Restrict the sequence of API calls in Webservice Connector

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about?

8.4p2

Share all details about your problem, including any error messages you may have received.

We have a unique situation in integrating with an API service using webservice connector. We are using a Quicklink form to generate the access requests for the users which invokes the LCM provisioning workflow. The API is configured in such a way that the first request for the user should be a method called “Add User” and all the subsequent methods to the methods called “Add Groups”. The create user has a mandatory argument of the role to be assigned to the user and the add groups method cannot accept multiple groups in a single request. We had to generate individual request for each role/group selected by the user on the form. The issue we are facing with this approach is:

  1. If a user selects 4 groups on the form and submits the access requests, 4 individual requests are getting submitted (As expected).
  2. At the final level of approval, if the approver clicks approve on first request, wait for it to complete and then approves other requests - the first request is being sent as create and all the subsequent requests are being sent as “Modify”
  3. If the approver at final level, clicks approve on all the requests without waiting for them to complete back to back instantaneously, all of them are being passed as a create operation and only one group is being added to the user on the target as all the other groups are returning an error user already exists when sailpoint is trying to create the user again as the difference between those api calls is milliseconds and I don’t think Sailpoint is creating link by that time to identify the subsequent requests to be Modify.

Can someone please provide us with inputs on how to solve this issue? We have currently asked the approvers to wait until the approval is complete and then act on the next approval item, but is there any way to fix this? Any inputs or suggestions are highly appreciated.

Thanks,
Maneesh.B

2

If the approver approves all the requests, does it result in a single ‘Create’ operation request that includes all the groups, or does it generate separate ‘Create’ requests for each group?

In the case of the second scenario (separate requests per group), the ‘Before Provisioning’ rule should be used to first check whether the user account already exists. If it does not exist, proceed with the ‘Create’ operation. If the account already exists, change the operation from ‘Create’ to ‘Modify’ then process it

3

Thanks for your reply. Yes, we are in the second scenario, i.e separate create requests for each group. Are you suggesting to check if the user account is already exists by directly checking on the target via an API call? As Sailpoint link will not be created on the identity with in those milliseconds of time difference