May 17 2011

Integrating Activiti BPM with JMS

Activiti is a light-weight workflow and Business Process Management (BPM) Platform targeted at business people, developers and system admins. However, its standard version doesn’t allow to integrate with your existing enterprise technologies (e.g. your JMS broker). In this post we will briefly explain how to integrate Activiti with JMS using Mule’s Activiti Module.

First, you will need to run Activiti in embedded mode inside your Mule application; it is pretty similar to run Activiti inside Spring. An example configuration is shown next; you will need to define your processEngineConfiguration and the service beans you can obtain from it:

Then you will also need to define your JMS broker; in our case we will use Active MQ:

Finally, your Mule’s Activiti connector:

We are ready!
For our example, let’s suppose we have a process for managing orders that waits for the approval of a manager:

The manager approves them by submitting a message to the JMS queue approveQueue. To resolve which process needs to be approved the message must contain the process id and the username which will be set in the approvedBy variable. For the sake of conciseness, we will create the process from Mule as shown next:

This process will start and wait for a message in the JMS queue to signal it. This can be easily solved from the Mule side by specifying a flow that reads from a JMS queue, sets the variable approvedBy and signal the process as shown next:

Want to see the full example? Check our git hub repository for Activiti examples. Hope you want to start integrating Activiti with your existing enterprise environment using Mule’s Activiti Module and I look forward to your comments.


May 11 2011

Did your business people fall in love with Salesforce? If so, integrate with it from Activiti!

Salesforce is the cool CRM who is starting to be used in almost any organization. Sadly for us (the developers) we will need to integrate with it soon. If you are using a BPM like Activiti, you may need to integrate sooner as the growing demands of business people. In this post we are going to show how to create a Salesforce contact from your Activiti process using the Mule’s Activiti module and the upcoming version of Activiti 5.6.

In our case, we will simulate that we need to create a Salesforce contact from our Activiti process. We will perform this task by calling a Mule endpoint and passing the necessary information as shown next:

The sendTask invokes the mule endpoint vm://createSalesforceContactFromActiviti which will receive the message with the necessary information to create the contact:#{firstName},#{lastName},#{email},#{title},#{phone} (where #{firstName} refers to the value of the variable firstName in the context of the process). Then we need to define the endpoint in the Mule’s side; the flow is simple and is shown next:

The sfdc:create type=”Contact” tag is the one that executes the contact creation in the Salesforce account. This information is stored in the payload of the message and need to be splitter (as it is comma separated) and then stored in the message’s headers so that we can reference them using: #[header:OUTBOUND:FirstName]. To do that we code the custom message processor SplitAndSetFieldsProcessor:

That’s it; so simple! Check the results:

Want to check a full running example? Check the full project with tests included at our GitHub repository. Also check the documentation of the Salesforce cloud connector for further configuration details.

Looking forward to hearing your comments!


May 10 2011

Want to tweet from your Activiti process?

Any BPM (specially Activiti) has integration requirements. For instance, in a customer order we may have multiple products and the customer may want to make public its purchased in his Twitter wall. So how can we publish this information in Twitter? Using the Mule’s Activiti module and the upcoming version of Activiti 5.6.

In our case, the process order will have a send task that invokes Mule to publish the information in Twitter. For the sake of conciseness we will keep the process definition simply:

The sendTask invokes the mule endpoint vm://tweetFromActiviti which will receive the message “I have just purchased a #{productName} from Mulesoft.com” (where #{productName} refers to the value productName in the context of the process).

Then we need to define the endpoint in the Mule’s side; the flow is simple and is shown as follows:

The twitter:update-status tag is the one that executes the update status to the user’s twitter wall. For simplicity we use the same user on each status update; all this information is configured in the twitter connector in Mule:

That’s it; so simple! Check our user’s twitter wall.
Want to check a full running example? Check the full project with tests included at our GitHub repository.
Also check the documentation of the Twitter cloud connector for further configuration details.


Feb 20 2011

Activiti + Mule ESB – Part 2

In the first part of this post we show how to start an Activiti process from Mule ESB using the new Mule’s activiti module. In this part we are going to show how to call a Web Service from Activiti that is going to be contained in Mule. Notice that you can expose anything as a Web service in Mule such as: beans, queues, etc.

Activiti configuration

First of all we need to create our proces. It will receive a request containing the username that has requested the image and the image name. The process will work as follows: check if the image needs copyright; if it needs copyright then allow the owner to approve or disapprove the request. If the request is approved, then charge the requester otherwise cancel it. In case that the image doesn’t need approval, just charge the requester with the cost.

Continue reading


Feb 17 2011

Activiti + Mule ESB – Part 1

We are pleased to announce Mule 3 Activiti support. We’re very happy to be working with the Activiti team and see a lot of value for our community using Mule and Activiti together. I already discussed why BPM and ESB need to work together and two different uses of ESBs with BPM. Today I am going to present a real world example.

For those that may not be familiar, Actiiviti is an open source BPMN 2.0 modeling tool and BPM runtime, founded by Alfresco and developed with other open source companies.

Getting Started

My example application uses Mule ESB and Activiti allowing users to view low-resolution images and request a high-resolution version that needs to be approved by a human participant (similar to Stock.XCHNG). Mule will handle the creation of the Activiti process and will take care of exposing it as a service. Activiti will take care of orchestrating the process that requires a user task (approval).

Continue reading


Jan 11 2011

Why ESB + BPM?

While should we use an BPM like Activiti with an ESB like Mule ESB?

Well, a BPM is a management approach focused on aligning all aspects of an organization with the wants and needs of clients. A BPM helps business people to define their organizational’s process and users are able to participate in those process by providing input and actions. However on several cases a process may need to interact with different systems that may already exist in the organization; that’s where ESBs are a strong player. Therefore the integration between both products seems reasonable in this case.

A typical scenario would be starting BPM process using the messages stored in a JMS queue. Obviously, we don’t want to duplicate the functionality already present in a ESB into a BPM just to read JMS messages. A picture of this scenario is shown in Fig. 1.

Using a ESB as a source for starting/manipulating processes

Fig. 1. Using a ESB as a source for starting/manipulating processes

A different but typical scenario in enterprise applications is dealing with existing components of the organization. For example, while we run a process we need to call an existing EJB to execute some business logic (e.g. to charge a credit card) and the EJB could exists in the ESB space. We expect to easily expose the EJB using the infrastructure existing on the ESB to be used by the BPM. A picture of this scenario is shown in Fig. 2.

Using a ESB to connect existing components

Fig. 2. Using a ESB to connect existing components

We must notice that there is a difference between both scenarios; in the first case, the ESB is used as a source for starting the process and it doesn’t play an important role in the process flow (the ESB is more passive). In the second scenario the call to the EJB is key in the process flow and therefore a bit more critical (the ESB is more active).

As a summary the two scenarios described above use the ESB as:

  • A source for starting/manipulating processes.
  • To connect existing components like EJBs, Web services with the BPM.

Am I missing any scenarios? Feel free to comment. I hope to post how to cover both scenarios using Activiti and Mule soon.


Nov 1 2010

Announcing Mule’s Activiti transport

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.

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:

[sourcecode language="xml"]
<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>
[/sourcecode]

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:

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

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.

[sourcecode language="xml"]
<activiti:inbound-endpoint activiti-server="actServer">
<activiti:list-candidate-tasks user="pablo" />
</activiti:inbound-endpoint>
[/sourcecode]

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.

[sourcecode language="xml"]
<activiti:outbound-endpoint activiti-server="actServer" >
<activiti:perform-task-operation operation="CLAIM" />
</activiti:outbound-endpoint>
[/sourcecode]

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

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!