Processes, EPA Taskbox and Multi-Tenancy

Processes, EPA Taskbox and Multi-Tenancy

  
Good morning all!

I am looking for some insight and thinking please with a challenge that we're facing when using Processes, Multi-Tenancy and an administrative back office across all tenants.

The scenario we have is as follows: The client has a multi-tenant application that allows their sub-agents access to segregated data and functionality. The client also has a related back office application that is not multi-tenant and allows access to the full data set across all tenants (using the "Show Tenant Identifier" flag approach on referenced Entities) for administrative purposes. This all works well.

The challenge we are facing is as follows: We have a use-case that requires a sub-agent user to initiate a Process Flow from the multi-tenant application, and have the process show for approval by a back office user on the administrative (non-multi-tenant) application. What is occurring is that the multi-tenant user can see the entry in their EPA Taskbox, but the back office user sees nothing in their Taskbox. My assumption is that this is related to the fact that the Process is being created by a multi-tenant application - is there a way on the Back Office eSpace to allow the users access to all running Processes, in the same way that I can see all the multi-tenant Entity data by setting the "Show Tenant Identifier" flag on those Entities?

Some notes:
- For testing purposes I've expanded the Roles of the Human Activity elements in the Process Flow all the way to "Registered" so as to remove the possibility of Role association being the issue. I have also ensured that none of the Human Activity elements have explicit "User" properties.
- I've gone through all the eSpaces (multi-tenant and back office) and confirmed that their "User Provider eSpace" is set to "Users".
- I created the Process Flow in the back office (non-multi-tenant) eSpace, which is referenced by the multi-tenant application. This eSpace also holds the Role definitions used by both the back office and multi-tenant applications.
- I created back office user through the standard "http://<environment>/Users" application, and the multi-tenant user through the TenantManagement Forge application.

Any help would be appreciated!

Thanks

Charl
Hi Charl,

I can only think of a way to do it.
A process can only be visible on a single tenant and users from other tenants cannot see or interact with them (tecnically the user created in the Users eSpace is still a multi-tenant user that belongs to the "default tenant").

Also it doesn't make a difference if the process is defined in the back office eSpace, they all belong to the Users user provider, so they are still in a multi-tenant context (note: this is good, my suggestion would not be possible if the user providers were different!)

The way to do it is to add a OnProcessStart callback in your process and to switch it's tenant.
By default the Tenant is set to one that triggered the process launch, regardless if it's referenced from a different eSpace.



You may need to add the TenantSwitch action from the System reference.


And use it in the OnProcessStart action to switch to the tenant of the user that needs to do the approval.


Regards,
João Rosado

I'm reviving this thread because I tried this tenant switch OnProcessStart method and it apparently caused concurrency issues when launching processes.

There's no issue creating a single process at a time, but when I launch, for example, 100 processes in the same second, I start seeing many deadlock errors in the error log and the processes fail to start with this message "Could not execute a built-in/extended action on activity 'Start' (#9750977) because the activity does not exist".

I believe it is because of the tenant switch because removing it stops the deadlocks (although it causes other errors related to data not being visible, since the process is running on the wrong tenant).

João Pedro Abreu wrote:

I'm reviving this thread because I tried this tenant switch OnProcessStart method and it apparently caused concurrency issues when launching processes.

There's no issue creating a single process at a time, but when I launch, for example, 100 processes in the same second, I start seeing many deadlock errors in the error log and the processes fail to start with this message "Could not execute a built-in/extended action on activity 'Start' (#9750977) because the activity does not exist".

I believe it is because of the tenant switch because removing it stops the deadlocks (although it causes other errors related to data not being visible, since the process is running on the wrong tenant).


What version are you on? I tried TenantSwitch in a process in 9.1 a few weeks ago and it wouldn't let me do it at all. Since processes are tied to tenants, that error message makes perfect sense.

J.Ja

I'm on 9.1.501.0.

The OnProcessStart event of a process is the only point where a tenant switch works. Anywhere else throws an error.

From what I saw, doing a tenant switch inside OnProcessStart will cause the platform to update the tenant_id on the process and on its underlying activities. This works well for low concurrency scenarios, but if there are many processes being updated concurrently, it will cause deadlocks.


In the database I could see many instances where statements like this one:

UPDATE OSSYS_BPM_PROCESS_INPUT SET TENANT_ID = @NEWTENANTID WHERE PROCESS_ID = @PROCESSID AND TENANT_ID = @OLDTENANTID

Were being blocked by statements like this one:

SELECT  ACTIVITY_DEF_ID, PROCESS_ID, USER_ID, STATUS_ID, IS_RUNNING_SINCE, IS_RUNNING_AT, NEXT_RUN, PRECEDENT_ACTIVITY_ID, PRECEDENT_OUTCOME, DUE_DATE  FROM OSSYS_BPM_ACTIVITY WITH ( UPDLOCK ) WHERE  TENANT_ID = @TENANTID AND ID = @ACTIVITYID


I ended up copying all the code I needed the process to execute to a new eSpace and exposing the tenant IDs on all the entities, so the process could run without the need for a tenant switch.


For future reference, I tried creating a semaphore (by obtaining an exclusive table lock, held until the end of the transaction, on a dummy table) before doing the a tenant switch. It solved the deadlocks, but caused some processes to fail the Start activity and not retr ity, becoming stuck.