I am building a scripted rest connector (a little easier than a full ICF build I am finding). The connector is for recons from the target only so it is fairly simple. I connect to a rest end point, get back the data and throw it into IDM. It is mostly working. The connector connects, it gets back the data. When I click on the data tab in the connector I can see the fields and data no problem. But when I do a reconciliation against a mapping it gives me an error…
"[609] Sep 20, 2023 3:17:52.065 PM org.slf4j.impl.JDK14LoggerAdapter fillCallerData
FINE: Enter: getObject(ObjectClass: usergroup, Attribute: {Name=UID, Value=[MPV: Play]}, OperationOptions: {IS_INTERNAL:false,ATTRS_TO_GET:[assignmet,userGroupID,customerLaunchDate,lastUpdatedAt,customerDeletedDate,NAME,uuid,customerName,status],CAUD_TRANSACTION_ID:cf6d3e57-2182-4473-b5bc-a373d8a65cd0-14372/8})%09Method: getObject
[606] Sep 20, 2023 3:17:52.066 PM org.forgerock.openicf.connectors.groovy.ScriptedConfiguration evaluate
INFO: Entering SEARCH Script
[604] Sep 20, 2023 3:17:52.066 PM org.slf4j.impl.JDK14LoggerAdapter fillCallerData
FINE: Exception: %09Method: getObject
java.lang.IllegalArgumentException: can’t parse argument number: Name=UID
"
I cannot find anything that makes sense of this. My schema seems right, the data populates when I analyze it form the connector, It also populates when I test from postman, and the names all match… Has anyone seen this before on the scripted rest connector? I’ve been through the docs and the “basics” guide part 1 and 2. I just cannot see what is wrong. It looks like the error happens AFTER the data is collected as I can see all the records in the log. but then it runs get object and blows up…
Hi @rob.kimball,
It looks like the script is not translating the special names, e.g __NAME__ in this case. Refer to : Developing a Groovy Connector, there’s an example on how to make this translation.
Regards
Patrick
Been through the guide and have an open ticket. So far nothing appears missing. Was hoping someone had seen this error before. I’ve confirmed the data is coming through and the error only occurs when I pass it to the handler, so not sure what or where I could be missing that “translation”. but will keep looking. Thanks.
Actually I have missed this, the script is passing an object to the handler, and the error is java.lang.IllegalArgumentException: can’t parse argument number: Name=**UID**
How do you set the __NAME__ e.g the uid, aka in your handler you should have something like:
handler {
....
uid <some value>
...
can't parse argument number sounds like it finds it, but can’t parse the expected type? What type is supposed to be __NAME__?
I do have that in my handler. I saw some scripts do uid = and some scripts I’ve seen just do uid I’ve tried both ways. I’ve setup NAME in my provisioner the same way as I’ve seen other connectors do it. it’s of string type, and my input is a string…
Weirdly, doing testing the other day when I try to do a sync with a mapping ONLY to bring in the items from my target, the objects are created in IDM, but the link fails giving me that same error. I also tried removing the handler and just output the data to the log and the data looks fine and no error. Clearly something is wrong with the handler or my schema…but I can’t see what it could be.
So I have a mapping for this target system. the idea is we want to bring in these objects from the target system and create objects in IDM. when I run sync the objects create, but the link fails as my uid has a value of say 15 (this is what we are using as a unique identifier on the target side) but the object in IDM created with idm default UID (very long string) in the linked system tab it’s looking for 15. not sure how I got in this issue. but it’s makimg me crazy. I see the same error in the log too. it’s like i’m reconning with what I want for the UID but IDM is assigning something else, and even it doesn’t know it
Yep. Tried both with as string and without. Its weird.