Using Hibernate with Mule ESB – Part 2

In our previous post we explained how to work with Mule and Hibernate using an interceptor that makes every method invocation transactional. In this post we will show how to simulate the open session in view pattern (used in Web apps) for each flow.

To do so, we will assume that we have the following simple flow that receives messages from a HTTP endpoint and chains 3 services in a flow:

We want to reuse the open session in view concept for our HTTP flow. To do so, I have created 2 MessageProcessor that opens and closes the hibernate session. Their implementation is as follows:


The HibernateSessionAdvice class is an adapted copy of OpenSessionInViewFilter; you can find the implementation here. The last step is to modify our HTTP endpoint to open and close the hibernate session using the previously created MessageProcessor. We modify our configuration and flow as follows:

Hope it helps and happy hacking!

Using Hibernate with Mule ESB – Part 1

If you are looking to use Hibernate with Mule ESB this is your place. Though Mule has a Hibernate transport, it is out date and it won’t work with Mule 3.
In this series we are going to explain different scenarios where you can integrate these technologies.

Let’s begin with something simple; suppose we are building an application that reads from a JMS queue and you would like to invoke a method in MyService Spring bean. Let’s assume we have the following Spring configuration:

and it’s implementation is as follows:

following our implementation you may try the following configuration for our scenario (assuming that the elements in the queue are long paramenters):

This implementation assumes that a Hibernate session exists for the current Thread; something typical in Web applications using the Open session in view pattern. Well in this case it won’t work because nobody has created a Hibernate session for you.

How to fix it?

There are several ways, in this case we are going to open the session and make the invocation transactional. To do so, first create 2 interceptors: a transaction interceptor and the hibernate interceptor.

Then you can refactor the Spring config as follows using the Spring’s ProxyFactoryBean:

Finally you will need to add a default constructor to be able to proxy your com.MyService class as follows:

Hope you like the post and stay tuned; we will present more alternatives to use Hibernate with Mule soon…

Working with SOAP attachments using Mule’s CXF module

It is pretty common that you may need to add/extract attachments when working with SOAP based Web services (WS). In this short blog post we explain how to do it using Mule’s CXF module.

Receive and extract attachments

When you are receiving a SOAP message, the first thing you must know is that Mule does not copy SOAP attachments to your Mule message. If you want to do so, you will need to add a special CXF interceptor to do it (CopyAttachmentInInterceptor). The next code snippet shows how to add that interceptor:

All the attachments are copied to the cxf_attachments INVOCATION property of the message. Notice that the value of that property is a COLLECTION of attachments. To work with attachments you can use the expression transformer, for example the following code snippet extract the contents of the first attachment of the list and sets it as the current payload of the message:

Add attachments and send

On the other hand, if you want to send attachments to a WS you will need to create the cxf_attachments property and then use the CopyAttachmentOutInterceptor interceptor to copy those attachments to the SOAP message. The following code snippet adds an attachment and calls the WS:

The AddAttachmentMessageProcessor class is responsible of creating the attachments collection and set it in the cxf_attachments property. The class itself is pretty simple, just adds the attachments as a property of the message:

Hope you like the post!

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.

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!

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” (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.

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

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

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.

Input streams aren’t lazy enough?


While I was working in the refactoring of the PGP module of Mule, I faced the problem that input streams weren’t lazy enough for me. Let me introduce the scenario; for those of you who are not familiar with Mule, Mule is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data. Data is carried in messages that contain a payload (data, e.g. the contents of a file) and can be transformed and written to an endpoint (a different directory, post the information to a URL, etc).

In many situations the payload of the messages could be huge enough and may not fit into memory. To avoid this problem, Mule allows the developer to configure the messages in streaming mode. This works fine for small streams and for big streams that don’t need to be transformed. However when we need to transform those streams without having to write a temporal copy to disk, we get an OutOfMemoryException exception as Mule tries to load the contents into memory to perform the transformation. That was my scenario, I need to encrypt big files but without having to write temporary files to disk. A big picture of the scenario is shown in Fig.1 where you can see that files in the form of messages are polled from a directory, move through a flow and occasionally encrypted and written to disk.

Fig. 1. Scenario


The main idea of the solution is to have an intermediate object that wraps the original input stream and will start the encryption process only when other object needs to read something from the stream. I called this object LazyTransformedInputStream which represents an input stream that is going to be lazy transformed. The first proposal was configuring this object with a transformation that will perform the encryption. The idea of having a transformation is because we would like to have lazy decryptions or any other lazy transformation (e.g. compression). Fig. 2 shows the first sketch of the classes:

First sketch of classes
Fig. 2. First sketch of classes

Everything was perfect in theory but in practice I had some problems; when I tried the solution using the Bouncy castle PGP implementation I realized that on the decryption case it was not going to work. 100 encrypted bytes may represent a fewer number of decrypted bytes (e.g. 30 bytes) and features like encryption + compression may required more bytes to be read. On the other hand, a simple transformation like increasing by 1 the byte read will produce 1 byte and therefore will be easier to implement. In general, this scenario may happened on more cases like compression; therefore I modeled both scenarios as different TransformPolicy subclasses. Each policy works different regarding how many bytes are transformed:

  • TransformPerRequestPolicy: will transform only the bytes requested.
  • TransformPerRequestInChunksPolicy: will transform only the bytes requested but in chunks. For example if we configure this policy with a chunk size of 10 bytes and some object requests 2 bytes, the policy will force to transform 8 bytes more (or until the end of the stream).
  • TransformContinuouslyPolicy: will transform all the bytes without waiting them to be requested (decryption case).

You can see a summary of the classes in Fig. 3 and you can check the behavior of the classes in LazyTransformedInputStreamTestCase test case.

Final version of the classes
Fig. 3. Final version of the classes

Technical aspects

Last but not least, we have to mention a small but important thing about how LazyTransformedInputStream works. On the one hand, there is an object the reads from the transformed stream and needs to be delayed when the information has not been transformed. On the other hand we have the transformation process that should run on a different thread. Trying to execute both processes in the same thread will probably cause deadlock.

Internally, each TransformPolicy has a thread that is the one who executes the transformation code. We reuse the existing PipedInputStream and PipedOutputStream of for this task. The object who wants to read the transformed stream will read from the PipedInputStream and the transformation will output the transformed bytes into a PipedOutputStream instance. In addition, the transforming thread needs to be kept alive till the object that consumes the PipedInputStream does not want more bytes so that the pipe doesn’t break. In our implementation, we terminate the thread either when the LazyTransformedInputStream is closed or when the LazyTransformedInputStream is finalized.

We did a memory profiling of the implementation with great results in the PGP module and can be found here.

Hope you enjoy the post and looking forward to hearing your comments!!!