A UMO is implemented as a standard POJO. You have two options for implementing a UMO:
Implement your own POJO.
Implement the org.mule.umo.lifecycle.Callable interface.
If you implement your UMO using your own POJO, the router core chooses the appropriate method to invoke based on the payload of the message. For example, if your route is using the payload data mode the router core would invoke a method that takes PayloadMessage object as its input parameter. If the router core cannot find an appropriate method to invoke, it will through an exception.
|
Tip |
|---|---|
|
If you are using the message data mode, you will need to use the transformers that convert between the input streams and strings. Therefore, when using the message data mode, the router will attempt to invoke a method that takes a String on the first UMO in a chained route. |
If your UMO implementation returns data it should be consumable by the next UMO in the chain.
If you chose to implement your UMO using the org.mule.umo.lifecycle.Callable interface, shown in Example 7.1, “The Callable Interface”, the router core will always invoke the onCall() method.
Example 7.1. The Callable Interface
public interface org.mule.umo.lifecycle.Callable {public Object onCall(UMOEventContext eventContext)
throws Exception;
}
For more information about implementing the org.mule.umo.lifecycle.Callable interface see http://mule.mulesource.org/wiki/display/MULE/Writing+Components.
Example 7.2, “A POJO Based UMO” shows a UMO implemented as a POJO. It is implemented to expect a String as input.
Example 7.2. A POJO Based UMO
public class BadGuy {
public List<String> messUp(String message) {
String badString = "XXXXX";
String goodString = "soap";
List<String> retval = new ArrayList<String>();
System.out.println("BadGuy receives: " + message);
String badMessage = message.replaceAll(goodString, badString);
retval.add(badMessage);
retval.add(badString);
retval.add(goodString);
return retval;
}
}