I have just started writing before provisioning rules and I am hoping to get some insight into product conventions.
The pattern I see in all the rules I have reviewed all follows the same approach:
for (AccountRequest accountRequest : plan.getAccountRequests()) { }
The plan returns a collection of account requests, what normally does that look like for creates for example?
I figured I would often see a create request followed by one or more modify requests, but we don’t, even though we add additional attributes to the create request that I know require a subsequent modify operation to set. They seem to be all contained with the same request.
So what does this collection normally look like for:
New account creations
Existing account disables (that we rewrite into deletes give the right conditions)
A Create Account request will typically have a list of attributeRequests (account.getAttributeRequests()) and each attributeRequest will have name: name of the attribute value: value populated based on Create Account profile of target source operation: Set
In addition to these, it will also have the target application reference as well as the account’s native Identity (value that will be assigned to the attribute marked as “Account ID” in the account schema of target source
Hi @iamnithesh ,
I guess I am curious what is possible given the plan contains collection of AccountRequest’s and bp rules are isolated to a specific source.
Under what circumstances would the collection of AccountRequest’s contain more than one entry?
Presumably if you had created more than one account for the same identity on the source? Are their any other circumstances?
A concrete example would be when we are rewriting an enable into a delete (given the required criteria). One might think it would make sense to ignore checking for any other uses cases and exit the loop.
But not knowing what the plan can contain, I am unsure about approach.
I have not seen any case where a Provisioning Plan had more than one Account Request. My best guess is that as ISC is developed as a cloud version of IIQ and same java libraries were reused, ProvisioningPlan class which would handle multiple Account Requests in IIQ continued to have the same structure, hence List of AccountRequests instead of single.