[midPoint] Couldn't determine shadow name
Pavol Mederly
mederly at evolveum.com
Thu Jul 7 12:32:03 CEST 2022
Hello Xiaoshu,
OK, I understand that you cannot execute a "blank" query that would
return all objects on a resource. But can you execute - at least - a
query for one specific object, identified by UID?
--
Just by the way, could you share the whole stack trace of the
"SchemaException: Could not determine shadow name"? I am quite
interested in the whole execution path there. And, the exact midPoint
version.
Best regards,
--
Pavol Mederly
Software developer
evolveum.com
On 06/07/2022 20:00, Wang, Xiaoshu via midPoint wrote:
>
> 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>
> <mailto:midpoint-bounces at lists.evolveum.com> on behalf of Pavol
> Mederly via midPoint <midpoint at lists.evolveum.com>
> <mailto: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>
> <mailto:midpoint at lists.evolveum.com>
> *Cc: *Pavol Mederly <mederly at evolveum.com>
> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20220707/1b6374a9/attachment-0001.htm>
More information about the midPoint
mailing list