I am trying to validate xml again xsd and route invalid one to rabbitmq in mule.
I found schema validation component in mule but it seems like it only filter invalid one and pass valid one to the next flow.
Does anyone know how capture invalid one and route to rabbitmq queue in mule?
Thank you in advance.
You can wrap the schema validation inside a message filter.
This will pass the messages on to a flow named DeadLetterQueueFlow:
<message-filter onUnaccepted="DeadLetterQueueFlow" throwOnUnaccepted="false">
<xml:schema-validation-filter/>
</message-filter>
Related
I have created an API in WSO2 EI.
API is expecting the requests to be send as JSON.
If it is a malformed JSON which is sent, then I should be able to receive it and make appropriate changes to make it a proper JSON.
Any help is much appreciated.
As we are using json-eval($.) to get the message to property, it is not working for me. What else i could try instead of json-eval to get the message as string.
WSO2 EI has the property force.json.message.validation, which can be used to validate incoming JSON payload. Please refer doc to configure this property in 'passthru-http.properties' file.
Once the property is configured, if there is a malformed JSON payload in the request, the mediation flow will be directed to the fault/error sequence. So, you can define the mediation logic to make appropriate changes to the malformed content within the fault sequence of your API.
can anyone explain what is Service Data Object(SDO) and Service Message Object(SMO)?
Questions:
1. what is the purpose of SDO and SMO?
2.how it works?
These concepts aren’t used with Mule, they seem to come from IBM. https://www.ibm.com/support/knowledgecenter/SSFTN5_8.5.7/com.ibm.wbpm.main.doc/topics/cwesb_sca_smo2.html
The equivalent of the SMO in Mule is the Mule Event which you can read about here: https://docs.mulesoft.com/mule-runtime/4.1/about-mule-event
A Mule event contains the core information processed by the runtime. It travels through components inside your Mule app following the configured application logic.
It’s basically an abstraction layer so you don’t have to deal with different protocols and transports.
A Mule Event is composed of these objects:
A Mule Message contains a message payload and its associated attributes.
Variables are Mule event metadata that you use in your flow.
A Http POST for example would be represented as an event.
The event payload would be the body data of the http request
Where as the http headers such as content-type would be attributes on the event.
Same for JMS. The message body would be the payload and the jms header would be attributes.
As for SDO, each SMO has an SDO. This is very specific to that IBM article and not relevant in Mule. But from what I understand it basically allows you to access your heterogenous business data in a common way. I guess Dataweave in Mule accomplishes this as Dataweave is the transformation and expression language in Mule, it allows you to query and transform data in the same way regardless of the data type, xml, Json, CSV and so on.
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 just need to ask a question about the type of data in mule message?
is it a java object determined by the message source and processors OR a java object implementing the collection interface?
I dont understand your question. Is related to : mule message structure?
The Mule message is the data that passes through an application via one or more flows. It consists of two main parts:
message header which contains metadata about the message
message payload which contains your business-specific data.
Here official documentation:
https://docs.mulesoft.com/mule-fundamentals/v/3.7/mule-message-structure
I'm pretty new to Mule so this may be a silly question. I'd like to call a remote axis2 SOAP service from Mule and for this I will use the SOAP component. What I am struggling with is the correct pattern for PAYLOAD population. Here is a very simple payload example
<oper:CreateTask xmlns:oper="http://api.abc.com/workflow/operationtypes">
<workType>
<Name>Reminder Task</Name>
</workType>
<activitySubject>
<GenericSubject>Richard Fanning</GenericSubject>
</activitySubject>
<description>This is a Mule generated Reminder Task</description>
</oper:CreateTask>
The payload is currently being populated via the set-payload transformer and the XML is embedded in the flow as seen below
<flow name="createWorkflowTask" doc:name="createWorkflowTask">
<set-payload value="<oper:CreateTask xmlns:oper="http://api.abc.com/workflow/operationtypes"><workType><Name>Reminder Task</Name></workType><activitySubject><GenericSubject>Richard Fanning</GenericSubject></activitySubject><description>This is a Mule generated Reminder Task</description></oper:CreateTask>" doc:name="Set Payload"/>
<cxf:proxy-client doc:name="SOAP" enableMuleSoapHeaders="true" payload="body"/>
<http:outbound-endpoint exchange-pattern="one-way" method="POST" address="http://localhost:6081/workflow/services/ActivityServices" doc:name="HTTP"/>
</flow>
My question is what the most appropriate way of setting this payload. My thoughts would be
if the PAYLOAD were larger would it be better to maintain this XML in a file in the Mule project and read it as outlined in this question
I'd prefer not to generate client stub classes for the Request but perhaps I should use CXF to define the service class. What advantages would this provide?
Are there other preferred methods of payload population. In my use case this (sub)flow would be called from a router so I'd not be passing any relevant information that would alter the message.
Aside: Perhaps for the worktype name "Reminder Task" I should extract to mule-app.properties and use XSLT to populate in final request?
Thanks
Rich
In order to set payload in a flow, you can use either of the following ways.
Write a component(Java bean) which has the XML request as String and then make that string as return from the component. This component should be the first message processor in your flow.
Write a component(Java bean) which read the XML request from a file into a String and then make that String as return from the component. This component should be the first message processor in your flow.
Use a Inbound-Endpoint ( file or JMS) as the entry point of your flow. These inbound can read from the path specified. This way your input can be dynamic. And you can execute the flow multiple times fo different requests without the need to start the Mule server everytime.
More on Mule File and JMS endpoints in the following links.
Mule JMS Transport Reference
Mule File Endpoint
Next for your XSLT population of the worktype name, Mule XSLT Transformer from the XML module can be used. More on this in the following link Mule XSLT Transformer
Hope this helps.