Wait for event tasks

Have you ever wondered what it is good for? Actually, here, we have a very cool feature of SAP NetWeaver Identity Management that I’m going to demonstrate in this post.

Imagine you have the following situation: You want to order execution of 3 tasks. One of them can’t be added in an ordered task group because it must be called by uProvision. This is pretty common, say you want to iterate and do something with each direct role assignment of a user and have another task executed only after the work on the roles has been completed. An ordered task is only the part of the answer here because you don’t know in advance how many roles there will be and how many calls you need. So you do not have much of a choice than doing this in a toGeneric task and call uProvision in a for-loop or similar. The problem is that uProvision kicks off task execution in parallel to the execution of the originating ordered task group.

See the following screenshot:

This picture tries to summarize this situation. We have an ordered task group (“Wait-for-example”). The first task to execute is Task calling Task2 by uProvision. After that, we want to call the task Task3 which should wait for Task2 to finish. As its name declares, Task3 should only be executed after all tasks started by uProvision in the previous task have successfully terminated.

What we could do, of course, is to check in mxp_provision similar to what we did in the Synchronization of IdM Tasks blog post I published earlier. But there is a better mechanism. Quote from the documentation:
You can specify “Wait for event tasks” on task execution and result handling. In this case, the ref audit field is used to determine whether tasks are still running. If one of the options is selected, it waits as long as there are tasks in the system where the ref audit is the same as the own audit ID.
This is exactly what we need. We want Task3 to wait until there is no other task running anymore. Only then, Task 3 should be executed. It’s as simple as that. But 2 more things are important:

 
1. We need to make sure that the tasks called by uProvision have the same audit ref as the ordered task group. We can achieve this by passing the current audit (function call uGetAudit()) as third argument to uProvision).  
2. Normal tasks do not have the “Wait for event tasks” check box. So the one that wait needs to be wrapped into an ordered task group.

So let’s modify the example accordingly:

Let’s see what happens if we execute “Wait-for-example”. The first task beneath simply calls Task2 but with a 60 seconds delay. This gives us the opportunity to check if Task3 really waits. Here is what you see in mxp_provision after executing the example:

You can clearly see that the task with ID 325 (which is the “wait for…” ordered task group) is waiting because there is one task in the queue with audit ref 607. A look into the job log also clearly reveals that the tasks have been executed in the right order.