Skip to Content
Author's profile photo Kai Ullrich

Wait for event tasks

You have certainly already noticed the “Wait for event tasks” check box in ordered task groups and conditional tasks.

image

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:

image

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:

image

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:

image

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.

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sri S
      Sri S

      Hi Kai ,

      Thanks for the post.

      We have a scenario ,where there are 3 ordered task group under one Ordered group .First ordered task removes business roles/direct privileges from the user - which in turn triggers the provisioning framework tasks for removal of inherited privileges from the user. The second ordered task should not get triggered until this process is complete and hence we have checked on "Wait for event tasks" on the second task . Also same with the third task which must not get triggered until the second one is completed and hence "wait for event tasks' is activated in this task as well.

      However the tasks do not wait as expected and hence we have included manual delay time between tasks as a work around. We do not call uProvision explicitly in this scenario as you see. Could you please advise on this ? Thanks

      Best Regards

      Sri

      Author's profile photo Kai Ullrich
      Kai Ullrich
      Blog Post Author

      Hi Sri,

      I remember having seen that the "wait for event tasks" doesn't properly work for the provisioning of roles/privileges. What you can do in this case to workaround the problem is to use the notification hooks to perform your post processing activities. Here, the attribute MX_TRIGGER_NOTIFICATION (or similar, not 100% sure) is written on the user with additional information and you have to register an event on this attribute and then this event gets called after successful provisioning (and also after failed provisioning, you'll have to add some more smart logic to filter out the events you're not interested in).

      Hope this helps.

      Cheers

      Kai

      Author's profile photo Former Member
      Former Member

      Thats correct. Removing a role/privilege doesn't create audit(s) until its been evaluated by the eval-link process initiated by the dispatcher so its difficult to create a wait function. You can look at the "Request Complete" task functionality and see if you can implement something there.

      For instance:

      My Scenario Thing (Ordered task)

        De-assign roles/privileges (1st ordered task)

           Generate Request ID, write to attribute/ctx var

           Action that removes assignments using {REQUESTID=<requestid>}{D}<role>

        Wait to continue #1 (Approval task)

        Something not specifiec (2nd ordered task)

           Generate Request ID, write to attribute/ctx var (action)

           other unspecified actions....

        Wait to continue #2 (Approval task)

        Something not specifiec (2nd ordered task)

      The request complete task needs to check if the request id is in "Wait to continue #1" or "Wait to continue #2" and if so use the uApprove function to send them on their way to the next step.

      Author's profile photo Sri S
      Sri S

      Thank you for the reply.

      But when we add a task under Request complete functionality , it gets executed on all scenarios . In our case , we have multiple other functionalities created as ordered tasks and we dont want that request complete to get executed for all the other tasks , but for this remove privilege functionality.

      Please advise.