I understand that session variables in Mule ESB can be shared between different flows of the same request, but... How can I make a variable visible to multiple requests?
It is a variable, so it would change depending on the data the flow receive.
Thanks in advance!
you can use the new mule 3.4 cache scope to store/cache objects, alternatively you can use the Mule Objectstore to save the session value as key and object. This
can be in-memory or persistent
<objectstore:retrieve key="mykey" defaultValue-ref="myvalue"/>
Related
I have an API that is called via scheduler and I want to store a variable so that the next time the scheduler kicks in it somehow recalls that variable (count) and increment it. I tried using objectstore here but I am having an issue since my API runs in a clustered environment. I think the objectstore value it not shared across the cluster environment. Tried changing the persistent value to false (so that it store the data in memory) but still does not work. Did I miss something or that is really how it behaves? If it is the later, is there any other possible solution knowing that saving the value in actual database is not feasible/available? Thank you.
Adding config for the objectstore
<os:object-store name="CounterStore" doc:name="Object store" doc:id="5e0b1de8-318f-49b1-ab7f-47d29f1631d2" persistent="false" config-ref="CounterStoreConfig"/>
<os:config name="CounterStoreConfig" doc:name="ObjectStore Config" doc:id="7be6b1a6-d0e0-45d4-a52a-2080a5d54802" />
We have our own domain for the anypoint platform and I'm seeing /cloudhub in the url in the runtime manager so I'm assuming that we are running in the CloudHub. We are using the Mule 4.
CloudHub does not support clusters. It does support multi worker deployments, where the same application is deployed to more than one worker. That means that the cluster object store implementation is not available in CloudHub. You can use the Object Store v1 (deprecated) or the recommended v2. Both allow to share an object store between workers. You need to name the object store according to the documentation. That means that for Mule 4/object store v2 it should be called _defaultPersistentObjectStore. Also remove the persistent attibute
https://docs.mulesoft.com/object-store/#object-store-notes:
For CloudHub applications using Mule 4, if you choose Object Store v2,
Object Store v2 overrides the _defaultPersistentObjectStore object
store.
For CloudHub applications using Mule 3, Object Store v2 overrides the
_defaultUserObjectStore object store. To use Object Store v2 in Mule 3 CloudHub applications, set the Object Store reference field to the
_defaultUserObjectStore value.
Note that Object Store implementations in CloudHub do not lock between workers so it may not be useful for you:
Using Object Store v2 with multi-worker CloudHub applications might result in data discrepancies or key clashes.
I am new to mule and trying to implement object store.
As per mule documentation:
Mule provides two types of object stores:
In-memory store – Prior to Mule 3.5.0, in-memory store was the default. As of Mule 3.5.0, persistent store is the default. For more information, see "Object Stores and Clustering" in the Cache Scope document.
Persistent store – Mule persists data when an object store is explicitly configured to be persistent. Mule creates a default persistent store in the file system.
it is mentioned as persistent store is default but in object store connector configuration persistent checkbox is not enabled by default. why it is so and which object store is used in this scenario?
Thanks in advance.
Note: Am using mule 3.8.3
Screenshot of Object store configuration
these are two different concepts. Mule Cache Scope which is what you are referring and Object Stores as a connector component itself.
If you are wrap a component in a cache scope then by default it uses 'default caching strategy' which uses inMemoryObjectStore (intended for testing only). It is better to store the cached responses in a separate store such as Object Store. Also, internally, Mule uses object stores in various filters, routers, and other message processors that need to store state between messages. In most cases, Mule creates and manages object stores automatically.
Coming to ObjectStores connector, they can be persisted to disk by proper configuration settings.
Hope this helps!
Thanks,
Anand
In this sub-flow, how can I access from the http connector (red area) the inbound properties available at green marked area.
The scope of the inbound property is only just after the inbound endpoint or the source endpoint.
Here you should copy your inbound properties to the "flowVars" and then use it across the flow
#[flowVars.paramerterName = message.inboundProperties.'http.query.params'.parameterName]
Please make note if you want to access the HTTP properties, the syntax MEL format will be different for the Mule latest version and old version. The above one is valid for the latest Mule version and the syntax to access any property like below
#[message.inboundProperties.'http.query.params'.cityname]
where as in previous versions
#[message.inboundProperties['propertyName']].
This will depend on your inbound message source, but assuming it is an HTTP connector, use the MEL expression to access the inbound property http.query.params
#[message.inboundProperties['http.query.params']
The inbound message object is nothing but a HashMap of key-value pairs - best would be to use the debugger and select the keys you would like to access.
Here is the documentation for the Mule message, there you will find the description for the different kind of variables and properties. Inbound properties should be propagated from the main flow to the sub-flow and should still be available after the choice, excepting the case where you overwrite them or when there is an outbound-endpoint, which would overwrite them too.
Let say I get a inbound variable from an http connector when I use this URL
http://x.x.x.x:8080/post?post-message=Hallo wold.
How can I use the value of the #[header:INBOUND:post-message] accross the complete flow from after the HTTP connector all the way up tp the end. Should I use the Mule Object store to write it to ram?
This post shows the scope of variables but it seem there is not one thay can flow from start to en like a session bean
https://m-square.com.au/mule-school-the-mulemessage-property-scopes-and-variables/
Kind Regards.
If you need the variable available throughout the whole flow (and
other flows reached through a flow-ref) use the invocation scope
(set-variable to set, flowVars[] to read it)
If you need it to reach other flows through a transport (e.g. VM) put
it in the outbound or session scope.
If you need it to live as long as the app is running, through
different calls, use the Mule registry (volatile, only available as
long as the app is up) or the object store (which can be configured
as persistent, to hold state even if the app goes down).
Mule Session variables are good enough to get the value throughout application.
But if you need to use the value outside your application, then you can set mule outbound properties.
There are three type of scope level variables supported by mule .
You can use flow variable if you want the variable to be accessible throughout the whole flow.
You can use session variable if you want it to be accessible form other flows through a transport barrier.
Refer this blog for getting better understanding of how different types of variables are propagated between different mule flows.
http://blogs.mulesoft.com/dev/anypoint-platform-dev/mule-school-the-mulemessage-property-scopes-and-variables/
I'm storing some data as session variables in a mule flow that involves a mid-flow http call to an external service. I need this data for a subsequent branch of the flow logic, hence the session variable. However, I do not want this data to go out with the http call as http headers. Is there a way to limit which session variables mule includes as http headers in a given call?
If you want to decide what session property to propagate you can write a custom session handler and inject it into your http connector something like this:
<http:connector name="httpConnector">
<service-overrides sessionHandler="your_session_handler" />
</http:connector>
An example of a custom session handler can be found here
That said I'd like to echo David Dossot's answer: session variables should seldom be used, especially knowing how Mule leaks them by default. If you want to propagate something, you should set it explicitly as an outbound property and mule will propagate it.
Use flow variables: session variables should seldom be used, especially knowing how Mule leaks them by default.
Flow variables (aka invocation properties) should be unaffected by endpoint interactions, this by design. Any other behaviour would be a bug. If your variables do not need to extend further than a flow, use flow variables, not session variables.
session variables are not sent across http calls, only session ID is sent via cookie (usually)
if you need to pass some data via http call to external domain - include them in GET, for example, as cookie are not shared