Context when Invoking Long Running Processes

[NW987]

When I use a long running process to invoke another long running process, the creator of the second long running process is always "System Context Account".

Is it possible to invoke one long running process using another long running process using the context of the workspace user?  The primary need here is to be able to track the process in the audit tab.

[AKloft]

Assuming there isn't really a way of specifying the user_id for the process invoker, you can pass the user_id context variable into the

next long-running process and update the database by overwriting the creator_id in the database.  May or may not

be the best solution because its strongly advised to NOT modify the Adobe database.

Hope that helps,

Alex

[_Nith_]

I tries Alex's approach of modifying the creator_id with actual user id (instead of System Context account).

However, I don't see the tracking entry in workspace. But when I search for the process in AdminUI, it shows the modified creator name.

Nith

[Gary_Gilchrist]

This is not a very useful answer, but might be relevant added info: You can browse services (that arise from your deployed processes) in the Admin UI and configure their "Run As" behavior. The Run As can be set to the Invoking User, a named user or System. I think you may be able to set the Run As for any long lived process to be the process invoker, which will in turn get passed through to any sub processes that get called. The downside of course is that you may not really want those processes running as the end user because it performs activity steps for which the end user is not authorized to invoke etc.

That said, even if you do propagate the invoker's identity through to the invocation of sub processes. Workspace might not track it. I think this is beacuse Workspace only tracks the process that it paricipated in (through inintiation of task assignment) not other processes that get a knock-on assignemnt. I need to check with the Workspace team to verify that suspicion though.

[_Nith_]

Hi gary,

Thanks for the update.

I have just tried your "Run As" approach which is also not working.

My testing scenario:

I have created two processes (a Parent and a Child)

I have enabled RunAs option with 'Invoker' for the Child process.The parent process is configured to invoke the Child internally.

I am, as a user, invoking the Parent process from Workspace. The Child process is being invoked; However, the process's creator name still shows 'System Context Account'. I do remember that this issues was exist in previous release as well ES (8.0).

Is this a bug? or am I missing something in between?

Please advise.

Thanks,

Nith

[Gary_Gilchrist]

The reason for that (and sorry, I know this will not immediately solve your problem) is that the *parent* process probably did not have a Run As configured. Being Long-Lived it will, by default, run as "System" after its invoker has invoked it and is no longer synchronously waiting for a resoponse. So if you chnage the parent process to "Run As Invoker", then I think you may see the invokers context proagate through to the child process as well. But this difficult to manage because each of the service activities in the process will then get executed as the invoker (who may not have permission).

What is probably needed is a way for processes to propagate both an invoker's context (for security and authorization) and an original caller's context for (for tracking and user task audit) which Workspace could use. There may have been some improvements in Workspace Tracking though in ES2 and I will try to find out.

Gary.

[NW987]

Both of the long lived processes that I'm using are configured to run as invoker.  They are still being created by the system context account.  This is ES1(8.2).

[Gary_Gilchrist]

That is odd. I did beleive that when you set Run As Invoker on a long loved process, then that will set the execution context for each of the steps that are invoked via the Work Manager (thus overriding the default behavior) but I will double check for you (maybe it was a chnage in behavior in ES2)