How does the shared engine look up the required resources for a process step invocation?

Question

I am using a shared process engine on WebSphere and I want to understand how the engine looks up the required resources (custom code shipped with my process application) for a process step invocation. Is a thread context switch applied?

Answer 1

The shared process engine can be used by multiple applications, one of these applications being the Camunda webapplication.
Whenever the process engine "does something" within a process instance, such as executing a service task, it performs a Thread Context Switch. This Thread Context Switch is performed to the application which deployed the BPMN process that the engine is currently executing. This is necessary for the process engine to be able to use resources locally available within that application.

Examples for these kinds of resources:

• The application's classloader, in order to instantiate Java Delegates
• The application's CDI Bean Manager, in order to be able to invoke CDI Beans.

How does this "Thread Context Switch" work technically?
The process engine executes a callback method on an EJB which has to be included within the application. This is why you include the camunda-ejb-client.jar. Relevant information: the process engine invokes the local business interface of that EJB.
As a result, the Thread Context Switch is performed with EJB local invocation semantics. Whatever Websphere puts in place for an EJB local invocation will work and whatever Websphere does not put in place for an EJB local invocation will not work.
The behavior is exactly the same as it would be if you would put the code from your Java Delegates into an EJB with a local business interface and invoke that from another application.