Duplicate Pending Provisioning Transactions

[nihar_chaware]

Which IIQ version are you inquiring about?

8.5 p1

Please share any images or screenshots, if relevant.

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

Current Configuration:

1. We have WebServices Connector Configured and added provisioning retry configuration in Application.xml

<entry key="provisioningMaxRetries" value="3"/>
<entry key="retryableErrors">
  <value>
    <List>
      <String>HTTP Error Code: 400</String>
      <String>Bad Request</String>
      <String>HTTP Error Code: 401</String>
      <String>JWT validation failed</String>
      <String>HTTP Error Code: 403</String>
      <String>Forbidden</String>
      <String>HTTP Error Code: 404</String>
      <String>Not Found</String>
      <String>HTTP Error Code: 429</String>
      <String>Rate Limit Exceeded</String>
      <String>HTTP Error Code: 500</String>
      <String>Internal Server Error</String>
    </List>
  </value>
</entry>

Issues/Observation:

1. On Failure, the Provisioning Transaction goes into Pending state and tries to Retry the transaction every 60 mins (by default). The retry happens as desired.
2. On Fixing the Configuration and Retried, the Transaction also gets success but the duplicate transaction which got created which has Identity Populated Still remains in Pending state.

Questions:

1. Why do we see two duplicate transactions created and How can we fix it?

[msingh900 (Manish Singh)]

Hi @nihar_chaware

Can you please share the LCM provisioning workflow that you are using. Is it customized or are you using the default OOTB LCM Provisioning?

[neel193 (Neelmadhav Panda)]

@nihar_chaware Could you please click on Action button and see what all additional requests are there? Also, what is the source value in both provisioning transaction?

[nihar_chaware]

We are using Cloned OOTB LCM Provisioning with some modifications on Notification Reminders.

[nihar_chaware]

@neel193

Could you please click on Action button and see what all additional requests are there

The Requests are for provisioning policy identity attributes like firstname, lastname, etc. in both provisioning transactions but the one which was success has result committed for that attribute while the one still in pending shows retry.

Also the source value is empty in both provisioning transaction.

[msingh900 (Manish Singh)]

IN this retry, are you manually also retrying any provisioning transaction? or using the connector retry functionality only it is being retried?

[neel193 (Neelmadhav Panda)]

@nihar_chaware Could you please share your provisioning plan? Is this OOTB plan or you have a code to generate the plan?

[nihar_chaware]

The Plan is generated from the AfterProvisioning Rule of another Web Services connector.

Identity planIdentity = plan.getIdentity();
Operation operation = accountRequest.getOperation();

// Plan created for the webservices connector whose 
// retry configuration is configured
ProvisioningPlan newPlan = new ProvisioningPlan();
newPlan.setIdentity(planIdentity);

AccountRequest newAccountRequest = new AccountRequest();
newAccountRequest.setOperation(operation);
newAccountRequest.setApplication("Application_NAME");
newPlan.add(newAccountRequest);

Provisioner provisioner = new Provisioner(context);
provisioner.execute(newPlan);

[nihar_chaware]

Yes for testing I did manually retried but as I said the provisioning transactions were created twice with Pending status and only one of them showed retry option which on retry goes to success while the second one doesnt have retry option and stays in Pending status

[punna0001 (harish Punna)]

Hello Nihar,

Based on the code, I would focus on the Provisioner.execute(newPlan) call inside the AfterProvisioning rule.

The OOTB LCM flow manages retries through the Provision with Retries subprocess, where the retry project is merged back into the original provisioning project. Here you are creating and executing another plan separately, so it may not be tracked and merged with the original LCM project correctly. That would also explain why only one pending row has the Retry action.

I would create both application requests in the original plan before it is compiled. If the second application must run only after the first succeeds, launch it through a separate workflow and track it as a separate request. Before changing anything in the database, compare the project, request and workflow details of both transactions

[neel193 (Neelmadhav Panda)]

@nihar_chaware Please print both plans, original one and new plan and please share it here.