E-mail support in jBPM 4

Today I would like to talk about one of the many automatic activities that jBPM 4 provides out of the box: sending emails.

For those of you who have been using jBPM for a while, you may remember that jBPM 3 offered you e-mail support in the following incarnations.

• node step visible in the process diagram
• action handler event not shown in the diagram
• task notification when an actor is assigned a task
• task reminder at specific intervals after task creation

The above functions were all implemented on top of a common infrastructure. Not all of them exposed the underlying capabilities consistently, tough. Moreover, the infrastructure was not modular. The template (entity), producer (control) and session (boundary) components were mixed together. Critically, more advanced capabilities were missing.

In the latest iteration, the email feature received input from a larger and more heterogeneous group of people, consisting of the core jBPM team, one consultant from a sister company and two community members. It took some time and many a compromise to come up with a solution that everyone liked. Nonetheless, the end result was much better than any of the participants would have achieved separately, in a true open source fashion.

The design criteria were:

• Clean, concise syntax
• Customizable mail composition
• Dynamic content templates
• Composite payload: HTML and attachments
• Multiple SMTP servers with address filtering
  

The diagram below depicts the design that realizes the above requirements. Immediately following is a description of the interaction.

1. The client of the mail subsystem requests its associated mail producer to produce email messages, reading variables from the given execution. The producer contains or references a template (not shown) which specifies the recipients and the content of the message.
2. The client retrieves the (shared) mail session from the environment and hands it the produced email messages. At this point, work from the perspective of the client is done. The rest is handled by the mail session.
   
3. The mail server is configured with one or more SMTP servers, each with separate filter and transport settings.
4. A mail server only sends messages to the addresses accepted by its filter.
5. Each mail server encapsulates the mail properties required to create a javax.mail.Session and retrieve the corresponding transport.
6. The transport is responsible for ultimately delivering the messages to their recipients.
   

Both MailProducer and MailSession are interfaces, allowing for customizable mail composition and delivery. The mail subsystem provides facilities for a client to read an arbitrary mail producer from a DOM element. In turn, the mail session implementation can be changed through the existing configuration binding mechanism provided by jBPM.

For more details on the mail features, please refer to the jBPM developers guide. In a future post I will focus on the mail usage model. Talk to you soon!