Business Scenario: Order-Processing Service
I have found that many organizations often prefer to leverage simple and widely established technical methods for the implementation of business processes rather than complex and sophisticated methods. Channels such as very simple form-based web submissions or e-mail channels are often the methods of choice for the implementation of important business functions.
This article presents the implementation of one such business function: submitting orders via e-mail into a RESTful web service and verifying the order quantities against a corporate warehouse before the order is submitted. It uses Mule to wire up these processes using mostly built-in Mule components with very little custom coding. This implementation will demonstrate how Mule ESB can save time and simplify the implementation of business functions, as well as add significant value.
To implement the order-processing service on Mule ESB, you first need to define the service itself using Mule's service definition syntax:
<service name="Order Submissions">
Orders are received as pre-formatted e-mails. Each line is prefixed with a label for the data it contains: name, address 1, address 2, city, state, zip, phone, comment, and item.
name: John Doe
address 1: 123 Some Street
phone: 012 345 6789
comment: please expedite
item: automatic blender
item: rotary circuit
For Mule ESB to pick up these messages, you first need to configure the POP3 transport and the transformer that will translate the messages into the appropriate format. The following XML shows the Mule ESB configuration for the POP3 transport and for the custom translator that translates the incoming plain text messages into an XML message that will be submitted into a backend web services:
<property name="checkFrequency" value="120000"/>
Notice how the POP3 configuration is defined. Many defaults, such as POP3 port number, are omitted. Refer to POP3 adapter messages on the public forums for more details on other options and defaults.
Transformation is a chained process. In other words, transformers can be chained to each other, similar to how pipes in UNIX/Linux allow a process to take inputs from another process and pass outputs to another.
To transform the e-mail message into XML that will work with a back-end service, this example uses two transformers:
- EmailMessageToString: a transformer supplied by Mule ESB
- orderprocessing.OrderSubmissionsMailtoXMLTransformer: a custom transformer
In order to be recognized as a custom transformer, orderprocessing.OrderSubmissionsMailtoXMLTransformer has to be implemented as an extension of the Mule ESB AbstractMessageAwareTransformer transformer (org.mule.transformers.AbstractMessageAwareTransformer). It also requires the implementation of the abstract method abstract Object transform(MuleMessage message, String outputEncoding).
The custom object simply parses each e-mail message line by line and produces the following XML:
<?xml version="1.0" encoding="UTF-8"?>
<address1>123 Some Street</address1>
<phone>012 345 6789</phone>
<item_name>rotary circuit </item_name>