SAP_SAPUserInSAPRole_Assign executed every 30 seconds only

Said differently :

If we do continuous refreshes in the monitoring page of the job server for the queue managing SAP requests, we can see that most of the time absolutely nothing happens and that it just wakes up intermittently to process a request, generally in less than a second, like if he was taking breaks for no reason, when there are still plenty of SAP tasks to process in Job Queue.

Hello Michel,

the SAP APIs (e.g. to add/remove role assignments to/from users) lock the under lying object in the SAP system. Concurrent change attempts to the same object will fail.

Depending on the OneIM version there are two different strategies to handle this behavior.
The old strategy was to use a Process task where the JobService enforces that there is only one Instance of that kind of Process task executed on this Jobservice at any given time.
The new strategy is to use a Process task that allows execution in multiple instances on the same Jobservice. But the Database keeps track of the objects a process step is related to and prevents the delivery of multiple process steps related to the same object to Jobservices.

Both strategies have different advantages and draw backs. The old way is fast in environments with little changes but quickly chokes under high change amounts and is incompatible to load balancing over multiple Jobservice instances. The new way is slow when multiple changes to the same object are made in quick succession in an idle environment but can easy out perform the old way when large amounts of changes to different objects are made. The new way also is compatible to load balancing over multiple Jobservice instances.

To me it sounds like you see multiple SAP_SAPUserInSAPRole_Assign instances that are related to the same object (like the same SAP user). If that is the case, check why there are multiple instances of SAP_SAPUserInSAPRole_Assign for the same related object.

Hello Andreas,

Many thanks for your detailed answer. I confirm we have sequences of multiple instances of SAP_SAPUserInSAPRole_Assign for the same related SAPUser, because we usually assign several SAP roles to each user. Which is classical I think. But if the new strategy allows to run several SAP requests in parallel and therefore to take benefit of the different execution slots in the job queue (that the old strategy did not allow from what I understand), I don't understand why the "new strategy" does not allow at least to continue to use a single execution slot and execute the requests one after the others, even if they are related to the same SAPUser. If the counterpart for being able to execute in parallel several requests related to different objects is that we are now unable to execute one after the other some requests related to the same object, then this is a bug and a bad implementation of concurrent access. Parallelism should be implemented with appropriates locks / unlocks and not with pauses because again, what we see is pauses of 15 or 30 seconds between the executions of the steps. Are you aware of a mean to switch to the former strategy ? May be by switching from AdHocProjection to AdHocProjectionSingle ? Please tell me if I misunderstood your answer and many thanks again.

Michel

Hello Michel,

SAP_SAPUserInSAPRole_Assign used AdHocProjectionSingle in older versions. That caused a pile up of thousends of process steps in the jobservice that were processed one by one.
AdHocProjectionSingle is marked as "max instance = 1". There for only one task of that kind is processed by the Jobservice Instance at any given time. This is intendet to prevent concurrent access to a local exclusiv resource. There is no (direkt) communication between Jobservice Instances to coordinate the execution of process steps. Therefor running AdHocProjectionSingle Process steps on different Jobservice instances that will use the same exclusiv ressource will collide in the SAP system.

Now SAP_SAPUserInSAPRole_Assign uses AdHocProjection. A jobservice may run multiple instances of this task simultaniously. This task is marked as exclusiv per object. When a jobserver requests work to do, the database prevents that multiple processes are returned that contain process steps that are related to the same object. In an enviroment that is basicly idle, this can trigger an unfortunat timing related behavior. When (almost) all Processes are related to the same object, only one Process is deliverd to the jobservice per load cycle. In an idle envornment the intermediat load of Processes is likly to happend prior to finishing the currently processed SAP_SAPUserInSAPRole_Assign instance resulting in loading no additional Processes. The next intance of an SAP_SAPUserInSAPRole_Assign Procces will happen with the next regular load cycle. In an enviornment with a certain baseline load of processes this timing artifact is unlikly to occurre.

In a chronically idle environment you could shorten the load interval of the Jobservice processing the SAP_SAPUserInSAPRole_Assign Processes.

From the point of view of an jobservice a process step is just some information like how to find the process task (which class in which library), how many instances of the task or library are permited and some information to pass to the task instance. The jobservice does not need to know what is accessed by the task. In turn the task does not know how many siblings are currently activ.

Regarding the "appropriates locks / unlocks" and supposibly "bad implementation of concurrent access". We don't talk about concurrent usage of a resource from within a singel (operation system) process that coordinats a couple of tasks. Basically all outward facing process tasks are excecuted in independent (operation system) processes. We talk about preventing concurrent access to the same resource from independend processes executed on probably differnt machines that probably don't even see eachother and only talk to the database via probibly diverent instances of application servers. The only thing they use in common is the database and thats not where you want to introduce more time critical things like interprocess lock semaphores.

Best regards
Andreas

Hello Andreas,

Many thanks for your detailed answer even if I still don't undesrtand why this is designed in this way but anyway, can you tell me where is configured the so-called "load interval of the Jobservice" ? Or is it possible to come back to the former behavior because on our side we have a single job service for SAP and therefore any kind of mechanism that allow concurrent access from different job services is useless in our environment ?

By the way, are you working for One Identity ?

Many thanks.

Michel

Hello Michel,

the "Process request interval (seconds)" is a setting of the JobService. This can be changed in the Designer or on the host running the Jobservice using the JobServiceConfigurator. 10 seconds might be a good choice.
There is no switch to go back to the old way. But you can create a custom copy of the SAP_SAPUserInSAPRole_Assign Process that uses AdHocProjectionSingle instead of AdHocProjection.

Yes. Employees have a Quest and/or an One Identity icon in there profile tooltip and are labeled as such in there profile.

Best regards
Andreas

Hello Andreas
When coming back to this topic, I realize I entirely forgot to thank you for your answer below that I took into account by switching to AdHocProjectionSingle and it worked fine in V8 for 2 years, but since we migrated to V9 this solution is not working anymore. I mean we are back to the former behavior where processes "SAP_SAPUserInSAPRole_Assign" are picked up from the jobqueue at regular intervals, except this is even worse than with AdHocProjection because the tasks are executed at a rythm of around 1 job every 1m30s instead of one job every 30 seconds. I tried to switch back to the standard process using AdHocProjection but it changed nothing and then I am back to the issue we had 2 years ago, taking into account we have a single job server running the SAP queue and therefore any kind of optimization related to parallelism is entirely useless in our context.
If you have a new suggestion it would be highly appreciated.
Many thanks again for your former answer.
Regards,
Michel