It looks to me that <set-property> only sets inbound properties (right?). How can I set outbound property, aiming to carry it across transport barriers and then use <copy-properties> to copy it to outbound from inbound.
I don't want to set session variables are lost amid flows by outbound endpoints
set-property adds outbound message properties. If you want to check all message properties use a logger component or you can use Mule 3.4.0 (Beta) that comes with a visual flow debugger.
Set-variable sets the properties in the INVOCATION scope.
Use message properties transformer to add variables in different scopes.
Related
I know Session variables are persisted across some but not all transport barriers for example they are not propagated across the HTTP transport barrier.
Can anyone help me to know what are other transport barriers in mule which does not allow propagation of session variable.
Session variables set with a session variable transformer persist for the entire message lifecycle, regardless of transport barriers, except for the HTTP Connector which doesn’t propagate them.
Ref below link
session-variable-transformer-reference
Session variables are used when we want to retain the value(s) across transport barrier within the flow. These session variables will not be available in the http request flow API but only within the flow they are declared. They are meant to be use in place of flow variables when there is any transport request in the flow.
To carry values over http you can set outbound property which will be available as inbound property after http barrier.
Below link explains property scope in detail
https://blogs.mulesoft.com/dev/anypoint-platform-dev/mule-school-the-mulemessage-property-scopes-and-variables/
The request-reply scope mandates that we place a outbound endpoint in the reply section of the scope, I am wondering why is the scope designed as such ?
Why can't this detail be handled internally by Mule ?
All MP's can be placed only after the request-reply scope and so I think Mule should be able to just get the reply using any endpoint it chooses and just forward the payload to the MP after the scope.
Also note that the flow which is invoked from the request section never refers to the outbound endpoint specified in the reply section, so this detail is anyways handled by Mule, then why even ask the developers to specify an outbound ?
The request-reply scope is a 1:1 implementation of the Request-Reply integration pattern:
There are advantages in using a stable (ie non dynamic, non private) channel for replies, including the capacity to trigger the reply from any point in any flow.
If you do not need this, consider using synchronous endpoints instead. For example, a synchronous JMS endpoint creates a dynamic reply channel (a reply queue) to transparently support routing responses back to the caller.
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 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.