Hello,
We are trying to see how to establish account to entitlement relationships when the target API does not provide endpoints to retrieve user groups.
In the new source I am trying to implement we will have around 20000 accounts and 1000 groups that we will need to match to those accounts.
The groups can only have one member at a time and therefore it is a waste of ressources to run the solution proposed in the link I shared.
I am trying to see if there is a way to make a rule that runs after the entitlement aggregation and loops on entitlements to then match it with the user it belongs to
I know that the endpoint to update accounts does not allow us to change account attributes, but is there another way to make this work?
If you had the option to migrate to SaaS connectivity, you could solve this issue pretty easily by customising your aggregation call. However, WS connectors don’t handle these situations smoothly and some work needs to be done. A single account aggregation involves at least three different calls: list groups, list accounts and collect account details. Account calls should be parent and child and that’s fine, but you’d need group information available in your last call. In my opinion, the only way to work around that is to store group information in the application object with a WS after provisioning rule attached to list groups call and fetch that info later on in the account details with another after provisioning rule. I haven’t tried myself but I reckon it should work. My rule is inefficient but it’s generic and easy to use, I think.
Storing group information within the application object (configuration) is not ideal either, and you need to be careful of the size. However, in your situation, I’d say it’s worth a try.
I have tried to store the group information within the application object during the Group aggregation. My group aggregation calls has paging configured and the groups are added in the source with each call.
I have to handle therefore the case where it’s the beginning of the aggregation to start from a new list or if we are in a paging step and increment the already existing list.
I have come across the following behavior on the start of the aggregation I create a new list and replace the attribute in the source supposed to hold the information correctly.
On the next paging step, using “application.getAttributeValue(“groupList”)” the returned value does not look like it has been updated from the first step.
I tried to run this rule for One iteration only and I can confirm that my API call to update the connector attribute holding the information works fine.
Is there a delay between the update of the source and the update “application.getAttributeValue()” ?
I would like to note that we also want to use this call and no API calls as we plan on encrypting this field for security reasons.
I’m not 100% sure but I suspect the application object is not persisted before the operation finishes. You could try to update the field with the entitlement aggregation call to get it ready for a subsequent account aggregation call.
I vaguely remember there was a naming convention for an attribute to make it encrypted by default but I cannot find it right now. Perhaps someone else knows.
My rule is working fine now I just have an issue with encryption. encrypting this field seems to transform it into a String, while the original form is a List. This field does not seem to be updated by the rule anymore. And the only thing I changed about the rule is some code lines to transform the String back into a List.
I tried as well to store the attribute as a String itself but it does not resolve the issue.
I never experienced something like that, sorry. I checked Application class Java docs here and I was surprised not to see any attribute update methods. This is part of the equivalent object from IIQ docs:
The differences are pretty evident. I don’t know if this is by design, I guess so but I’d need confirmation. It may be we were not supposed to update the application object to start with, which is definitely going to complicate things for you.
@tyler_mairose, could you please confirm the Java Docs are accurate and updating attributes of the application object is not supported?
I aslo was not able to find a way to update the attribute directly with a method from the class. this is why I use the following API call update-source | SailPoint Developer Community in my rule.
It seams to work fine when the field I want to update is not encrypted. but does not work when I try to encrypt it.
I have seen the Java doc for IDN recently, but the first question I got was get methods are fine, but what I am going to do with set methods. I cannot save any object explicitly rite as context usage is prohibited. Some objects are fine, for example: ProvisioningPlan, where you set attribute requests and it’s values but not all objects.
I could see that, Java doc is continuously getting updated.
