[midPoint] Couldn't determine shadow name

Wed Jul 6 19:34:59 CEST 2022

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.

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> on behalf of 
> Pavol Mederly via midPoint <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>
> *Cc: *Pavol Mederly <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%7C6db71273b9e54c31b99b08da5f2f5dc8%7C58b3d54f16c942d3af081fcabd095666%7C1%7C0%7C637926954285726547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hAMdFcxeO%2FQlRRUqGHNHQCoLi4sWNZzxRQummPvlDtE%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%7C6db71273b9e54c31b99b08da5f2f5dc8%7C58b3d54f16c942d3af081fcabd095666%7C1%7C0%7C637926954285726547%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c%2FCeTzy7i7FA5tBl2pWQBA4Wnb1j%2FdOkMCDAltEdPAQ%3D&reserved=0>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> https://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20220706/9a19bc00/attachment.htm>