Just ran into an interesting scenario. We have a business object with a required attribute (amongst a sea of non-required ones). In a business object map, we only set the non-required ones and never set the required ones to any value.
In the above example, ‘productStatus’ is required, ‘name’ is not.
This is the Mediation Flow Component that my response flow is using. The map is being called via a Custom Mediation and then it gets passed onto an XSLT. This XSLT just adds some header information into the body of the message and match maps the business data from source to target.
When the response is serialized via a SOAP/HTTP we see the following XML:
<product> <name>ADSL</name>
<productstatus></productstatus>
</product>
Which is correct. The name field is populated from the BO Map and the productStatus field is present because it is required.Now, an interesting thing happens when we change the XSLT in the response MFC to a Message Element Setter. Now when the message is serialized, we get:
<product> <name>ADSL</name> </product>
‘productStatus’ is not present in the serialized message. Well that’s a no-no. A strict Web Service client would not be able to consume this response object.
So what happened to our required element? Simply, the XSLT transformation engine is smart enough to realize that ‘productStatus’ is required and the match map creates the element for us. The MessageElementSetter primitive assumes that the business object is already valid, so it doesn’t populate required fields.
What surprises me is why the Business Object Mapping runtime does not:
- Give me some kind of visual indication in the main editor that a field is required
- Set required elements to “”, given that they are required in order to serialize a valid message
So watch out when you are dealing with business object maps that your required elements are set properly. If you don’t, you can ‘catch all’ the missing elements using the XSLT primitive.
Related Posts
