| Author |
Message
|
| deepak_paul |
 Posted: Tue Mar 16, 2010 8:21 am Post subject: Parsing Environment Variables |
 |
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
All,
I am storing teh whole input body to Environment variables and then after two three comput nodes, i am retrieving teh field value stored in the environment variables. I am not mentioning any Parser to Environemnet variables tree to get parsed.
| Code: |
SET Environment.Variables.MyMessage = InputBody;
SET OutputRoot.XMLNSC.MyMsg.Third = FIELDVALUE(Environment.Variables.MyMessage.First.Second.Third);
SET OutputRoot.XMLNSC.MyMsg.Sis = FIELDVALUE(Environment.Variables.MyMessage.First.Second.Sub);
|
I have tested this case with XML and MRM input messsages. I am succesfully able to get thoses fields from Environment variables.
I am just wondering whether we should really mention the parser name to Environment variables to get parsed as desired. in What scenero, it is a must thing.
Note: My flow dsign as follows:
MQInput[Completely Parsed by respective Parser(MRM/XMLNSC)] --> Compute[assigning to ENV]-->Compute2[retriving from ENV]-->MQOutput |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Mar 16, 2010 8:28 am Post subject: Re: Parsing Environment Variables |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deepak_paul wrote: |
Note: My flow dsign as follows:
MQInput[Completely Parsed by respective Parser(MRM/XMLNSC)] --> Compute[assigning to ENV]-->Compute2[retriving from ENV]-->MQOutput |
Why? What's the requirement for this? It seems a bit cumbersome... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Mar 16, 2010 9:39 am Post subject: Re: Parsing Environment Variables |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
| Vitor wrote: |
| deepak_paul wrote: |
Note: My flow dsign as follows:
MQInput[Completely Parsed by respective Parser(MRM/XMLNSC)] --> Compute[assigning to ENV]-->Compute2[retriving from ENV]-->MQOutput |
Why? What's the requirement for this? It seems a bit cumbersome... |
Vitor,
It is test message flow. You need not dive deep into it.
Please share if you have any clue....
_________________
Regards
Paul |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Mar 16, 2010 10:03 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
If you are copying parsed data into the Environment or LocalEnvironment tree, it is always best to create the parent node using the CREATE statement with the DOMAIN clause. Make sure that the parser specified by the DOMAIN clause is the same as the one which parsed the data.
If you don't follow this rule, the parser-specific data in the field type will get zeroed during the copy. That will produce a whole range of unpredictable results, depending on what the original parser was. One common symptom is that XML attributes turn into tags. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 16, 2010 10:11 am Post subject: Re: Parsing Environment Variables |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deepak_paul wrote: |
| It is test message flow. You need not dive deep into it. |
Yes, but clearly you're testing this for some reason. What I'm trying to work out is why you feel the need to store the input message in the Environment tree so as to better answer your question.
| deepak_paul wrote: |
| Please share if you have any clue.... |
Clues are what I'm trying to get from you. If you're just asking do you need to associate a parser with data in the Environment then it's yes. I'm just trying to add a little value with a better solution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Mar 16, 2010 11:06 am Post subject: Re: Parsing Environment Variables |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
| Vitor wrote: |
| deepak_paul wrote: |
| It is test message flow. You need not dive deep into it. |
Yes, but clearly you're testing this for some reason. What I'm trying to work out is why you feel the need to store the input message in the Environment tree so as to better answer your question.
|
OK. The actual requirement for which i was trying out with a test message flow is to call a subflow in between the main flow but need to process the (subflow) response with the actual input message. So i have been thinking to store the whole input body messsage to environment variables which can be later retrieved fieldwise and processed with Subflow response fields.
_________________
Regards
Paul |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 16, 2010 11:10 am Post subject: Re: Parsing Environment Variables |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deepak_paul wrote: |
| OK. The actual requirement for which i was trying out with a test message flow is to call a subflow in between the main flow but need to process the (subflow) response with the actual input message. So i have been thinking to store the whole input body messsage to environment variables which can be later retrieved fieldwise and processed with Subflow response fields. |
Why not decouple the subflow & use an MQGet node? Or a collector?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Mar 16, 2010 11:28 am Post subject: |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
| kimbert wrote: |
If you are copying parsed data into the Environment or LocalEnvironment tree, it is always best to create the parent node using the CREATE statement with the DOMAIN clause. Make sure that the parser specified by the DOMAIN clause is the same as the one which parsed the data.
If you don't follow this rule, the parser-specific data in the field type will get zeroed during the copy. That will produce a whole range of unpredictable results, depending on what the original parser was. One common symptom is that XML attributes turn into tags. |
I think I can consider this as a best practice, as i think that, as long as those statements from me did not result any error, it can be valid anyway.
_________________
Regards
Paul |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Mar 16, 2010 11:31 am Post subject: Re: Parsing Environment Variables |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
| Vitor wrote: |
| deepak_paul wrote: |
| OK. The actual requirement for which i was trying out with a test message flow is to call a subflow in between the main flow but need to process the (subflow) response with the actual input message. So i have been thinking to store the whole input body messsage to environment variables which can be later retrieved fieldwise and processed with Subflow response fields. |
Why not decouple the subflow & use an MQGet node? Or a collector? |
I feel it is not as much complicated as to buy a queue and/or play with collector nodes but a doable in compute node itself.
_________________
Regards
Paul |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Mar 16, 2010 11:53 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I think I can consider this as a best practice, as i think that, as long as those statements from me did not result any error, it can be valid anyway. |
I assume you mean 'I think I can ignore this advice on my project'. That's fine - as long as you understand exactly what the parser-specific bits of the field type are used for, and you are sure that your project will never ever use them. |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Mar 16, 2010 12:19 pm Post subject: |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
Yes Kimbert. We dont handle with Attributes at the input request in our projects. This may be a small reason i prefered tha way.
I would certainly apply your advice when i come to.
One curious question is how environment variables store the whole input message with the structure?[stores the logical tree?]
_________________
Regards
Paul |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Mar 16, 2010 2:38 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| We dont handle with Attributes at the input request in our projects. This may be a small reason i prefered tha way. |
What about all of the other XML constructs which make use of parser-specific field types? Are you certain that your project will never, ever use any of them?  |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Mar 16, 2010 2:46 pm Post subject: |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
When there is a need, i will certainly use your advice.
_________________
Regards
Paul |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Mar 16, 2010 2:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deepak_paul wrote: |
| When there is a need, i will certainly use your advice. |
Why build something now which will need to be changed later?
Also make sure the business owner of the flow has signed off on this design. If a major redesign is needed later because someone wants to use attributes in XML then you'll need to be covered. Or they'll need to be told they can't add attributes to the XML.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Mar 16, 2010 2:57 pm Post subject: |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
| Vitor wrote: |
| deepak_paul wrote: |
| When there is a need, i will certainly use your advice. |
Why build something now which will need to be changed later?
Also make sure the business owner of the flow has signed off on this design. If a major redesign is needed later because someone wants to use attributes in XML then you'll need to be covered. Or they'll need to be told they can't add attributes to the XML. |
This is also a good advice. Thanks guys.
_________________
Regards
Paul |
|
| Back to top |
|
|
|
|
