New feature in 9102 for performance enhancement of provisioning engine by enabling the parallel execution.
To reduce the transaction time out for various target systems.
Example: Consider 10 users to be requested 10 target systems... (U1, U2,.....U10 to request for R1, R2....R10). So there will be a total of 100 transactions.
In releases earlier to 9102, where there is no off line provisioning, this process goes on as a sequential one
provision R1 to R10 to U1, then R1 to R10 to U2, and so on.
Only after U1 to U10 are completed, only then the request is completed. Basically, it is a serial execution, which is time taking.This can impact performance, and also the transaction time-out on the target systems might need to be increased. The admin has to wait for all the 100 provisioning to be completed, after clicking the submit button, to get a response to UI from the provisioning engine.
So the concept of offline provisioning using JMS messages has been introduced in version 9102.
As soon as the request is submitted, the provisioning engine submits a JMS message (for each account on target system).
In above case 100 messages will be submitted, and it gives a response back to the submitter that the operation has been initiated. So, submitter need not wait for the entire process(es) to complete.Slowly each of the request (here 100) is completed. By this most of the execution is offline and the execution can happen parallel and there will be improvement in performance. the submitter gets response as soon has he submits the request. The transaction time-out on target systems will not be affected as it is a parallel execution.
To enable offline provisioning, on the resource object form, in design console, tick mark the "offline-provisioning" check box and also on the provisioning process definition of this resource object, tick mark the "Auto Save Form" check box for provisioning use case.
For other user operations like enable, disable etc, only the "offline-provisioning" check box is enough to be tick marked.
As soon as the request is submitted, the status of the request would be "provisioning in queue". As the JMS message is submitted. Once MDB picks up this JMS message and completes the provisioning, the status would now change to"provisioned"
You will not find any advantage of offline provisioning if the number of "operations(create, update, enable, disable, revoke) are less. But for any bulk operation as mentioned above, the submitter will not see the status for the request, until all the operations are complete.
But here, JMS message is initially submitted, a intermediate response is sent back, and then MDB picks up each JMS message parallel and completes the execution.Once execution is done, another status message is sent, based on details in "Task to object status mapping".
Trouble shooting:
What happens if one of the JMS messages get failed>>> Where to track these failed messages...
for this, before submitting a JMS message, all details related to the request and the JMS message are inserted into a table called OPS table.
Process instance, user key, obj key, kind of details of the request and JMS message details are inserted into the table.
Once the operation is complete, the row is deleted.
So if the request failed, it means the row is not deleted from this table.
OPS means Offline Persistance Store.
if all the JMS messages are processed successfully, then ops table will be empty.
So at any point of time, an admin can refer to this table for failed transactions and then take corrective action accordingly.
There is also a scheduled task that deletes these kind of failures after a certain age of days.
Name of the task is Remove Failed offline messages.
This task is present because, for a failed message, after u take corrective action, it has to be manually deleted. So for this purpose, we have put this scheduled task which deletes the failed messages after a certain period of time.
