Mule message
- 1. Mule Message
- 2. | ©2013, Cognizant 1 Mule Properties and FlowVariables are one of the most widely used features in Mule. Nevertheless, Mule newcomers may have a hard time understanding how the different property scopes and variables compare to each other, and how to choose the right one for their use cases.
- 3. Messaging Framework A message is simply a packet of data that can be handled and sent between applications on a specific channel (also called a queue). Many applications don't have the ability to read or process data coming from another application. Mule ESB solves this problem by providing a messaging framework that reads, transforms, and sends data as messages between applications. A Mule message is composed of different parts: The payload, which is the main data content carried by the message. The properties, which contain the meta information very much like the header of a SOAP envelope or the properties of a JMS message. If required, a series of attachments that can accompany the message
- 4. Mule vs. Traditional ESB Difference between Mule and a traditional ESB is that Mule only converts data as needed. Traditional ESB Need to create an adapter for every application, connect to the bus and convert the application's data into a single common messaging format. To develop adapter and process message require a lot of time. Mule ESB Mule eliminates all these efforts. Mule increases performance and reduces development time over a traditional ESB.
- 5. Messaging styles One-way Receives a message and puts it on a SEDA queue. The calling thread returns and the message is processed by the SEDA thread pool. Nothing gets returned from the result of the call. The Mule service must have an asynchronous inbound endpoint. If an error occurs it is handled by the Mule server. One-Way return types are NullPayloads
- 6. Messaging styles - contd Request – Response Receives a message and the component returns a message. If the component call returns null, then a Mule Message with a NullPayload is returned. If the call method is void the request message is returned. The Mule service must have a synchronous inbound endpoint and no outbound endpoint configured.
- 7. Messaging styles - contd 6 Synchronous A message is now processed synchronously if one of the following is true: endpoint is request-response A transaction is active The message property MULE_FORCE_SYNC is set to TRUE Receives a message and the component processes before sending it out on another endpoint. The request happens in the same thread. Mule blocks on the outbound endpoint to wait for a response from the remote application (if applicable) until the responseTimeout threshold is reached. If no response is received, it returns null. A synchronous call always returns a result, even if there is an outbound endpoint.
- 8. 7 Messaging styles - contd Async Request Response This pattern allows the back-end process to be forked to invoke other services and return a result based on the results of multiple service invocations. The Async Reply Router is used to listen on a Reply To endpoint for results. Set the reply-to address on the outbound router, and set the <async-reply> element to listen on that reply endpoint.
- 9. Message scope Inbound Inbound properties scope will hold the headers/properties sent by the caller flow/service/external source. When a message arrives to a mule endpoint it can contain headers/properties. Those properties will be placed as inbound properties of the mule message. Inbound message properties are read only.
- 10. Outbound Outbound properties scope will contain all the properties that will be deliver together with the message payload when calling an outbound endpoint. When a message is deliver to another endpoint then all the properties in outbound scope will be sent together with the message as headers. After calling an outbound endpoint that returns a response outbound properties are lost. Message scope - contd
- 11. Message scope - contd Invocation An Invocation property will be present in the invoked flow and will last for all the flow execution. Invocation properties are not propagated to other flows, but will be propagated if another flow or sub-flow is called using flow-ref. Session Mule session scope is created when a message enters a mule flow/service and it will preserved until the message leaves mule. Mule session propagation is done only when mule endpoints transport supports message headers (i.e. JMS, HTTP, VM). Any change to those properties within the async flow will not be reflected in the caller flow. Application Application properties scope is tied to the application lifecycle Application properties are read only.
- 12. Sample Code – Inbound Scope
- 13. Sample Code – Outbound Scope
- 14. Sample Code – Invocation Scope