nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Running Activiti on WebSphere Application Server

b_schnarr

We want to execute Activiti 5.15 on a WebSphere Application Server. I googled a lot and the only thing I found is the message that this would be very tricky.

Therefore my question: is there any tutorial / documentation for this?
Are there any restrictions or developing tasks to get Activiti work in WebShpere?

Thanks and best regards
Ben

Find more posts tagged with

Comments

trademak

Hi Ben,

I'm not aware of issues with WebSphere Application Server. Or you going to use the Activiti Engine embedded in your application?

Best regards,

b_schnarr

Hi Tijs,

Activiti shall be executed standalone on a WAS. Are there any experiences?

Thanks and best regards
Ben

jkronegg

We have some issues with WebSphere 8.5 and Activiti when used in CDI mode, but I don't think it's related to WebSphere.

How would you use Activiti with WebSphere? With or without CDI ? With which EAR structure ?

b_schnarr

We want to use the simpelst possible deployment. Therefore, we want to deploy both war-files (activiti-explorer.war, activiti-rest.war) to WAS, configure them to use LDAP and a MySQL-Database. Nothing else.

And here the question: Are there any problems known?

Thanks and best regards
Ben

jkronegg

We successfully deployed activiti-explorer.war to WebSphere 8.5 with DB2 and default users (i.e. no LDAP).
However, we did not tried activiti-rest.war.

b_schnarr

The reason why I´m asking is that according to this here: http://www.bpm-guide.de/2012/01/22/run-activiti-on-ibm-websphere-application-server-with-camunda-fox/

WAS does not offer the Standard Java Transaction APIs which are needed by Activiti. Did you have to make some special configurations in the activiti-ui-context.xml or on other places to make Activiti run on WAS? How did you solve this transaction problem?

Thanks for your answers and best regards
Ben

bardioc

Hello Ben,

we are currently running Activiti successfully under WebSphere Application Server 8.x. You are right, there are some things to take care of, mainly transaction handling and asynchronous support via managed threads.

While the first is rather easy as Activiti supports Spring and Spring has a generalization of a transaction management which includes the use of WebSphere UnitOfWork Transaction management, simply search for an Activiti setup utilizing the WebSphereUOWTransactionManager and the SpringProcessEngineConfiguration. This shall lead you into the right direction. If this does not help, simply reply here and I will try to give further information. If your project does not allow spring, you are screwed here. We don't use (and don't like) Spring, and use it only because of its adaption for transaction management in our application designs. We rather stick with CDI which works great in combination with Activiti. For that to work, you'd have to combine the setup found in the SpringProcessEngineConfiguration with those found in the CdiProcessEngineConfiguration which is quite easy as there is not much added here.

The second part, asynchronous support is actually more difficult, cause Activiti by default does not use managed threads in a JEE environment, thus you loose the JEE context as soon as your application becomes asynchronous. This includes JNDI lookups, EJB (including transaction management) as well as CDI. The worst part here is, that WebSphere does its own thing for handling 'managed' asynchronous threads. Only the Liberty Profile of WAS supports the JEE 7 ManagedExecutionService. For earlier versions of WebSphere we simply applied the following scenario:

We subclassed the JobExecutor and the AquireJobsRunnable and let these use a programmable JEE timer (via TimerService) instead of a simple thread. The programmable timers timeout()-method works exactly as the AquireJobsRunnable run()-method (without the unnecessary endless while-loop). By default the timer goes off every 5 seconds to check whether there is work to do. It then is rescheduled for the next round (making it possible to even fire right away in case multiple jobs need to be handled) or in time frames shorter than the 5 seconds if work is due in less than these 5 seconds.

Our version of the Job Executor (see the DefaultJobExecutor) is again done asynchronously as proposed by Activiti. To make sure, the whole JEE context will be active, we simply lookup a local EJB via JNDI from our Job Executor and call a method annotated with @Asynchronous within it, passing in the ExecuteJobsRunable which is then executed within the asynchronous method (obviously asynchronous and transactional). This works great even with CDI. One could think of using a WorkManager here too (WebSphere supports commonj.WorkManager API) but the easy API of just annotating a method within a Stateless bean with @Asynchronous made our work so much easier.

One thing you must be aware of is in case you are using JPA entities within your process as process variables and become asynchronous, the JPA entities will ALWAYS become detached, as their attachment is based on the EntityManager from the previous thread. So in case you become asynchronous, the first thing to do is to reattach your entities.

This all would have been much easier, if Activiti supported an easier plugin-interface to change the underlying implementation of the task manager. The drawback of our solution is, that we have a different way of 'AquireJobsRunnable' and we must take care, that this implementation is consistent with Activiti (there was actually a slight modification between 5.15 and 5.16-SNAPSHOT).

Just one note to Camunda. They've taken a completely different approach of implementing container managed asynchronous support via JCA and a MessageDriven Bean. This approach is far more complex and does not work with Activiti, as Camunda needed to change the Job Execution Framework quite a lot to fit this in. Additionally, Camunda offers WebSphere support as a enterprise supported platform.

Regards,

Heiko

jbarrez

Wow, Heiko! Many thanks for writing this down so detailed! This is really useful information for many!

b_schnarr

Indeed, thank you very much for this! I will try it out. If there are any further questions, I would post again on this thread.

Thanks and best regards
Ben

jayblanc1

Hi Heiko,

I'm pretty intrested in your solution. I'm working on wildfly but I had the same approach than you to inject the container managed thread pool executor provided by JEE7. I have wrote my own JobExecutor and everything works fine as asyn service tasks are executed in manged thread according to log.
Now I'm facing another problem regarding authentication. When calling EJB from Service Task, initial context of workflow execution (aka the initier logged in when starting the workflow instance) is lost when service task execute and, because I use security domain, unauthentified service task thread is not able to make the EJB call due to security restrictions…
Before embedding activiti in my application, I had code a very simple task manager which was using an Executor too but also the ContextService in order to create Threads keeping the original EJB caller SecurityContext…
I don't see how to handle security problem (a kind of runas) from the activiti async thread to be able to be authentified…
I haven't understand precisly where you use the @Asynchronous EJB call in order to keep some Context information like Transaction and if it is suitable for my needs.
Could you please give me some sample code or a little bit more information about your solution ?

Best Regards, Jérôme.

mvharish

Hello Heiko,
Nice explanation you have provided , but what i have found is that by using Activiti with SpringprocessEngineconfiguration over websphere in a jndi based datasource we will always be connected to public schema and no where i have found that we can specify our own schema if we use jndi based datasource for that approach we need to use jdbc type datasource which is sometimes not desirable.

Thanks,
Harish

jbarrez

Is this specific to jndi? Or is this a general Activiti problem?

mvharish

it looks like activiti problem as specifying datatableprefix prefix in SpringProcessEngineConfiguration doesnt takes the value as database schema in the jndi datasource.

mvharish

am using below configuration
<bean id="transactionManager"
class="org.springframework.transaction.jta.WebSphereUowTransactionManager"/>

<!– process engine configuration –>
<bean id="processEngineConfiguration"
class="org.activiti.spring.SpringProcessEngineConfiguration">
<property name="dataSourceJndiName" value="XXXWDS" />
<property name="databaseTablePrefix" value="ACTIVITI." />
<property name="databaseSchema" value="ACTIVITI" />
<property name="transactionManager" ref="transactionManager" />
<property name="transactionsExternallyManaged" value="true" />
<property name="databaseSchemaUpdate" value="false" />
<property name="mailServerHost" value="localhost" />
<property name="mailServerPort" value="2525" />
</bean>

<bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean">
<property name="processEngineConfiguration" ref="processEngineConfiguration" />
</bean>

<bean id="repositoryService" factory-bean="processEngine" factory-method="getRepositoryService" />
</beans>

but it gives me empty stack trace error

jbarrez

an empty stack trace? that sounds very strange.

The prefix is applied to all queries through MyBatis, so it shouldn't matter which approach you use, jndi or direct. When do you see that it is not workin? During boot? Or during some process execution?