I was wondering whether anyone had any experience dynamically setting the name of the flow I want to redirect to in Mule? The use case is that I might have data coming in and I want to route the request to a specific flow based on the data coming in. However, the mule-config may not know of this flow until runtime, so I need to select a flow that corresponds to the data in a certain incoming field.
Many thanks.
Selecting a destination flow is usually done by sending a message to the inbound endpoint of the desired flow.
For example, if you use VM inbound endpoints in your different flows, you can then at runtime use a dynamic VM outbound endpoint that will target the right VM inbound endpoint.
Related
I am developing a mule application where I have to take orders from One system System-1 & have to send it to the another system say System-2 through soap (which actually takes care of creation of orders, invoices etc) & the response from System-2 is routed back to system-1 with success or failure response. Now what approach should be the best, will a VM be the best approach for referencing purpose or a flow reference ? The number of orders coming could be like 100 per hour. Also for both cases what should be the ideal worker size ?
If the system 2 is to be called SOAP web service, you should be using web service consumer component or an http requester component.
Lets understand the difference between flowref and vm.
Both flowref and vm are used to call another flow within the mule application.
Major difference between both is vm uses in-memory queue to refer to other flow and it creates a transport barrier, hence flow variable and inbound properties wont be propagated across, hence use of vm component should be considered only of it creating a transport barrier is necessary.
If thats(creating transport barrier) not the requirement, usage of flow ref is recommended.
we are trying to audit all incoming/outgoing messages, header information in our mule flow.
For same we have tried to use 'wire-tap' which we dint found so useful also its working on mule 3.6.1 but giving error in 3.7.
Any idea/suggestion for auditing?
Ok let me add some more details:
What we are trying to do is- Whatever message comes or flows via flow components we want to copy it in some sub flow (say in queue) without interrupting the main flow so that we can check the message.
you can make it work in several ways
1) Wire tap is one of the choice. You can route your messages asynchronously to sub flow and sub flow will do the auditing work. But I don't know why you didn't found wiretap useful. Can you explain in more.
2) All the messages your receive from the main flow, those you can post to JMS queue. So another flow will read from there and do the auditing work. Use of this multiple projects can use the same piece of code and post JMS queue for auditing.
This can be done in many different ways and you kind of mentioned them in your question such as logger component and interceptor.
All the headers are available as message properties so if you log the entire message they are shown. Simply put an logger component after the inbound endpoint and one before the outbound endpoint and this is easily done.
If you need some log entries transformation you could always put that in a wire tap so you don't interfere with the functionality of your flow.
If all the outbound properties are converted to inbound properties on crossing the transport barrier , and all the outbound properties set are available at the mule endpoint as inbound properties , why do we need session variable ?
You are right about the concept of outbound properties,but you need to consider following scenarios
The outbound properties(which can later become inbound properties)
are visible only during execution of single flow i.e. they cannot be
used across multiple flows.
when message is passed to a new flow via a flow-ref rather than a
connector, the outbound properties remain outbound properties and are
not converted to inbound property.
on the other hand for session variables
They are available across all flows within a application.
so there is a specific purpose for which mule has both outbound properties and session variables.
You can use any one of those which cater to your specific requirements.
For further reference you can have a look here Mule Message
hope this helps!
Good luck!
Here is a link, which helped my through when I was asking your question:
https://m-square.com.au/mule-school-the-mulemessage-property-scopes-and-variables/
I hope it helps.
Session variables are used when you need the values within the application, as Session variables are Global throughout the application.
On the other hand, Outbound properties are used when you need the values outside the application into another application. Since outbound properties can cross across the transport barrier, we can easily get the value into other application, which the Session variable can't
I have been trying to figure out, what exactly a inbound end point and outbound end point. For me it is bit of an eluding to understand.
what are exactly inbound and outbound endpoints for/do in mule flow? if a flow wants send message which endpoint shoud be used viz when receiving. Or when an application want to invoke a flow which end point it should communicate to?
Inbound endpoints are message sources (http://www.mulesoft.org/documentation/display/current/Message+Sources), which as the name suggests is where messages are created. They can be created based on external events (like an incoming HTTP request or JMS message) or by polling (like files in a directory).
Outbound endpoints and anything else you see in a flow (except exception strategies) are message processors (http://www.mulesoft.org/documentation/display/current/Message+Processors), which means they do something with the message in-flight the flow. Outbound endpoints are message processors that send the current message to "destinations" like a JMS queue, an HTTP server, a file, ...
Disclaimer: This is a simplified view to give you a general idea, its not the beginning or end of what you can do with mule (or other service buses)
Mule is a message processing engine. You can think of it as a giant conveyer belt. You put something on one end, and it goes along the belt and comes out the other end.
The thing that mule deals with are called messages.
The starting point is the "inbound end point" and the exit point is the "outbound end point"; between these pairs of end points you can have other things that will process the message as it travels from the start to the end.
A combination of a start end point + gubbins in the middle to do some work on the message + outbound end point is called a flow. You can chain flows together to create a workflow or process.
These processes are then packaged as an application and uploaded to the mule server. The process only runs when a message that it is listening for arrives. Otherwise the processes are sitting idle. Think of it like a car assembly line. The assembly line that fixes the seats in the car can only start when the chassis is finished; otherwise there is nothing for it to do. Once the seats are fixed, only then can the paint assembly line start, and so on.
Inbound Endpoint: To get the data in mule app from outside.
Outbound Endpoint: To pass the data from the mule app to the outside.
There are two types of connectors available based on operation.
Inbound Endpoint based connector : Inbound endpoint based connectors are the connectors which is placed inside a message
source area of a mule flow which is used to start executing or
triggering off the flow upon receiving the request. (or which is
used to receive the incoming request and pass the request to the
next message processors in a flow for further processing)
Outbound Endpoint or Process based connector: Outbound Endpoint based connectors are placed anywhere within a message processor
area of a flow at beginning or in the middle or at the end.
Regards,
Rajnish
Giving below the structure definition of Mule Message Object has Message Inbound Property Outbound Property Payload Variable Flow Variable Session Variable Attachment Exception Payload
When a connector of a flow (listening on a port) receives the payload its called Inbound endpoint. When in a flow we have a connectore placed in the middle and send a payload its called Oubound endpoint. Here the all the outbound properties sent to the Http Outbound flow become Inbound Properties within that flow.
For detailed explanation see the link below.
https://docs.mulesoft.com/mule-user-guide/v/3.8/mule-message-structure.
I need to create an "accumulator" service to be used by Mule ESB applications.
This service will hold inbound messages until a certain number are received and then package those messages into a single outbound message.
This is the first time I've needed to write an ESB application that needs to maintain state (the collection of previously received messages) across inbound messages and I'm not quite sure how to get started.
I think what I need is a place to hang a reference to a data structure that holds my lists of inbound messages, but I'm not sure.
What's the best (most productive, most consistent with ESB best-practices) mechanism for managing "application-level" (i.e. cross-message) state data?
Thanks.
For this scenario you need to use the aggregator pattern. Please follow the below link .
http://www.mulesoft.org/documentation-3.2/display/32X/Message+Splitting+and+Aggregation