Share all details related to your problem, including any error messages you may have received.
Hello!
In the project I am actually working we have the requirement of create a Webservice LogiPlex connector and we have an issue when we try to create accounts in the sub-applications when the master account exists for the user.
In the provision logiPlex rule we use the method runDefaultProvisioningMergeLogic to recalculate the plan and tranform it from create to modify in case that the master account exists, but when the method getObject of the master WebService application is called fail because the native Identity of the user don’t send to the method (provisioning plan = null)
We have in the jsonBody $plan.nativeIdentity$ and it works when we call the getObject from the “Manage Account” menu but not through the provision rule (runDefaultProvisioningMergeLogic method). We tried to use $getobject.nativeIdentity$ and we had the same result. We are checking the variables in the beforeOperationRule configured in the getObject method.
We saw in other post for SQL connectors that the variable is called $(identity) but we can’t use this in operation configuration and in the before rule the variable “identity” is void.
We can modify the plan on our own without the runDefaultProvisioningMergeLogic but I prefer to use the OOTB method for this.
Does anyone know how we can obtain the nativeIdentity(attribute/parameter) of the master-account in the endpoint configuration/beforeOperationRule using the runDefaultProvisioningMergeLogic method?
We are aggregating correctly and spliting accounts and groups depending of our criteria to each sub-application.
I would need to know more about the exact setup. You do not really need the provisioning rule if all you do is to call the default provisioning logic. If you don’t have a rule, that is exactly what is used.
If account creation is forced at some point, the trick is to get the corresponding account name from the main application. You can do so by getting the proxy of the current application. If there is no proxy, you know you’re on the main application. If there is a proxy, this proxy is the main application. Then look for a Link on the identity cube for that main application. If found and unique, take that value. If found and not unique you need to determine which account to use. If not found, apply the standard logic to generate the account id.
If an existing account is selected, the default provisioning logic will detect the corresponding account name and automatically convert the request to a modify on the main application.
You don’t need to use the getObject operation. It’s easier and probably more efficient to look inside IdentityIQ itself. Just get the Link from the identity.
Thank you for you reply. I understand your point, but if I remove the logiPlex provisioning rule, where will I put the logic of your trick? I suppose that I can do it in the provisioing rule, search for the main native identity and modify programatically the plan from create to modify without the runDefaultProvisioningMergeLogic method but without the rule?
I will try to remove the rule or just remove the runDefaultProvisioningMergeLogic method from the rule to see the behavior of the provisioning, but I think that it will still triying to create the account in the sub-application, I will see.