[midPoint] Couldn't determine shadow name

Thu Jul 7 08:56:30 CEST 2022

We have a similar issue with one API where there is no findAll/findById
method to get the current state of a resource.
We prepare a "cache" table where the connector writes the last known state
that is sent to the resource over create/update and we use this table to
receive the last "known" state when we need findAll/findById.

best regards,

Gustav

st 6. 7. 2022 o 20:00 Wang, Xiaoshu via midPoint <
midpoint at lists.evolveum.com> napísal(a):

> Pavol:
>
>
>
> I am not sure how.
>
>
>
> The icf connector’s create signature is this. And see the implementation
>
>
>
> public Uid create(ObjectClass objectClass, Set<Attribute> attributes, OperationOptions
> operationOptions) {
>
> Optional<String> pid = CsUtil.*findPid*(attributes);
> if (pid.isPresent()) {
>     *LOG*.info(">>> Done CsCreate.create");
>     Name name = new Name(pid.get());
>     Uid uid = new Uid(pid.get(), name);
>     return uid;
> } else {
>     throw new IllegalArgumentException("Cannot create because PID is empty");
> }
>
> }
>
>
>
> I can only return a Uid object. Providing the nameHint seems have no
> effect.
>
>
>
> Most “standard” resource will go through the executeQuery method (e.g,
> through an inititial import).
>
>
>
> public void executeQuery(ObjectClass objectClass, PersonSearch personSearch,
> ResultsHandler resultsHandler, OperationOptions operationOptions) {
>
>
>
> Here, you can construct a connectorObject and ask the resultHandler to
> handle it. So, I can set both uid and name to whatever I want.
>
>
>
> But, because my resource cannot do the blank query so the midpoint will
> call the create method when needed. But the create() is unaware of
> connectorObject, it only returns a unique handle, i.e., the UID.
>
>
>
> What I guess is this.
>
>
>
>    1. A property-change triggers an outbound mapping
>    2. Midpoint notices the absence of a shadow account for the outbound
>    resource
>    3. Midpoint called the connector.create() method to create the
>    intended resource and subsequently create the shadowObject with the
>    returned uid.
>    4. At a later stage, it triggers the ShadowUtil.determineShadowName
>    method and throw an exception when found absent.
>
>
>
> A potential remedy is step #3, when midpoint can use the nameHint of the
> Uid object to fill in the name of the shadow account.
>
> Xiaoshu
>
> *From: *midPoint <midpoint-bounces at lists.evolveum.com> on behalf of Pavol
> Mederly via midPoint <midpoint at lists.evolveum.com>
> *Date: *Wednesday, July 6, 2022 at 1:35 PM
> *To: *midpoint at lists.evolveum.com <midpoint at lists.evolveum.com>
> *Cc: *Pavol Mederly <mederly at evolveum.com>
> *Subject: *Re: [midPoint] Couldn't determine shadow name
>
> Hello Xiaoshu,
>
> I am still not sure I completely understand your use case, but maybe the
> simplest thing your connector can do is to mirror __UID__ to __NAME__
> itself (if the name is not known). This is actually what many connectors do.
>
> See also
> https://docs.evolveum.com/connectors/connid/1.x/connector-development-guide/#__uid__-and-__name__-are-the-same
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.evolveum.com%2Fconnectors%2Fconnid%2F1.x%2Fconnector-development-guide%2F%23__uid__-and-__name__-are-the-same&data=05%7C01%7C%7C82ee4f4b8d5641f797bd08da5f75ddd5%7C58b3d54f16c942d3af081fcabd095666%7C1%7C0%7C637927257089124002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IdUHpdfHbErsScQkaEq4fsd7cgcdpL2WzMpJckyIPQk%3D&reserved=0>
> .
>
> I am not sure why both of these are obligatory in ConnId (originally ICF,
> then OpenICF).
>
> The ShadowUtil.determineShadowName method is maybe not very consistent, I
> must admit. (I have looked at it right now.) For example, it is called from
> a couple of places in midPoint, and a caller usually catches
> SchemaException, and continues with "no name" situation. I am not sure
> about your specific situation, because I don't know exact midPoint version,
> whole stack trace, and so on. But I think the best you can do is simply to
> return both __UID__ and __NAME__ from your connector, and (hopefully)
> midPoint will be happy with it.
>
> Best regards,
>
> --
>
> Pavol Mederly
>
> Software developer
>
> evolveum.com
>
> On 06/07/2022 17:34, Wang, Xiaoshu via midPoint wrote:
>
> Pavol:
>
>
>
> Conceptually, I know “why” it throws the exception but I wonder if it can
> be considered as a “bug” or “improvement” for the midpoint.
>
>
>
> I have a particular use case, where I have a resource that I only need to
> do outbound mapping. The resource, however, does not provide an API for me
> to do something like getAll() operations. In other words, I cannot do an
> initial import kind of task to force midpoint to create all the shadow
> account.
>
>
>
> Thus, when a property change that triggers an outbound mapping, midpoint
> noted that the resource does not exist, so it calls the create() method on
> the connector. Unlike the executeQuery method, which can construct a
> connectorObject and ask midpoint to handle it. The create method can only
> return a “Uid”. I understand the rational under this as the
> connector.create() is meant to create a remote resource as opposed to
> create the shadow account, (I guess is mirrored by the connectorObject).
> Upon receiving the UID, the midpoint then creates a matching shadow account
> with it (due to the absence of it). However, as both __UID__ and __NAME__
> are **required** attributes for a connectorObject (i.e., shadow account),
> then a later verification step failed the check and throws the exception.
>
>
>
> The exception appears non-preemptive, i.e., it does create the shadow
> account, which name, I can later fill when the updateDelta is called. The
> exception trace would be more of a nuance than error. Yet, I think it would
> be nice that midpoint can do some auto remedy for it. For example, during
> the validation phase, copy the __uid__ to __name__ if the latter is absent
> etc.
>
>
>
> Or, if there might be some other way to get around this particular use
> case of mine, I would be glad to hear it.
>
>
>
> Xiaoshu
>
>
>
> *From: *midPoint <midpoint-bounces at lists.evolveum.com>
> <midpoint-bounces at lists.evolveum.com> on behalf of Pavol Mederly via
> midPoint <midpoint at lists.evolveum.com> <midpoint at lists.evolveum.com>
> *Date: *Wednesday, July 6, 2022 at 5:10 AM
> *To: *midpoint at lists.evolveum.com <midpoint at lists.evolveum.com>
> <midpoint at lists.evolveum.com>
> *Cc: *Pavol Mederly <mederly at evolveum.com> <mederly at evolveum.com>
> *Subject: *Re: [midPoint] Couldn't determine shadow name
>
> Hi Xiaoshu,
>
> I always recommend to have a look at the code that throws the exception.
> In your case it's most probably this one:
>
>
> https://github.com/Evolveum/midpoint/blob/d317537626a99db32764c486507f1c1ac5a47fb6/infra/schema/src/main/java/com/evolveum/midpoint/schema/util/ShadowUtil.java#L688-L736
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FEvolveum%2Fmidpoint%2Fblob%2Fd317537626a99db32764c486507f1c1ac5a47fb6%2Finfra%2Fschema%2Fsrc%2Fmain%2Fjava%2Fcom%2Fevolveum%2Fmidpoint%2Fschema%2Futil%2FShadowUtil.java%23L688-L736&data=05%7C01%7C%7C82ee4f4b8d5641f797bd08da5f75ddd5%7C58b3d54f16c942d3af081fcabd095666%7C1%7C0%7C637927257089124002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NQ15LUcMeIk6ZXAR%2FxdGzzrPw%2FudHpWrP%2FP9TxZ3Yns%3D&reserved=0>
>
> (lines are shifted probably because of midPoint version mismatch)
>
> It should give you a clue - e.g. does your object have a primary
> identifier set? Etc...
>
> Regards,
>
> --
>
> Pavol Mederly
>
> Software developer
>
> evolveum.com
>
> On 23/06/2022 15:27, Wang, Xiaoshu via midPoint wrote:
>
> Hi,
>
>
>
> I am developing a custom connector. When I assign the resource connected
> with that connector, I got the following exception.
>
>
>
> com.evolveum.midpoint.util.exception.SchemaException: Could not determine
> shadow name.
>
>           at
> com.evolveum.midpoint.schema.util.ShadowUtil.determineShadowStringName(ShadowUtil.java:695)
>
>           at
> com.evolveum.midpoint.schema.util.ShadowUtil.determineShadowName(ShadowUtil.java:667)
>
>           ….
>
>
>
> The exception seems not do anything “harmful” as far as I can tell because
> the new account would be listed under the resource. But I want to know why.
> Hope someone can shed some light on for me.
>
>
>
> Xiaoshu
>
>
>
>
> _______________________________________________
>
> midPoint mailing list
>
> midPoint at lists.evolveum.com
>
> https://lists.evolveum.com/mailman/listinfo/midpoint <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.evolveum.com%2Fmailman%2Flistinfo%2Fmidpoint&data=05%7C01%7C%7C82ee4f4b8d5641f797bd08da5f75ddd5%7C58b3d54f16c942d3af081fcabd095666%7C1%7C0%7C637927257089124002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RFi8HBUDzf0vutdxZ7LwB6hr9gxZixVf162KsekRHUw%3D&reserved=0>
>
>
>
> _______________________________________________
>
> midPoint mailing list
>
> midPoint at lists.evolveum.com
>
> https://lists.evolveum.com/mailman/listinfo/midpoint <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.evolveum.com%2Fmailman%2Flistinfo%2Fmidpoint&data=05%7C01%7C%7C82ee4f4b8d5641f797bd08da5f75ddd5%7C58b3d54f16c942d3af081fcabd095666%7C1%7C0%7C637927257089124002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RFi8HBUDzf0vutdxZ7LwB6hr9gxZixVf162KsekRHUw%3D&reserved=0>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint
>

-- 
s pozdravom

Gustáv Pálos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20220707/082967ab/attachment-0001.htm>