In my flow I have a soap client calling a service. Since we are using 3 different operations from the service I'd like to dynamically fill in the "Operation" field under "Client Attributes" in Mule soap component. The way I have it working right now is:
start flow -> message transformation -> choice flow control (based on the message type)
choice 1. sub flow A -> soap client with operation A
choice 2. sub flow B -> soap client with operation B
choice 3. sub flow C -> soap client with operation C
What I would like is to dynamically in runtime set the "Operation" field based on the message and not have three different subflows.
start flow -> message transformation -> set the operation field -> soap client with the correct operation
Is that possible? Using Mule CE 3.3.1. Thanks in advance.
To achieve your goal:
Remove the operation attribute from the cxf:jaxws-client element,
Add set the operation as an outbound message property before the cxf:jaxws-client element with:
<set-property propertyName="operation" value="#[...]" />
where #[...] represents a MEL expression that extracts the operation name from the message.
Related
With Mule 3 it was possible to send messages asynchronously to an endpoint using MuleClient:
MuleClient client = new MuleClient(muleContext);
client.dispatch("vm://vm.queue", "Message Payload", null);
Is there a way to migrate this functionality in Mule 4 since MuleClient has been removed?
I came across a post that suggested getting the flow by name and publishing the message to the flow as follows
Flow flow = registry.lookupByName("MyFlow").get();
InputEvent event = new DefaultInputEvent();
event.message(Message.of(payload));
flow.execute(event);
but I get a ClassNotFoundException for the class org.mule.runtime.internal.event.DefaultInputEvent
Using Harshank's recommendation I was able to push messages to a flow simply by getting a reference to the flow and triggering the flow by sending messages to the source.
Flow flow = registry.lookupByName(flowName).get();
ComponentLocation location = DefaultComponentLocation.from(flowName + "/source");
...
Message message = Message.of(payload);
CoreEvent coreEvent = CoreEvent.builder(EventContextFactory.create(flow, location)).message(message).build();
flow.process(coreEvent);
This is a much cleaner solution than what is implemented in the blog and works from beans initialized in the Spring module. As aled mentioned, this is bad practice, but in the interest of time it is a solution.
We are migrating from Mule 3 to Mule 4 and in one of our functionalities we need to publish messages to a topic and downstream another mule component is consuming from the queue which is bridged to the topic.
Nothing special here .
To ensure we are able to trace the flow via logs we were sending a 'TrackingId' attribute while publishing messages to the topic ( Mule 3 )
message.setOutboundProperty("XYZ_TrackingID", flowVars['idFromUI']);
return payload;
However when I try the same in Mule 4 we get the following exception :
ERROR 2020-12-20 10:09:12,214 [[MuleRuntime].cpuIntensive.14: [mycomponent].my_Flow.CPU_INTENSIVE
#66024695] org.mule.runtime.core.internal.exception.OnErrorPropagateHandler:
Message : groovy.lang.MissingMethodException: No signature of method:
org.mule.runtime.api.el.BindingContextUtils$MessageWrapper.setOutboundProperty() is applicable for
argument types: (java.lang.String, org.mule.weave.v2.el.ByteArrayBasedCursorStream) values:
[XYZ_TrackingID, "1234567"].\nError type : (set debug level logging or '-
Dmule.verbose.exceptions=true' for
everything)\n********************************************************************************
Checked internet and it seems in Mule4 setting outbound properties is removed as per here
So how do I achieve the same in Mule 4 ?
Don't even try to do that for several reasons. For one message structure is different, so output properties doesn't exist anymore and that method doesn't even exists. On the other hand, in Mule 4 components like the Groovy component can only return a value and cannot change the event. They can not decide to what that value is going to be assigned. You can set the target in the configuration (payload or a variable) and not change the attributes. Note that variables in Mule 4 are referenced by var., not by flowVars. like in Mule 3 (ie vars.idFromUI).
There is a simpler way to set message properties in the Mule 4 JMS connector. Use the properties element and pass it an object with the properties.
For example it could be something like this:
<jms:publish config-ref="JMS_config" destination="${bridgeDestination}" destinationType="TOPIC">
<jms:message>
<jms:body>#["bridged_" ++ payload]</jms:body>
<jms:properties>#[{
XYZ_TrackingID: vars.idFromUI
}]</jms:properties>
</jms:message>
</jms:publish>
It is in the documentation: https://docs.mulesoft.com/jms-connector/1.0/jms-publish#setting-user-properties. I adapted my example from there.
I am not sure if Correlation Id serves the purpose of a tracking ID for your scenario. But you can pass a CID as below. It's there in the mule documentation.
https://docs.mulesoft.com/jms-connector/1.7/jms-publish
<jms:publish config-ref="JMS_config" sendCorrelationId="ALWAYS" destination="#[attributes.headers.replyTo.destination]">
<jms:message correlationId="#[attributes.headers.correlationId]"/>
</jms:publish>
If your priority is to customise the Tracking ID you want to publish, then try passing below format. The key names may differ as per your use case.
<jms:publish config-ref="JMS_config" destination="${bridgeDestination}" destinationType="TOPIC">
<jms:message>
<jms:body>#["bridged_" ++ payload]</jms:body>
<jms:properties>#[{
AUTH_TYPE: 'jwt',
AUTH_TOKEN: attributes.queryParams.token
}]</jms:properties>
</jms:message>
</jms:publish>
In the above the expression attributes.queryParams.token is basically trying to access a token query parameters which is passed to JMS as a property AUTH_TOKEN key-name , consumed by the API through a HTTP Listener or Requestor earlier.
However, attributes.headers.correlationId is a header. Both queryParams and headers are part of attributes in Mule 4.
I'm looking for a native (correct, in terms of the framework) way to send thirdparty (custom) Object to JMS in citrus-simulator?
I have tried:
scenario
.send()
.payloadModel(myObject);
but in JMS queue myObject appears as com.consol.citrus.message.DefaultMessage instead of com...myObject.
Example:
Scenario - receives http POST request (as trigger) and send's JMS Object to message queue.
config
...
.useObjectMessages(true)
...
scenario
...
import com.temafon.data.MORequest;
#Scenario("morequest")
#RequestMapping(value = "/simulator/morequest",method = RequestMethod.POST)
public class JmsMoRequestScenario extends AbstractSimulatorScenario {
#Override
public void run(ScenarioDesigner scenario) {
MORequest request = new MORequest(12345678901L, "USSD", "1172", "ON",
11L);
request.setSourcePort(3);
scenario
.receive()
.payload("getmorequest");
scenario
.send("jms.queue.destination")
.payloadModel(request);
After this case, I expect to get in jms.queue.destination something like screen 1
Expectation
Reality
P.S. I have implemented workaround already, with JavaActionBuilder and jmsTemplate.send in additional class and
scenario
.java(//Object).method(//instance");
But it doesn't seems like correct citrus-simulator way
Setting the payloadModel() in Citrus Java DSL will always result in some kind of marshalled representation of the object and this is not what you want. Neither is using .useObjectMessages(true) working for you because this results in the whole Citrus message object to be used as message payload.
You need to define a complete Citrus message object and that will remain untouched in terms of payload creation for the JMS destination. Citrus is then automatically using a JMS object message with proper object payload.
MORequest request = new MORequest(12345678901L, "USSD", "1172", "ON", 11L);
request.setSourcePort(3);
scenario
.receive()
.payload("getmorequest");
scenario
.send("jms.queue.destination")
.message(new JmsMessage(request));
Note that I am using the .message() fluent API instead of the payloadModel() API. The message API receives a Citrus message object such as com.consol.citrus.jms.message.JmsMessage or com.consol.citrus.message.DefaultMessage
Your custom domain model object request is used as constructor arg and will result in the JMS message as object payload as is. Of course MORequest must be of type java.io.Serializable
I have configured Apache Flume to receive messages (JSON type) in HTTP source. My sinks are MongoDB and HBase.
How can I write the message according to a specified field to different collections and tables?
For example: let's assume we have T_1 and T_2. Now there is an incoming message that should be saved in T_1. How can I handle those messages and assign them where to be saved?
Try using the Multiplexing Channel Selector. The default one (Replicating Channel Selector copies the Flume event produced by the source to all its configured channels. Nevertheless, the multiplexing one is able to put the event into a specific channel depending on the value of a header within the Flume event.
In order to create such a header accordingly to your application logic you will need to create a custom handler for the HTTPSource. This can be easily done by implementing the HttpSourceHandler interface of the API.
you can use regex for tagging message type + multiplexing for sending it to right destination.
example , based on message "TEST"
regex for a string / field
agent.sources.s1.interceptors.i1.type=regex_extractor
agent.sources.s1.interceptors.i1.regex=(TEST1)
assign interceptor to serializer SE1
agent.sources.s1.interceptors.i1.serializers=SE1
agent.sources.s1.intercetpros.i1.serializers.SE1.name=Test
send to required channel , channels (c1,c2) you can map to different sinks
agent.sources.s1.selector.type=multiplexing
agent.sources.s1.selector.header=Test
agent.sources.s1.selector.mapping.Test=c1
all events of test regex will go to channel c1 , others will be defaulted to C2
agent.sources.s1.selector.default=c2
Is there a way in mule to extract parent flow message in sub/synchronous flow after sub message source has generated its message and modify it.Sub flow is having its own message source.
You can always get the message of parent flow in sub flow ..
Now extracting a message depends on its data type ...
For example if the payload type is xml and you need to extract particular value of a node, you can use XPATH...
Similarly for JSON payload there is different techniques of extracting it..
And now if you want the entire payload of parent flow and not just part of it, then you can always use #[message.payload] expression in subflow