| Author |
Message
|
| nize |
 Posted: Fri Sep 04, 2009 12:36 am Post subject: More info on unresolved choice handling |
 |
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
Hi,
I have been trying to make a flow using more or less complex repeated unresolved choice handling work for a while (  ). The only documentation on the subject I have found is the parts on the video sample. I have not seen it written explicitely anywhere if the branches need to be of equal length, which are the limitations for making the parser selecting branches in the ESQL code. I have several issues and I have realized that is too heavy to trial-and-error.
Do you guys know any nice tutorial, list of rules or other type of documentation?
My message is generated from a C struct and can have several parts which must come in a certain order, but of which some may be left out.
Until I find such documentation I will switch strategy: I plan to parse one part at the time, putting the parsed part in the environment and then use ESQL to determine the next part, pass the remaining BLOB to a label, use resetcontentdescriptor, parse the BLOB using a new message definition and so on until the whole message is parsed. This is not as pretty as the "unresolved choice handling" strategy which would be completed in a single compute node though... |
|
| Back to top |
|
 |
| kimbert |
| Posted: Fri Sep 04, 2009 1:24 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Fair comment - the rules are not exactly well documented.
You do need to ensure that all branches of the choice are the same length. Otherwise, the parser cannot extract the choice as a BLOB and continue parsing the rest of the message. |
|
| Back to top |
|
|
| nize |
| Posted: Fri Sep 04, 2009 2:06 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
I dont understand why this (always) has to be a requirement. Are you sure it is? See this example message:
I
choice
--------A
----------------C
----------------choice
------------------------D
------------------------E
--------B
----------------F
----------------choice
------------------------D
------------------------E
sorry for the looks of the tree!
Here I, C, D, E and F are sequences of simple elements. An element in I determines whether to use track A or B. Lets assume that track A is the correct choice for a specific message. Then the ESQL program would realize that by reading info from I and then try to reference the elements in C and thereby the leading the parser to that track. Why would it matter the length of the B track? The parser would not need to care since the B track is the last element in the modeled message. Simplified: To find the first element in C it would just need to read the first bit after the last read I element.
Am I getting things wrong? Since I dont find much documentation I am trying to see it from the MRM parser developers perspective. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Sep 04, 2009 4:04 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I agree with your analysis - in theory it should be possible to handle this case because the choice is at the end of the bit stream. In recent versions, the CWF parser has got better at handling this type of model, so I suggest that you give it a try and see what happens.
| Quote: |
| sorry for the looks of the tree! |
Use [code] tags to preserve indentation. Much easier  |
|
| Back to top |
|
|
| nize |
| Posted: Fri Sep 04, 2009 4:35 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
I believe I have concluded that it doesnt work (even though I am using WMB 6.1)... or anyway I have problems and as long as I can not exclude that this is the reason, I decide to try the alternative method.
thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 04, 2009 5:35 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| nize wrote: |
I believe I have concluded that it doesnt work (even though I am using WMB 6.1)... or anyway I have problems and as long as I can not exclude that this is the reason, I decide to try the alternative method.
thanks |
I have tried with success following rule (V 6.0.0.6)
Before you allocate any value from a source below the choice, make sure the choice has been resolved.
i.e. you have a tree like this
| Code: |
-------------A
-------------B
-----------------choice
--------------------C
--------------------D
-------------E
|
Doesn't matter what you have in E. Before you can access it in the parser you would need to have decided whether you are going to access B values through C or through D. What this means is that you must have allocated to something ( a variable if need be) a value in C or in D.
| Code: |
SET mya = sourceref.A;
SET mye = sourceref.E;
|
will likely blow up with unresolved choice.
| Code: |
SET mya = sourceref.A;
SET myx = sourceref.B.D;
SET mye = sourceref.E; |
should be ok.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Sep 04, 2009 5:43 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| fjp_saper : Your advice is sound, but you don't say whether you tested this with unequal-length choice branches. I think that's the crux of nize's problem. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Sep 04, 2009 5:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kimbert wrote: |
| fjp_saper : Your advice is sound, but you don't say whether you tested this with unequal-length choice branches. I think that's the crux of nize's problem. |
I can't remember specifically but I believe yes we tested this with unequal length branches...
I had a specific section at the begin of the esql mapping procedure just to resolve choices before I got into the meat of the mapping.
Mind this is fairly easy to determine in an xml parser (check lastmove(reference)).
If you have a cobol structure (CWF), my experience has in fact only been with equal length branches (Redefines).
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nize |
| Posted: Mon Sep 07, 2009 11:08 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
| thanks fbj_saper, since neither you have the experience from unequally long branches in the CWF case, I have decided to continue with the backup plan. |
|
| Back to top |
|
|
|
|
