uSleep function is not stable

[Chenyang]

Hi Experts,

I used uSleep function in termination case. The system waits for 5 minutes to complete some other activities, before it terminates the user.

The function works fine in most case. But when there were any issue with the dispatcher, the uSleep sleeps forever and will never wake up again. Dispatcher restart will not resolve issue, unless you restart the the task by force.

Is there any way to avoid the uSleep issue?

Thanks,

Chenyang

[former_member2987]

Hi Chenyang,

First off, I think you need to open a ticket on that. While the dispatcher kicks off the job, the JavaScript library should not be affected. I would think that if the dispatcher was interrupting the pass execution that re running it should fix it.

As a workaround to uSleep, could you do a uProvision on a task that had a 5 minute delay before start, just load the task with a pass that does nothing. (or very little). Or if you can break up the actions in the task so that you do some, and then stick in the 5 minute delay before the remaining operations occur.

Matt

[Chenyang]

Hi Matt,

thanks for your suggestion. I have an action task before the termination task doing nothing but to sleep 5 minutes. Since it is a sporadic issue. I will report to SAP if it happens again .

Thanks,

Chenyang

[former_member2987]

Hey that's great Chenyang! Please like the answer and accept if it helped!

Matt

[brandonbollin · Accepted solution]

Couldn't you just use a Wait Task? Both IDM v7.2 and v8 have something along these lines. I would assume the task you're speaking about is tied into the Modify Task for the MX_FS_EMPLOYMENT_STATUS or MX_FS_EMPLOYMENT_STATUS_ID attributes. If the attribute is modified, you evaluate the new value in your task and, if the identity is now terminated, you perform your termination process.

During the termination process, you're probably calling another, external process that has to complete its actions before the remaining operations in your main task complete. Immediately after the task that has the uProvision in the script or is linked to that external task, in IDM v7.2, insert an ordered task group and in the Result Handling tab, select the box at the top, "Wait for Event Tasks". In IDM v8, there's a specific, "Wait Task" you can insert into the workflow chart (the new thing in Eclipse that looks like a Visio diagram). Both of these will accomplish the same thing, await for all tasks associated with this AuditID to complete before moving on to the next item on your main event task workflow.

This is much more reliable than using the uSleep function because it's not time sensitive. What happens on a especially heavy processing day when IDM is churning through a TON of data and that sub process takes longer than 5 minutes to complete? Might happen only once in a blue moon but do you really want your process to have that kind of vulnerability? Using a wait task is much cleaner and will work right every time. Heck, might even be faster because, likely, in most situations, your sub task won't take 5 minutes to finish so now your main process can move forward more quickly.

[Chenyang · Accepted solution]

Hi Brandon,

I like your idea. I will test your solution with wait task.

cheers

Chenyang

[brandonbollin · Accepted solution]

Cool! Let me know if it works for you. I'll keep watching this thread for your results. 🙂

[Chenyang · Accepted solution]

Hi Brandon,

Sorry for slow response. I tested the "wait solution"solution and it didn't work unfortunately.

The "Wait task" does not actually wait for other activities of the same identity to complete before moving on to the next one - terminate the user. The termination happens to the user first, then some other updates continue to the identity which cause inconsistency.

I have a sync job to read and update employee profiles from SuccessFactors to IdM. There are many attributes to calculate and update, so it is quite time consuming. There is another event based task "termination" which is set on the create/update event of mx_fs_employment_status_id.

I want the user update to complete first, before it triggers the termination event. The "wait task" does not wait for the user update job, which is outside of the termination task.

Can you share some other ideas on the issue I am facing?

Thanks,

Chenyang

[brandonbollin · Accepted solution]

Maybe your best bet would be to have two separate reads of attribute updates from SuccessFactors. Have your current sync job operate as normal and read in all the employee profile updates but disable the update to MX_FS_EMPLOYMENT_STATUS_ID. Then, once that task has completed and updated all the attributes in IDM, have a second task that does the same read from SuccessFactors but only updates the MX_FS_EMPLOYMENT_STATUS_ID attributes on your user records. Now, when anyone's records gets a terminated status, then your termination process begins. Perhaps that would work?

[former_member201064]

In the meantime, you could code your own sleep function and use that then.

[former_member2987]

Hi Dominik,

I have some concerns with that. The current uSleep() is a Java function, so I would wonder if any custom function would cause an issue. Of course, the difference could be that uSleep() comes from a library and the custom sleep might just be code which would probably make a difference.

I'm not enough of a Java developer to comment more on this, but I would appreciate your thoughts.

Matt

[former_member201064]

Depends on the situation I would guess.

I read it like the IdM itself has the problem with "reactivating" its uFunctions not with what is inside them. So avoiding uSleep and adding a script could solve the problem. I think the SAP 2nd or 3rd level support could find that out, so a ticket really is the best.

Yet, I'd give it a try. Maybe even a script with a while loop and a select on the audit table could be possible (ehem, there's a uFunction again now). And don't forget the break statement like 10mins are gone or something. Also would depend on how often that process is called. For termination could be OK.

Even better idea: Set up a batch job that does stuff like calling a task when the conditions are met. The job could then run every minute or every five minutes.