<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cus="http://schemas.acme.com"> <soapenv:Header/> <soapenv:Body> <cus:customerOrder> <cus:header> <cus:customerNumber>123456</cus:customerNumber> </cus:header> </cus:customerOrder> </soapenv:Body> </soapenv:Envelope>The OGNL expression representing the customerNumber parameter is "customerOrder.header.customerNumber".
Once the OGNL expression has been calculated for a parameter, this class will check the supplied parameter map for an Object keyed off the full OGNL expression (Option 1 above). If no such parameter Object is present on the map, this class will then attempt to load the parameter by supplying the map and OGNL expression instances to the OGNL toolkit (Option 2 above). If this doesn't yield a value, this parameter location within the SOAP message will remain blank.
Taking the sample message above and using the "Option 1" approach to populating the "customerNumber" requires an object instance (e.g. an "Order" object instance) to be set on the parameters map under the key "customerOrder". The "customerOrder" object instance needs to contain a "header" property (e.g. a "Header" object instance). The object instance behind the "header" property (e.g. a "Header" object instance) should have a "customerNumber" property.
OGNL expressions associated with Collections are constructed in a slightly different way. This is easiest explained through an example:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cus="http://schemas.active-endpoints.com/sample/customerorder/2006/04/CustomerOrder.xsd" xmlns:stan="http://schemas.active-endpoints.com/sample/standardtypes/2006/04/StandardTypes.xsd"> <soapenv:Header/> <soapenv:Body> <cus:customerOrder> <cus:items> <cus:item> <cus:partNumber>FLT16100</cus:partNumber> <cus:description>Flat 16 feet 100 count</cus:description> <cus:quantity>50</cus:quantity> <cus:price>490.00</cus:price> <cus:extensionAmount>24500.00</cus:extensionAmount> </cus:item> <cus:item> <cus:partNumber>RND08065</cus:partNumber> <cus:description>Round 8 feet 65 count</cus:description> <cus:quantity>9</cus:quantity> <cus:price>178.00</cus:price> <cus:extensionAmount>7852.00</cus:extensionAmount> </cus:item> </cus:items> </cus:customerOrder> </soapenv:Body> </soapenv:Envelope>The above order message contains a collection of order "items". Each entry in the collection is represented by an "item" element. The OGNL expressions for the order item "partNumber" is constructed as "customerOrder.items[0].partnumber" and "customerOrder.items[1].partnumber". As you can see from this, the collection entry element (the "item" element) makes no explicit appearance in the OGNL expression. It is represented implicitly by the indexing notation. In terms of an Object Graph (Option 1 above), this could be represented by an Order object instance (keyed on the map as "customerOrder") containing an "items" list ( {@link java.util.List} or array), with the list entries being "OrderItem" instances, which in turn contains"partNumber" etc properties.
Option 2 (above) provides a quick-and-dirty way to populate a SOAP message without having to create an Object model ala Option 1. The OGNL expressions that correspond with the SOAP operation parameters are exactly the same as for Option 1, except that there's not Object Graph Navigation involved. The OGNL expression is simply used as the key into the {@link Map}, with the corresponding key-value being the parameter.
The XStream approach (Option 1) is configured on the action as follows:
<action name="soapui-client-action" class="org.jboss.soa.esb.actions.soap.SOAPClient"> <property name="wsdl" value="http://localhost:18080/acme/services/OrderManagement?wsdl"/> <property name="SOAPAction" value="http://www.acme.com/OrderManagement/GetOrder"/> <property name="paramsLocation" value="get-order-params" /> <property name="responseLocation" value="get-order-response" /> <property name="responseXStreamConfig"> <alias name="customerOrder" class="com.acme.order.Order" namespace="http://schemas.acme.com/services/CustomerOrder.xsd" /> <alias name="orderheader" class="com.acme.order.Header" namespace="http://schemas.acme.com/services/CustomerOrder.xsd" /> <alias name="item" class="com.acme.order.OrderItem" namespace="http://schemas.acme.com/services/CustomerOrder.xsd" /> </property> </action>In the above example, we also include an example of how to specify non-default named locations for the request parameters {@link Map} and response object instance.
We also provide, in addition to the above XStream configuration options, the ability to specify field name mappings and XStream annotated classes.
<property name="responseXStreamConfig"> <fieldAlias name="header" class="com.acme.order.Order" fieldName="headerFieldName" /> <annotation class="com.acme.order.Order" /> </property>Field mappings can be used to map XML elements onto Java fields on those occasions when the local name of the element does not correspond to the field name in the Java class.
To have the SOAP response data extracted into an OGNL keyed map (Option 2 above) and attached to the ESB {@link Message}, simply replace the "responseXStreamConfig" property with the "responseAsOgnlMap" property having a value of "true" as follows:
<action name="soapui-client-action" class="org.jboss.soa.esb.actions.soap.SOAPClient"> <property name="wsdl" value="http://localhost:18080/acme/services/OrderManagement?wsdl"/> <property name="SOAPAction" value="http://www.acme.com/OrderManagement/GetOrder"/> <property name="paramsLocation" value="get-order-params" /> <property name="responseLocation" value="get-order-response" /> <property name="responseAsOgnlMap" value="true" /> </action>To return the raw SOAP message as a String (Option 3), simply omit both the "responseXStreamConfig" and "responseAsOgnlMap" properties.
Transformation of the SOAP request (before sending) is supported by configuring the SOAPClient action with a Smooks transformation configuration property as follows:
<property name="smooksTransform" value="/transforms/order-transform.xml" />The value of the "smooksTransform" property is resolved by first checking it as a filesystem based resource. Failing that, it's checked as a classpath resource and failing that, as a URI based resource.
<property name="SOAPNS" value="http://www.w3.org/2009/09/soap-envelope"/>This is an optional property and can be used to specify the SOAP schema that should be used by OGNL. @author tom.fennelly@jboss.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|