After many years of following what is happening in the BPM world, I have gotten round to properly integrating BPM in a real project. This is a project which includes an approval process including spatial evaluations. The plan was to build it around Activiti and Geomajas. Because of budget restrictions, they two parts are conceived as independent applications which use mutual links to connect the two parts.
The good news is that it all worked. There are some things I would do differently if I knew what I know now.
I started building the process in the Activiti modeler. This is a very nice web application which allows you to easily build your process diagram. There is nothing to install (apart from Activiti itself) and it works really nice and is user-friendly. Until you want to make your process runnable that is. The process I built could not be loaded by Activiti. So I switched to the Activiti designer application. This is supposed to import the models from the Activiti modeler without problem. Apparently not. You are better of immediately starting with the Activiti Designer. It takes a bit of getting used to if you are not used to Eclipse but the application itself is really nice and works well.
On to the next step, building the BPM dashboard. The plan was to reuse and customize the Activiti explorer. I expected to be able to download the application and use that as war overlay. Don’t work. So I copied (should I say forked) the original project to customize, trying to build one war for the front-end. Turned out to be a lot of work (meaning I gave up). As an end result, I just copied the Activiti Explorer and Activiti REST wars produced by the Activiti installer and explained what changes are necessary to make it fit in our environment. Previously, in their pre-Activiti days, I heard some of the Activiti developers claim that there is no need to develop your own BPM user interface. It seems they are no longer going that path.
Once the initial hurdles were taken, it was more straightforward. The process was running nicely. What remains is connecting the two applications. From the BPM dashboard, you need to be able to go to the mapping application to investigate some data. In some cases, the actual work is done in the mapping application and the “finish task” should actually be handled there instead of in the BPM dashboard.
To link to the mapping dashboard, a Spring bean was written which knows the URL of the other component and builds a link which includes the necessary query parameters. Unfortunately, tweaking Activiti explorer to use a spring enabled engine is non-trivial. The following steps were needed:
- I had to replace the ActivitiWebScript and ActivitiStreamingWebScript classes by variants which allow the processEngine to be set using Spring.
- I had to copy activiti-spring, spring-tx and spring-jdbc into the WEB-INF/lib folder of the Activiti REST application.
- In Activiti REST’s WEB-INF/classes/web-application-context.xml I inserted the following
<context:component-scan base-package="mypackage.bpm" /> <bean id="ktunaxa" class="org.ktunaxa.bpm.KtunaxaConfiguration"> <property name="mapDashboardBaseUrl" value="http://localhost:8080/map/"/> <property name="bpmDashboardBaseUrl" value="http://localhost:8080/activiti-explorer/"/> </bean> <bean id="dataSource" class="org.springframework.jdbc.datasource.SimpleDriverDataSource"> <property name="driverClass" value="org.postgresql.Driver"/> <property name="url" value="jdbc:postgresql://localhost:5432/db"/> <property name="username" value="un"/> <property name="password" value="pw"/> </bean> <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration"> <property name="dataSource" ref="dataSource"/> <property name="transactionManager" ref="transactionManager"> <property name="databaseSchemaUpdate" value="true"> <property name="jobExecutorActivate" value="true"> <property name="dbCycleUsed" value="true"/> <property name="deploymentResources" value="classpath*:diagrams/.*.bpmn20.xml"/> </bean> <bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean"> <property name="processEngineConfiguration" ref="processEngineConfiguration" /> </bean>
- In the same file, for both the activitiWebScript and activitiStreamingWebScript beans, add the following setter
<property name="processEngine" ref="processEngine"/>
- To allow using HTML links in the task name or description we had to disable HTML code escaping. This was done in components/tasks/task-list.js in the activiti-explorer webapp. Lines 196 and 197 (Activiti 5.4) contain some $html() which should just be replaced by whatever is insie the brackets.
Building the link to go to the mapping application is done using this code
public String getUrl(DelegateExecution execution) {
String objectId = (String) execution.getVariable(VAR_OBJECT_ID);
return mapDashboardBaseUrl + "?" + QUERY_OBJECT_ID + "=" + objectId + "&" + QUERY_TASK_ID + "=" + execution.getId();
}
This code is in a Spring wired class to allow using it as ${myBean.getUrl(execution)}
in the process definition.
When the actual task finishing needs to be done in the mapping component, a form like the following is used
<div>
<p><a href="${myBean.getUrl(execution)}">Object in the mapping component</a></p>
<script type="text/javascript">
<!--
window.location = "${myBean.getUrl(execution)}";
//-->
</script>
</div>
Using that execution id in the mapping component to finish the task can be done using code like
Task task = taskService.createTaskQuery().executionId(taskExecutionId).singleResult();
if (task != null) {
taskService.complete(task.getId());
}
The application then redirects back to the BPM dashboard.
Deploying works nicely in the Activiti probe application. I was expecting to be able to have it easier by using the deploymentResources engine configuration. I may have done something wrong, but it unfortunately did not work. It is needed in install the process stuff both as jar in WEB-INF/lib of Activiti REST and deploy it using Activiti Probe. The mapping component uses a plain Spring engine configuration which accesses the same database as the Activiti REST web application.
Conclusion, it works! However, the customer now wants the BPM front-end to be customized (e.g. allowing sorting of issues, reassigning tasks etc). The original effort of trying to figure out how to combine the independent web applications may have been spent better by building my own BPM front-end.
Nice read, but I wonder where you got
“I heard some of the Activiti developers claim that there is no need to develop your own BPM user interface. It seems they are no longer going that path.”
Can only imagine one person having said that and he was only partiall involved in the Activiti predecessor. Most said it was for demo purposes only