Is it safe to rely on session variables to store information to be shared between multiple asynchronous flows? - mule

I have a couple of flows that rely on session variables that are generated in one flow and then passed to the other. Is it safe to rely on session variables used by two asynchronous flows? I guess I don't fully understand the scope of 'sessionVars' in a mule application or in a given mule message.

The mule session has nothing to do with the Java EE session that is shared across threads. The mule session is part of the MuleMessage and how they works is explained here, therefor if you want to share something across multiple flows processing the same message that is the way to go.
If instead you are looking into a way to store a value from a flow processing the message A and pick that value from a flow processing the message B you should consider store this value into the objectstore

I am pretty sure that session variables are returned to http endpoints that are request-response. This could expose sensitive data. I am trying to locate the original mention and official mitigation strategy but have yet to locate it again.
But an easy solution is to remove them at return point of a flow
Edit:
Found the thing I was looking for...
`
<http:connector name="NoSessionConnector">
<service-overrides sessionHandler="org.mule.session.NullSessionHandler"/>
</http:connector>
`
found here under 'HTTP Response Header'
http://www.mulesoft.org/documentation/display/current/HTTP+Transport+Reference
Or, you can also create a custom SessionHandler

Related

Two-way Apache Camel Routes - Infinite loop

I have 2 endpoints that I would like to establish routes between. Due to the nature of these endpoints (JMS topics), I would like the bridging to be bidirectional.
The underlying JmsComponent for the Tibco endpoint has the pubSubNoLocal parameter enabled which ensures that a consumer does not receive messages it has itself sent as per http://camel.apache.org/jms.html
pubSubNoLocal false
Specifies whether to inhibit the delivery of messages published by its own connection.
However this has no effect since the 2 routes create separate connections to the JMS topic my.topic.
As a result, the following will create an infinite loop.
As mentioned, I need the routes to operate in both directions for "seamless integration"
<c:route>
<c:from uri="tibco:topic:my.topic"/>
<c:to uri="solace-jms:topic:mytopic" />
</c:route>
<c:route>
<c:from uri="solace-jms:topic:mytopic"/>
<c:to uri="tibco:topic:my.topic" />
</c:route>
I suggest le consideration the concepts of message selectors and headers.
The way I see it, you do 2 things:
Add a "PRODUCER" header with your Server ID (however you define it)
All your listeners must be configured with a negative selector "NOT (PRODUCER='YOUR_ID')"
Done ?
(Of course, you could also use 2 topics... but I assume it is out of the question...)
You will need to add some indication in the message that it has been sent through either bridge. You could play with existing properties (redelivery ?) or better add a new one. For example set property bridged=true when it passes your bridge. Then inside your definition you can filter out each message already bridged.

Changing Mule Flow Threading Profile at runtime

I have a requirement in hand where I need to change the Mule Flow Threading Behavior at runtime without the need of bouncing the whole Mule Container. I figured out few different ways to achieve this, but none of them are working.
I tried accessing the Mule Context Registry and from there I was trying to do a lookup of "FlowConstructLifecycleManager" Object so that I can tap in there and access the threading profile of the object and reset those values, then stop and start the flow programmatically in order to get the change applied in the flow. I am stuck in this approach as I was unable to get hold of the FlowConstructLifecycleManager Object neither from the Mule Spring Registry nor from the Transient Registry. I was able to get hold of the Flow object though which has a direct reference to that FlowConstructLifecycleManager Object. But, unfortunately, they made this object as protected and didn't expose any method for us to access this object.
Since I was unable to access this FlowConstructLifecycleManager directly from Mule implemented Flow class, I decided to extend this Flow class and just add another public method to it so that I can access FlowConstructLifecycleManager object from Flow object programmatically. But, I am stuck in this approach as well as even if I am putting my version of the same Flow class packaged and dropped in lib/user folder of the container, it is still not picking up my version of the class, and loading the original version instead.
It would be of great help if I can get any pointer on the approach of solving either my first or second problem.
Thanks in advance,
Ananya
In our company, we are building a dashboard from where we should be able to start/stop any flow or change the processing power of any flow by increasing/ decreasing the active threads for a flow or changing the pollen polling frequency. All of these should be done at runtime without any server downtime.
Anyway, I made it working finally. I had to patch up the mule-core jar and expose few objects so that I can get to the thread profile object and tweak the values at runtime and stop/ start the flow to reflect the changes to take effect. I know this is little bit messy and but it works.
Thanks,
Ananya

Mule Web Service Consumer Warning : Operation Messages With More then 1 Part Are Not Supported

Hi I am working with Mule Web Service Consumer and i was trying to call operation with Multiple Parameters it is warning me that
Warning : Operation Messages With More then 1 Part Are Not Supported
I just want to pass multiple parameters to access my SOAP method to achieve the task.
Is this the problem with Web Service Consumer or is their any way to deal with this.
I'm afraid this is a known limitation of the web services consumer. However you can accomplish this with the cxf component.
I having the same issue and found some information around it ...
There is a improvement logged in JIRA, may help if you vote for it :)
This link suggests that you can still use WSConsumer but need to do some hand crafting of the request XML ... I could not understand what that exactly it meant so if anyone has an example on it would be great
PS: The problem I had with using CXF component is that it does not play well with the new Dataweave transformer as the Dataweave needs to be placed within the response block and from there it cannot datasense the response coming out from the CXF component
The Solution here is very simple. You just have to comment other messages and then load metadata for non-commented message (for one which you're trying to load metadata). Repeat this procedure for all the other messages and you're good to go.
Hope this helps !

Is it possible to programatically add an interceptor before a VM endpoint from within a Mule FunctionalTestCase? If so, how?

I have a flow with two VM endpoints both configured with the exchange pattern of request/response. I want to evaluate the message at the end of the flow when it reaches the seecond VM endpoint, before the next flow takes off with the message. I thought I might be able to do this with an interceptor inserted before the VM endpoint. Is this possible from within a Mule FunctionalTestCase? Is it possible to programatically add an interceptor to a flow at all..?
Personally, I think that the flows should not really be altered during the testings. In that case you would have another (although just slightly different) version running when you deploy it to a server.
Instead, I would argue that you divide your flows into testable parts and put the endpoint addresses into separate configuration. That way you can test each vm-based flow separated from each other and verify the behaviour using mock flows or similar.
vm://in-flow1 -> process -> vm://mock
vm://mock -> verify payload -> vm://in-flow2
In the "real" configuration, you change "mock" to something pointing to the second vm flow.
You can also elaborate on mocking the first or second VM flows entirely from each other to create distinct unit tests.
However, if you really want to go down the "modify code for testing purposes" rabbit hole, you can likely use some aspect oriented black magic to achieve that.
Look at this blogpost how it's done in mule.
You could try with Munit, and run an spy around the flow (it should work). So you can run assertions after the flow execution
https://github.com/mulesoft/munit

The <invoke>-element of Mule 3, what does it do?

I have previously only used Mule 2.2.1, but i'm now reading up on Mule 3.4/3.5.
One major change between theses versions is the introduction of flows.
In the documentation of the Mule configuration i found this:
A flow begins with an inbound endpoint from which messages are read and continues with a list of message processors
However, in this post i came across the invoke-element. It appears that a flow can also begin with an invoke-element.
I was searching the Mule documentation for documentation of the invoke element, but was not able to find it. Can someone help explaining the semantics of the invoke-element, or point to any relevant documentation?
The "invoke" element is a message processor and not a message source.
The quote "A flow begins with an inbound endpoint from which messages are read and continues with a list of message processors" is not quite true as flows such as sub-flows or private flows that are referenced via other flows using flow-refs do not need an inbound-endpoint and can just have a list of message processors.
So it cannot be used to trigger a flow. However the example above seems to be a private flow which would be referenced from another flow via flow-ref so hence why it starts with a message processor. More eon private and sub-flows here: http://www.mulesoft.org/documentation/display/current/Using+Flows+for+Service+Orchestration
Back to the invoke message processor. THere is lacking documentation around this, but simply put, it calls the specified method for the given object using the given arguments.
From the javadoc: invokes a specified method of an object. An array of argument expressions can be provided to map the message to the method arguments. The method used is determined by the method name along with the number of argument expressions provided. The results of the expression evaluations will automatically be transformed where possible to the method argument type. Multiple methods with the same name and same number of arguments are not supported currently - http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/processor/InvokerMessageProcessor.html