[midPoint] Couldn't determine shadow name
Wang, Xiaoshu
xiaoshuw at email.unc.edu
Wed Jul 6 20:00:04 CEST 2022
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<mailto: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<mailto: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<mailto: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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20220706/c560f966/attachment-0001.htm>
More information about the midPoint
mailing list