Reading Time: 5 minutes

Hi all!

A couple of weeks ago I started the integration between Mule ESB and Activiti BPMN. Activiti is a Business Process Management (BPM) and workflow system targeted at business people, developers and system admins. Its core is a super-fast and rock-solid BPMN 2 process engine for Java. It’s open-source and distributed under the Apache license. Activiti is being written from the ground up with the requirement that the engine should be easily embedded and that the project would be aimed at developers not the business. This is a very natural fit for MuleSoft since our approach to middleware starts with the developer. We have been working with the Activiti guys since July focusing in the integration aspects of the project.

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

The idea behind Mule’s Activiti transport is that you are able to perform several administrative actions in an Activiti server from Mule. For example, let’s suppose that you would like to retrieve the candidate tasks of the user kermit, do some processing and CLAIM a subset of those tasks. The following configuration will work for you:

<activiti:connector name="actServer"
    activitiServerURL="http://localhost:8080/activiti-rest/service/"
    username="kermit" password="kermit" />

<model>
    <service name="Activiti service">
        <inbound>
            <activiti:inbound-endpoint activiti-server="actServer">
                <activiti:list-candidate-tasks user="kermit" />
            </activiti:inbound-endpoint>
        </inbound>

        <component class="org.mule.transport.activiti.SelectTaskComponent" />
        
        <outbound>
            <multicasting-router>
                <vm:outbound-endpoint path="out" connector-ref="asynchVm" />
                <activiti:outbound-endpoint activiti-server="actServer" >
                    <activiti:perform-task-operation operation="CLAIM" />
                </activiti:outbound-endpoint>
            </multicasting-router>
        </outbound>
    </service>    
</model>

We next describe each part of the configuration, but for those of you who are familiar with Mule, the configuration is pretty straightforward.

Let’s start with the basics; for configuring the transport you need a connector. The connector will hold all the information related with the Activiti server such as server URL, administrative user and password, e.g:

Then you can configure an inbound endpoint for polling information from the Activiti server. For example the following endpoint polls the list of candidate tasks of the user pablo.

Finally, you can execute operations in the outbound endpoints. For example, the following endpoint executes the operation claim over the task that comes inside the message. The payload of the message must be a map which must contain a task id and a operation. If the operation inside the map is null then the default operation configured in the endpoint is used.

For further examples please check the following configuration files in the SVN:

  • activiti-processes-config.xml
  • activiti-tasks-config.xml

You can obtain a snapshot version of the transport from here. Currently the transport has been tested with Mule 2.2.6 and shortly with Mule 3.0.

In future releases we plan to cover more operations that could be perform on the server and let the user provide custom spring beans for operations that are not covered by the implementation.

Looking forward to hearing your comments!