| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Can CWF fields be ignored? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jfrankman |
 Posted: Thu Oct 15, 2009 4:15 pm Post subject: Can CWF fields be ignored? |
 |
|
Apprentice
Joined: 18 Jun 2009
Posts: 36
|
I am working on converting XML to a Fixed Length record. To do this, I created a message set from the XML schema, I then added a physical format for CWF and TDS and then for each field defined its type and length.
For most of the fields in the Message Set I want to define a physical format. However, some fields in the XML I don't want to appear on the fixed width record at all. On the physical properties for my message set is there a way to specify that the field should be ignored (not appear) on the fixed length record? It seems that the MRM parser expects all fields within the MessageSet to appear on the record. Is there a way to handle this, or do I need to create two separate message sets, one for the XML and one for the Fixed Width?
Thanks. |
|
| Back to top |
|
 |
| Vgowda |
| Posted: Thu Oct 15, 2009 7:29 pm Post subject: |
|
|
Acolyte
Joined: 11 Dec 2007
Posts: 61
Location: Bengaluru
|
In a single message set if u are having both XML and CWF it is not possible to leave some of the records because it is Fixed length message. The better way is to create a new message set with which all records are required and map it in compute node.
_________________
Regards
Vinay |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Oct 16, 2009 1:27 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
We need to be careful about terminology here:
- One 'message set' can contain one or more 'messages'. Usually, each message will have a different logical structure. Global elements and types can be used in more than one message.
| Quote: |
| I then added a physical format for CWF and TDS |
a) I assume you meant to say 'CWF and XML'.
b) IBM do not recommend that you put more than one physical format on the same message set. It's not dangerous, but it doesn't usually produce a very maintainable solution.
c) To get around b), why not use XMLNSC to parse the input XML? That way, you don't need the XML physical format ( XMLNSC never even looks at it )
| Quote: |
| some fields in the XML I don't want to appear on the fixed width record at all |
That's OK. Just create a second message in the same message set, and omit the fields that you don't want.
| Quote: |
| the MRM parser expects all fields within the MessageSet to appear on the record. |
Well, the CWF writer does. The TDS writer can sometimes be more tolerant. But Vgowda is correct here - CWF must be strict, otherwise it would write out un-parseable messages.
| Quote: |
| do I need to create two separate message sets, one for the XML and one for the Fixed Width |
No. One message set with two message definitions is what you need. |
|
| Back to top |
|
|
| jfrankman |
| Posted: Fri Oct 16, 2009 6:29 am Post subject: |
|
|
Apprentice
Joined: 18 Jun 2009
Posts: 36
|
Thanks for the tips. The approach I have taken is to:
1. Create one message set
2. Create one Message Definition File
3. Within the message Definition file create Two separate "Messages". The first message "FupRecords" represents the data that is common to both XML and Fixed length records. This contains a physical format for both XML and TDS . The second message "ImageRightFup" contains the first message as well as other fields that I don't want written to the fixed length record.
I handle this in the message flow in the following manner:
A. MQInput input node is set to MRM parsing for "ImageRightFup"
B. ComputeNode takes message and extracts each record from the XML and puts in on the OutputRoot, and changes the format from "ImageRightFup" to "FupRecords" . Each record is propagated to a file output node.
Here is the ESQL in the compute node:
| Code: |
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
--SET Environment.Variables.FileName='zzzzz.txt';
declare uid char ;
set uid = UUIDASCHAR;
Set OutputLocalEnvironment.Wildcard.WildcardMatch =uid;
DECLARE i INTEGER 1;
DECLARE count INTEGER;
SET count = CARDINALITY(InputRoot.MRM.ns2:FupRecords.ns2:FupRecord[]);
WHILE i <= count DO
CALL CopyMessageHeaders();
Set OutputLocalEnvironment.Wildcard.WildcardMatch =uid;
Set OutputRoot.Properties.MessageType='FupRecords'; --input message type is ImageRightFup, since this has fields that are not found on the FUP record, we need to change to a format that does not include these extra fields.
Set OutputRoot.Properties.MessageFormat='Text1';
SET OutputRoot.MRM.ns2:FupRecord = InputRoot.MRM.ns2:FupRecords.ns2:FupRecord[i];
PROPAGATE TO TERMINAL 'out1';
SET i = i+1;
END WHILE;
Set OutputLocalEnvironment.Wildcard.WildcardMatch =uid;
RETURN TRUE;
END; |
This works, but after reading the comments it looks like I should not be mixing physical formats on the same Message (FupRecords). Is this correct? |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Oct 16, 2009 6:59 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| That's a perfectly reasonable approach - but I still think you should be using XMLNSC, not MRM XML. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
