Set Message Type Primitive
March 16, 2008 Leave a comment
There’s some confusion around about what the new Set Message Type primitive in WebSphere ESB v6.1 does. I’m writing this tip as I myself was recently a victim of this confusion, even though I should have known better! Contrary to what the name might imply, it does not set the type of part of a message, or of part of a message. Instead, it merely asserts that a weakly-typed part of the message is actually of a stronger (more well-defined) type. There’s a subtle, but important, difference, as this means that it does not perform the actual data conversion for you.
(Note: when we say ‘message’ above, in practice we mean a SMO – a Service Message Object – which is what flows through a mediation flow).
Because of this, the Set Message Type primitive has no runtime behaviour in a mediation flow. It is best to think of it as a development-time placeholder: something that indicates that parts of downstream messages are more strongly typed than they were upstream (or vice-versa, if the ‘Reset’ checkbox is ticked). This allows WebSphere Integration Developer to provide the capability to work with parts of those messages directly (for example, the XSLT primitive can be used to map from and to them).
Sometimes the Set Message Type primitive is sufficient (for example, if you have an incoming message containing a field of type A, and you know that actually contains an object of type B – where B inherits from A – you can you the primitive to treat it as such).
However, sometimes you may want to actually make the message type more specific yourself – if you are creating a structure to work with, for example. A common technique is to use a custom mediation, and the BOFactory to create the new, more specific Business Object(s) that you want to include in the Service Message Object. You’ll most likely want to do this before your Set Message Type primitive in the flow (in other words, you make the SMO more specific, then you assert that it’s more specific).
This to Chris Markes and Andrew Borley for the pointers that led to this tip.