Spawning multiple approval tasks in parallel in OIM11g SOA Composite

Question

Hi,
We are trying to implement the following scenario.
1) We are trying to develop a SOA composite for AD Group Access
2) The request dataset contains a child table for AD User Group Details which is as follows.
<AttributeReference name="AD User Group Details" attr-ref="UD_ADUSRC" type="String" length="20" widget="text" available-in-bulk="true">
<AttributeReference name="Group Name" attr-ref="Group Name" type="String" length="400" widget="lookup" available-in-bulk="true" lookup-code="Lookup.ADReconciliation.GroupLookup" primary="true"/>
</AttributeReference>
3) Consider the user is already provisioned to AD.
4) User now tries to request for AD Group Access by using a request template
5) The request dataSet for the resource "AD Group Access" will be displayed where the user would "Add" the group(s) to which (s)he want access.
6) Once the request is sumbitted the associated SOA composite would be executed.
7) Now, in the SOA composite the logic should be as follows:
a. For each group selected, there is a corresponding dataApprover who should approve the request.
b. Once the dataApprover approves the request it goes to the next approver who is securityApprover.
c. Once the securityApprover approves the request, the request should go thru and the user should get the membership in the AD Group.
d. Since "AD User Group Details" is a child form in the request dataset, the user can add multiple groups in the same request.
e. If there are muliple groups selected in the same request, then the same request should spawn parallel approval tasks for all corresponding dataApprovers and securityApprovers.
f. Then the user should get membership to those AD Groups for which the corresponding dataApprover and securityApprover had approved the request.
e. If a dataApprover or securityApprover rejects the request then the user shouldn't get membership to the respective group. However, this shouldn't prevent the user from getting membership to other groups for which dataApprover-securityApprover approval was done.
The dataApprover and securityApprover for the groups are stored in a db table mapping to the corresponding group name.
We have implemented a SOA composite for which the logic is fine if we add only one group in the child table of request dataset. As per the current implementation, when a user submits the request, the dataApprover and securityApprover for the selected group are fetched from the table and the global variables in SOA composite are set with the ID of dataApprover and securityApprove using setVariableData. These are sting variables. These variables are used in the approval task. The approval task has two "Single Type" participants - dataApprover and securityApprover. These participants fetch the value of dataOwner and securityOwner from the global variables set using setVariableData.
Now, as mentioned above, if mutiple groups are added like group1, group 2 etc. then there should be multiple approval tasks spawned in parallel that will be approved/rejected by dataApprover1-securityApprover1, dataApprover2-securityApprover2 etc. Depending on the output (approve/reject) the user should get membership to appropriate groups.
Any inputs on how to modify the current composite to spawn multiple approval tasks in parallel depending on the number of groups added from the requestDataSet would be helpful.
Regards,
Swaroop

Answer 1

Single request id then you are bit safe. The way to do it would be:
1. Set the dataApprovers as a comma separated list of all the data approvers for all the groups.
2. Set the securityApprovers as a command separated list of all the security approvers for all the groups.
3. In Human Task assign the first stage to all the dataApprovers and second stage to securityApprovers.
Cons of this approach are:
1. All the approvers would see all the data and they might be confused what they are approving.
2. securityAppprovers for say group1 won't get the item untill all the dataApprovers approve the request even though dataApprover has approved the request for group1.
3. Would be hard to implement the rejection cases; depending upon how you want to handle the rejections. For e.g. what if any dataApprover rejects the request? Should the whole request be rejected? If so what would happen to those which have already been approved by dataApprovers? Same case goes for securityApprovers. Again since you cannot modify the requested data once the request is submitted; thus you cannot remove the rejected groups from the request.
4. You provisioning won't trigger untill all dataApprovers and all securityApprovers have approved the request.
5. Any one approve from comma separated list of approvers would approve the request. Thus you cannot make sure that all the approvers should approve the request. The workaround would be to create parallel stages in human task and assign one group/approver to one parallel stage. This would mean that you will have to hard code the number of parallel approvals which can be generated in your BPEL human task (This would again depend upon the number of groups requested). To workaround this you could use BPEL extenal routing program where you can pragmatically assign tasks but again since there is no entitlement based request engine in OIM, thus there would be issues there too.
As a workaround, make sure that you allow only one group to be requested per request and reject the request outright if multiple groups are requested in a single request. You will need to buy in the business on this one.
Have heard the grapevine that 12G which is in the pipeline would have entitlement based request engine and also would allow for modification of request data once the request is submitted.
HTH,
BB