I'm new to Mule, so that might be a dumb question. I would like to name the axis2 remote SOA service from Mule, and for this I will use the SOAP component. What I'm struggling with is the right model for the 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 populated using the set-payload transformer, and XML is embedded in the stream, as shown 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 the most appropriate way to configure this payload. My thoughts would be
- if there was more PAYLOAD, it would be better to save this XML in a file in the Mule project and read it as described in this question
- I would prefer not to create client cache classes for the request, but maybe I should use CXF to determine the class of service. What are the benefits of this?
Are there other preferred payload population methods. In my use case, this (optional) thread will be called from the router, so I will not transmit any relevant information that could change the message.
Beyond this: Perhaps for the job type name "Reminder Task" I should extract in mule-app.properties and use XSLT to populate in the final query?
thanks
Rich
source share