| Author |
Message
|
| pawel_janowski |
 Posted: Wed Aug 01, 2007 8:24 am Post subject: MRM messages once again |
 |
|
Apprentice
Joined: 13 Dec 2006
Posts: 38
|
Hi!
I didn't manage to resolve my problems with messages in MRM domain.
I use the code as follows (to build a message to be put out through PROPAGATE):
...
| Code: |
SET OutputRoot.Properties.MessageType = 'sendSMSToken';
SET OutputRoot.MRM.header.processingTimestamp.value = InputLocalEnvironment.MRM.header.processingTimestamp.value;
|
I've got the message type 'sendSMSToken' defined in my MRM (in mxsd).
Message set and format are set correctly in MQRFH2 in 'mcd' folder. In Toolkit I can see correct reference to 'header' type in mxsd.
When the message is propagated I can see in a trace log sth like this:
2007-08-01 17:42:32.293514 6948 UserTrace BIP4008I: Message propagated to '''out1''' terminal of node 'flows.sendtoken.sendsmstok_v2.sendSMSandReply'.
....
2007-08-01 17:42:32.306060 6948 UserTrace BIP5493W: Message, element or attribute 'processingTimestamp' is self-defining within parent 'header'. The message, element or attribute 'processingTimestamp' did not match with any corresponding artifact in the message model hence it is considered to be self-defining.
If it is not intended that this message, element or attribute be self-defining,
check that the message set is referenced in the message properties, or
modify the message model to correspond to the instance message, or
modify the instance message to correspond to the message model.
2007-08-01 17:42:32.306083 6948 UserTrace BIP5493W: Message, element or attribute 'value' is self-defining within parent 'processingTimestamp'. The message, elemen
t or attribute 'value' did not match with any corresponding artifact in the message model hence it is considered to be self-defining.
If it is not intended that this message, element or attribute be self-defining,
check that the message set is referenced in the message properties, or
modify the message model to correspond to the instance message, or
modify the instance message to correspond to the message model.
The question is why WMB does not recognize the type of the 'header' element of 'sendSMSToken' and how/if can I enforce datatyping in broker?
Any ideas?
Regards,
Pawel |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Aug 01, 2007 8:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Are you working with XML documents, that you've modelled?
If so, the most likely cause is that the namespaces on the elements in the document don't match the namespaces on the elements in the model.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pawel_janowski |
| Posted: Wed Aug 01, 2007 8:48 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 38
|
| jefflowrey wrote: |
Are you working with XML documents, that you've modelled?
If so, the most likely cause is that the namespaces on the elements in the document don't match the namespaces on the elements in the model. |
Thanks.
I think - this is not a case, because I try to build a message (of type 'sendSMSToken' (somehow) from scratch. In the other words - I've got an input messge of XML type, I parse it and according to its content I generate different message (but from the same message set). And in the moment of propagation, when broker tries to apply to it correct serialization method it does not recognize the message - so it can't find in the message set correct definitions for message fields - and so creates those fields as self defined.
One again sth from the trace:
2007-08-01 18:28:20.160596 6950 UserTrace BIP2537I: Node 'flows.sendtoken.sendsmstok_v2.sendSMSandReply': Executing statement ''SET OutputRoot.MRM.header.processi
ngTimestamp.value = InputLocalEnvironment.MRM.header.processingTimestamp.value;'' at ('flows.sendtoken.sendsmstok_v2_sendSMSandReply.Main', '66.3').
2007-08-01 18:28:20.160642 6950 UserTrace BIP2539I: Node 'flows.sendtoken.sendsmstok_v2.sendSMSandReply': Evaluating expression ''InputLocalEnvironment.MRM.header.p
rocessingTimestamp.value'' at ('flows.sendtoken.sendsmstok_v2_sendSMSandReply.Main', '66.57'). This resolved to ''InputLocalEnvironment.MRM.header.processingTimestamp.value
''. The result was ''ROW... Root Element Type=50331659 NameSpace='' Name='value' Value=TIMESTAMP '2007-08-01 18:28:19'''.
As you can see broker recognizes on input the correct datatype (of TIMESTAMP), but when it tries to format the message on output it does not find the leaf type of the element and passes it as a string (and not as a type defined in MRM which enforces the format of the timestamp).
Regards.
Pawel
_________________
Pawel Janowski |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 01, 2007 8:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's complaining that "proccessingTimestamp" is self-defining. This is causing "processingTimestamp.value" to be also self-defining.
The mismatch between namespaces could even be higher up the element tree than that, too.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pawel_janowski |
| Posted: Wed Aug 01, 2007 9:05 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 38
|
| jefflowrey wrote: |
It's complaining that "proccessingTimestamp" is self-defining. This is causing "processingTimestamp.value" to be also self-defining.
The mismatch between namespaces could even be higher up the element tree than that, too. |
If so than how can I enforce correct namespace to the element 'header' or
its subelement 'processingTimestamp'? And is this the problem of namespace - not a datatype?
Pawel
_________________
Pawel Janowski |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 01, 2007 9:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You are setting OutputRoot.MRM.header.processingTimestamp to be equal to InputRoot.MRM.header.processingTimestamp.
So it's *likely*, not guaranteed, that the namespace on either InputRoot.MRM.header or InputRoot.MRM.header.processingTimestamp is not the same as the namespace that is defined in the output model.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pawel_janowski |
| Posted: Wed Aug 01, 2007 9:22 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 38
|
| jefflowrey wrote: |
You are setting OutputRoot.MRM.header.processingTimestamp to be equal to InputRoot.MRM.header.processingTimestamp.
So it's *likely*, not guaranteed, that the namespace on either InputRoot.MRM.header or InputRoot.MRM.header.processingTimestamp is not the same as the namespace that is defined in the output model. |
I agree but I dare  to claim that the problem is not with a an input message with output one. Let's assume that I've no input message at all. My flow builds the output message completely from scratch - it creates all the elements of the message - MQMD and MQRFH2 headers and MRM as a body of the message. In such situation I would like to enforce somehow that the MRM body of the output message is of some datatype (let's say 'sendSMSToken') - is it possible?
Pawel
_________________
Pawel Janowski |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 01, 2007 9:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm not claiming anything. I'm merely saying that, in my experience, the problem you are seeing is usually caused by mismatched namespaces.
In the case of creating a new field from scratch - RATHER THAN copying an Input element - then there won't be a mismatch in namespaces. And you won't have this issue.
And the MRM will validate your data against the model.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Aug 01, 2007 9:38 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
The message tree which is being serialized does not match with the message definition.
So far this discussion has concentrated on namespaces. The problem may be a namespace mismatch. Alternatively, it could be a name mismatch. The way to diagnose it is:
- insert a Trace node with pattern ${Root} just before the output node
- start at the 'header' element in the message tree. It matches with the message definition ( otherwise you would have got another BIP5493W )
- for each child of 'header' in the message tree, check that its name and namespace match the name and namespace defined in the message definition. |
|
| Back to top |
|
|
| pawel_janowski |
| Posted: Wed Aug 01, 2007 9:40 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 38
|
| jefflowrey wrote: |
I'm not claiming anything. I'm merely saying that, in my experience, the problem you are seeing is usually caused by mismatched namespaces.
In the case of creating a new field from scratch - RATHER THAN copying an Input element - then there won't be a mismatch in namespaces. And you won't have this issue.
And the MRM will validate your data against the model. |
Sorry - I didn't want to be unpolite 'claiming'. I've checked this - I've change the SET operation to set the CURRENT_TIMESTAMP value instead of InputRoot..... Unfortunately - the problem seems to be the same. In the trace I can see the same BIP message saying that processingTimestamp is not recognized 
Maybe its possible to say somehow to SET statement to use the namespace and datatype?
Regards.
Pawel
_________________
Pawel Janowski |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 01, 2007 9:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kimbert wrote: |
| The problem may be a namespace mismatch. Alternatively, it could be a name mismatch. |
Name mismatches are a *lot* easier to spot than a namespace mismatch of, say, forgetting a / at the end of a namespace ("http://example.com/my/name/space/" versus "http://example.com/my/name/space").
That was a couple of hours I could have spent on other things.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pawel_janowski |
| Posted: Wed Aug 01, 2007 11:13 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 38
|
So once again - is it possible to say explicitly (in SET or somwhere) what the namespace should be used by broker?
Pawel
_________________
Pawel Janowski |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 01, 2007 11:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Not with MRM, not really.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pawel_janowski |
| Posted: Wed Aug 01, 2007 11:47 am Post subject: |
|
|
Apprentice
Joined: 13 Dec 2006
Posts: 38
|
Well. I've checked once again to be 100% sure. All my messages in MRM domain use the 'header' element of the same 'OperationHeader' type, so it is impossible to have the mismach between input and output, I suppose. I've asked broker to write namespaces durring serialization of the message to XML using xsi:type output policy of message set and it looks correct (it has got the type of 'OperationHeader' from correct namespace). Any ideas what else to check?
Pawel
_________________
Pawel Janowski |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 01, 2007 11:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It might not be the header element.
It might not be the namespace in the *input model*. It might be the namespace in the *message*.
Again, kimbert suggests you also check spelling (and case) of element names.
Thirdly, double-check the spelling of the namespaces character by character, one single character wrong will throw the whole thing off.
Otherwise, go back to your debug trace, and read it carefully through, looking for the very very first time it reports a self-defining element. That's the element to focus on.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
