I am having this requirement in a mule service that it should consumes from an inbound connector(flow message source) only if a business condition holds true. I need to look into the database whether that condition holds and then only my inbound connector should start consuming.Each time it should check for that condition and consume only if condition is true. Suggest best way to achieve implementation in mule.
Although a message filter is theoretically correct, in practice this is often accomplished using the Database Connector with a SELECT query that determines which rows should be processed in its WHERE clause. You can place the query in a <poll></poll> element at the beginning of a flow to execute the query on a schedule, as illustrated in the second example here.
This is something difficult to say without looking into your flow what exactly you want to implement .. Generally if you want your inbound endpoint to consume and the flow to work , the best option is to put a message filter after the inbound endpoint which will check the condition and allow the message to pass to next processor..
Since here you want to check the condition from the Database, what you need is to put a DB component after the inbound endpoint which will fetch the value of the business condition from the DB and then you can put either the message filter or Choice router to pass the message payload to the next Mule component
This is tipically done using the message filter integration pattern.
This pattern is implemented in Mule as (and only as) Filters, other patterns that could do the trick, specially routers and detour, but the more consistent way of do it is with filters.
In the case of Mule, you have a number of filters however there is no sql query based filter out of the box. This said. You have a number of options:
a Filter in java, that you could instantiate as a spring bean injected with the datasource and then use as a custom filter with ar ref.
if this is meant to be reusable, implement as a DevKit module.
as a workaround, implement a sub-flow that leverages the database conector to fetch the query result and to then filter or not at the end of the flow with an expression filter.
Related
We are using WSO2 ESB, and we are using payloadFactory mediator to transform the message. we have entered into scenario where we need to ignore the payload arguments when it is empty or null. can any one help us achieve this?
You can try using filter mediator wherein you check the arguments in xpath, if arguments exist then you can call payload mediator with all the arguments, else you can call another payload which doesn't contain those arguments.
However according to me the best practice would be to use an xslt mediator where you put all your logic in the xslt, this would make your sequence small in length and more readable.
I want to customise the Action and ReplyAction properties of the OperationContractAttributes that I have on my data contract types in my WCF services.
I have some logic in an ESB that will read incoming messages and route them accordingly based on the SOAP action header so I need to explicitly state the values for these properties. But I don't even look at messages being returned, so it seems cleaner to have the same value for both properties.
I'd like to know if there is anything obviously wrong with setting these two properties to equal the same value for a specific operation? Why are the default values different to one another?
Thanks
Just to follow up on my own question in case it's helpful to others... I did proceed with using the same value for Action and ReplyAction.
Many SOAP implementations ignore the actions so it's less relevant, but WCF does use this value to route a message to the operation on a service. Setting both of the values to the same thing doesn't cause any issues because no system processes both the request and the response so there's nothing ambiguous about it.
I found that doing this made the WSDL generated simpler to understand, and there were half as many actions to document and route in our ESB.
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 have a client who has a web service providing several different top-level entities. Let's say there are three which are of particular interest: Organisations, Sectors and Activities.
The client wants to be able to search for a term across all three of these entities simultaneously without have to make three separate calls. For example, "return all records whose name contains bread".
While the expand keyword would seem to be the solution at first glance, this only provides a view into the parent entity.
My suspicion is that this cannot be done by virtue of the way in which OData is designed to work, but I need to have a conclusive answer before going back to the client.
Unless the server provides a service operation for this exact purpose (and that would be pretty tricky to design anyway, what type should it return?), then it's not possible in one query.
On the other hand the client can send three queries inside one batch request. So that it's just a single roundtrip to the server. Might be good enough.
You could add a webget to the service to perform this function. You would have to wrap the response objects though.
Im connecting to a multi-tenant database through an odata service (my client is an iOS app, using the obj-c OData SDK). My question is, is there a way to apply a global filter to all data calls. Every data call should be filtered by TenantID=?, so instead of going to every single data call and adding TenantID=? to the filter string (My app is already developed for single database and am now refactoring it for multi-tenant), i was just hoping there is a way to catch it in say the OnBeforeSend event and manipulate the URL to add the filter. So therefore all data calls are filtered. Any ideas? Or any suggestions on approaching this?
Thanks in advance
There's nothing wrong with that approach.
Another approach, which may not be applicable in your situation, is to filter it on the Odata side using change and query interceptors.