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/
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
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
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"/>
I have a WCF service application (actually, it uses WCF Web API preview 5) that intercepts each request and extracts several header values passed from the client. The idea is that the 'interceptor' will extract these values and setup a ClientContext object that is then globally available within the application for the duration of the request. The server is stateless, so the context is per-call.
My problem is that the application uses IoC (Unity) for dependency injection so there is no use of singleton's, etc. Any class that needs to use the context receives it via DI.
So, how do I 'dynamically' create a new context object for each request and make sure that it is used by the container for the duration of that request? I also need to be sure that it is completely thread-safe in that each request is truly using the correct instance.
UPDATE
So I realize as I look into the suggestions below that part of my problem is encapsulation. The idea is that the interface used for the context (IClientContext) contains only read-only properties so that the rest of the application code doesn't have the ability to make changes. (And in a team development environment, if the code allows it, someone will inevitably do it.)
As a result, in my message handler that intercepts the request, I can get an instance of the type implementing the interface from the container but I can't make use of it. I still want to only expose a read-only interface to all other code but need a way to set the property values. Any ideas?
I'm considering implementing two interfaces, one that provides read-only access and one that allows me to initialize the instance. Or casting the resolved object to a type that allows me to set the values. Unfortunately, this isn't fool-proof either but unless someone has a better idea, it might be the best I can do.
Read Andrew Oakley's Blog on WCF specific lifetime managers. He creates a UnityOperationContextLifetimeManager:
we came up with the idea to build a Unity lifetime manager tied to
WCF's OperationContext. That way, our container objects would live
only for the lifetime of the request...
Configure your context class with that lifetime manager and then just resolve it. It should give you an "operation singleton".
Sounds like you need a Unity LifetimeManager. See this SO question or this MSDN article.