| Author |
Message
|
| PEPERO |
 Posted: Sun Feb 01, 2015 7:51 am Post subject: File Read Node |
 |
|
Disciple
Joined: 30 May 2011
Posts: 177
|
Hi all;
Is it possible to set Input Message Parsing tab attributes( Message Type property for example) at run time?
I mean is it valid using the following statement to change the "Message Type" under the "Input Message Parsing" tab in the FILEREAD node?
| Quote: |
Set OutputRoot.Properties.MessageType = 'msg_' || Environment_Variables_File_ID;
|
|
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun Feb 01, 2015 8:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What have you tried and with what kind of result? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PEPERO |
| Posted: Sun Feb 01, 2015 9:07 am Post subject: |
|
|
Disciple
Joined: 30 May 2011
Posts: 177
|
| The version of the Message broker i'm using doesn't support FILEREAD node. Despit of the necessity of upgrading it to a higher version , i want to know if it is possible to expect a positive result from this issue. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Feb 02, 2015 3:48 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Something similar is possible, but your question is too specific. You need to explain what you are trying to do. Then we can explain how to do it.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| PEPERO |
| Posted: Mon Feb 02, 2015 6:32 am Post subject: |
|
|
Disciple
Joined: 30 May 2011
Posts: 177
|
I have multiple text files each of which have two record formats within themselves. A generic record format for the header of the file which holds the file content information(An 8 byte file identifier, total number of records , etc). The rest of the file (Body records) which can be of specific types (type1 , type2 , ...). There is a file identifier within the generic header first record which determines the type of the other records(Body records).
So i've to define a complex type for the generic file header record format and multiple complex types per each specific body.
In my message flow design using EIPs i've considered an endpoint( file input node) to open and read the first record which would be the header record. When reading this record , the message type of the body records is determined using the file identifire field element value from the header complex type.
Then i've to set the message type attribute of the FileRead node dynamically. At the other hand i've to propagate the first record read message to the out terminal which is of type header. So in my opinion using the properties tree is not convenient because i have to serialize the MRM message header using header complex message type and it couldnot set to a message type for other than this to validate the body records in the FileRead node.
In fact i'm trying to design a generic message flow to process some input files with different message type formats but all of them have to be processed in a same manner. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Feb 02, 2015 6:46 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I think there is a much simpler solution. You need one FileInput node, no FileRead node, and a more flexible model.
1. Design a DFDL model that can parse the entire file, regardless of which subtype it happens to contain.
2. Set the FileInput node to use the model. In WMBv8 and IIBv9 that reduces to 'set the Document Root to point at the outermost element in the model'.
You will probably need some help with 1. but I can supply that.
Any other issues with that approach?
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| PEPERO |
| Posted: Mon Feb 02, 2015 6:52 am Post subject: |
|
|
Disciple
Joined: 30 May 2011
Posts: 177
|
| Unfortunatly at first i've to upgrade from WMB V7.0.0.7 to V8 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 02, 2015 6:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PEPERO wrote: |
| Unfortunatly at first i've to upgrade from WMB V7.0.0.7 to V8 |
You could just as easily create an MRM model that matched the whole data in the file.
But you are much better off upgrading to v9, than staying with v7.
Note, skip v8. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Feb 02, 2015 7:01 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I agree with mqjeff. As always 
Look up 'Message Key' and 'Interpret Element Value As' in the v7 info center.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| PEPERO |
| Posted: Mon Feb 02, 2015 7:09 am Post subject: |
|
|
Disciple
Joined: 30 May 2011
Posts: 177
|
| Previously i used MRM parser and defined One message type inwhich multiple complex types where redefined to each other using "Composition" set to "choice" for the different body records. But since in the CWF all the redefined complex types had to obey the same record length that solution were failed to be continued. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 02, 2015 7:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In MRM, at later levels, you can almost always use a TDS model to handle the data in a CWF model.
That will let you avoid the length restriction.
Particularly since you have a body identifier in the header record. You can use that as a tag.
But DFDL will be easier to use. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Feb 03, 2015 6:21 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Previously i used MRM parser and defined One message type inwhich multiple complex types where redefined to each other using "Composition" set to "choice" for the different body records. |
Correct - CWF is designed for COBOL, and a choice follows the same rules as a COBOL REDEFINES statement.
If you switch to using TDS ( and set the properties as I recommended above ) then you will find that everything works.
But DFDL would be easier...
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
|
|
