Author |
Message
|
nize |
Posted: Mon Sep 07, 2009 3:50 am Post subject: Modeled element has maxOccurs=-1 but CWF only outputs first |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
I guess this is related to the discussion in http://www.mqseries.net/phpBB/viewtopic.php?p=209904, but still not exactly.
I have the following structure:
Code: |
<xs:complexType name="credR">
<xs:annotation>
<xs:documentation>Warranty claim status</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="credRRec">
<xs:complexType>
<xs:sequence>
<xs:element name="nationCode">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:length value="2"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
... <many elements removed for readability> ....
<xs:element minOccurs="0"
name="specCode" nillable="true">
<xs:annotation>
<xs:appinfo source="WMQI_APPINFO">
<cwfInclRep messageSetDefaultRep="CWF1">
<cwfSimpleRep
encodingNull="NullLiteralFill"
encodingNullValue="NUL"
lengthUnits="Bytes"
mrLengthEncoding="fixedLength"
paddingCharacter="NUL"
stringJustification="leftJustify"
typeName="MRCWFStringRep" width="10"/>
</cwfInclRep>
</xs:appinfo>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:length value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
|
I have read that
An unbounded number of occurrences (Max Occurs = -1) is allowed if the element or group is the last child in its parent group, and the group is terminated by the end of the message bit stream. On writing, the writer outputs all occurrences in the message tree, if this number is less than Min Occurs then additional default values are written. (http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/topic/com.ibm.etools.mft.doc/ad10490_.htm)
I input an XML message, which is parsed successfully, but when it serializes it to CWF the output only contain the first credRRec element. What should I do to make it serialize all elements? |
|
Back to top |
|
 |
kimbert |
Posted: Mon Sep 07, 2009 4:33 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
which version of the runtime? |
|
Back to top |
|
 |
nize |
Posted: Mon Sep 07, 2009 4:41 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
|
Back to top |
|
 |
kimbert |
Posted: Mon Sep 07, 2009 4:46 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
The topic which you quoted is from the v6.0 online docs. v5 was significantly weaker in handling maxOccurs=-1 in CWF.
Now you're going to try this in v6.1 and tell me that it fails. I just know it... |
|
Back to top |
|
 |
nize |
Posted: Mon Sep 07, 2009 4:56 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
I think you are right... this is an extract from the v5 documentation (ad10490_):
When parsing or writing a CWF message in the MRM domain, any values specified for the message model properties Min Occurs and Max Occurs are ignored. The number of occurrences of an element is instead determined by either the Repeat Count or Repeat Reference property. However, the message validation functionality of WebSphere Business Integration Message Broker utilizes the Min Occurs and Max Occurs information.
What a problem... I need it to run on this runtime. Is the only way to work around the problem to change the data model to include a counter in the input structure which can be read by the parser when serializing (using Repeat Reference property)?  |
|
Back to top |
|
 |
nize |
Posted: Mon Sep 07, 2009 4:59 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
another alternative I guess would be to count the number of credRRec elements in ESQL and then propagate one new message for each element, letting the receiver handle multiple messages. |
|
Back to top |
|
 |
kimbert |
Posted: Mon Sep 07, 2009 5:01 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
I think you are right |
...phew.
Quote: |
Is the only way to work around the problem to change the data model to include a counter in the input structure which can be read by the parser when serializing (using Repeat Reference property)? |
Errr....
At least, that's the workaround we used to recommend before v6.0 was released. |
|
Back to top |
|
 |
kimbert |
Posted: Mon Sep 07, 2009 5:06 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Well, now that you've suggested an ESQL-assisted solution...you could
- Change your output message definition so that the repeating CredRec is replaced by a binary field.
- Define a message which contains only the CredRec structure
- ASBITSTREAM each CredRec occurrence using the cutdown message definition, and append to a BLOB
- Assign the entire BLOB to the binary field in the output.
...but that seems messier/more work than the Repeat Reference solution. |
|
Back to top |
|
 |
nize |
Posted: Mon Sep 07, 2009 6:18 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
Ok ... here I found another alternative to the one you gave, in case I decide to not have the repeatCount field in the output message.
http://www.mqseries.net/phpBB2/viewtopic.php?p=85798
The receiver "prefers" to not have such field.
Hmm... need to choose strategy...
edit: I will try the one you suggested. Will have to read about ASBITSTREAM ... |
|
Back to top |
|
 |
nize |
Posted: Mon Sep 07, 2009 6:38 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
kimbert wrote: |
...
- Change your output message definition so that the repeating CredRec is replaced by a binary field.
...
- Assign the entire BLOB to the binary field in the output.
|
Really I dont need to model the binary output field in the message set? Is it not sufficient to construct a OutputRoot.BLOB (having the already-serialized data attached)?
edit: at the moment I get an error (Invalid Wire format retreived.) when doing the ASBITSTREAM. This is my ESQL code:
Code: |
CALL CopyMessageHeaders();
SET OutputRoot.Properties.MessageFormat = 'CWF1';
SET OutputRoot.BLOB = ASBITSTREAM(InputBody.credRRec[1]);
|
after the compute node I have put a resentcontentdescriptor (before the MQOutputnode) setting Domain to BLOB. |
|
Back to top |
|
 |
kimbert |
Posted: Mon Sep 07, 2009 10:54 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
Is it not sufficient to construct a OutputRoot.BLOB (having the already-serialized data attached)? |
Yes, in your case that will work. I was forgetting that your repeating CredRec is at the end of the bit stream
Quote: |
I get an error (Invalid Wire format retreived.) when doing the ASBITSTREAM |
Look up the documentation for ASBITSTREAM. Or it might well be simpler to search MQSeries.net for examples - there will be dozens of them.
Code: |
CALL CopyMessageHeaders();
SET OutputRoot.Properties.MessageFormat = 'CWF1'; |
No need for the RCD node, and no need to set the Properties folder. As you will quickly realize once you know how to use ASBITSTREAM correctly. |
|
Back to top |
|
 |
nize |
Posted: Mon Sep 07, 2009 11:00 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
ok, thanks... I will try to find examples of people doing something similar... |
|
Back to top |
|
 |
nize |
Posted: Mon Sep 07, 2009 10:45 pm Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
|
Back to top |
|
 |
nize |
Posted: Tue Sep 08, 2009 1:21 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
Based on the info center doc I wrote this peace of code:
Code: |
SET Environment.var.credR.credRRec = InputBody.credRRec[1];
DECLARE options INTEGER FolderBitStream;
DECLARE testBlob BLOB CAST (
ASBITSTREAM(
Environment.var.credR
OPTIONS options
ENCODING 273
CCSID 1208
SET 'HLMCKR4002001'
TYPE 'credR'
FORMAT 'CWF1'
)
AS BLOB);
|
... but the testBlob is empty according to the debugger. What could be wrong? |
|
Back to top |
|
 |
nize |
Posted: Tue Sep 08, 2009 1:45 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009 Posts: 90
|
I modified the code so it looks like
Code: |
CALL CopyEntireMessage();
DECLARE testBlob BLOB CAST (
ASBITSTREAM(
OutputRoot.MRM
--OPTIONS options
ENCODING 273
CCSID 1208
SET 'HLMCKR4002001'
TYPE 'credR'
FORMAT 'CWF1'
)
AS BLOB);
SET OutputRoot.MRM = NULL;
SET OutputRoot."BLOB"."BLOB" = testBlob; |
and of some reason I get some kind of interesting data in the output. I think it had to do with the environment tree... hmm |
|
Back to top |
|
 |
|