| Author |
Message
|
| john.ormerod |
 Posted: Wed Nov 25, 2020 5:33 am Post subject: IIB10: Can't find value in o/p msg from Aggregate Reply node |
 |
|
Apprentice
Joined: 14 Feb 2017
Posts: 49
|
Hello
I'm using IIB 10.0.0.7 in Ubuntu 20.04
In a node that receives the message from an Aggregate Reply node, I want to find a value in the payload. InputRoot.XMLNSC.xxx failed to find the value.
I used the Flow Exercise to view the message contents. There are two xml elements before the first XMLNSC element (there are several in the whole msg).
Below shows the, mostly collapsed, elements copied from the Exerciser
| Code: |
<message>
<Properties>
</Properties>
<ComIbmAggregateReplyBody>
<OrderCreate>
<Properties>
</Properties>
<MQMD>
</MQMD>
<XMLNSC>
<OrderEnvelope>
<Header>
<OrderNumber>X-123456789</OrderNumber>
<CustomerNumber>CF-C-FAIZ01</CustomerNumber>
</Header>
<PriceData> |
I coded the IF stmt as
| Code: |
IF InputRoot.ComIbmAggregateReplyBody.OrderCreate.XMLNSC.OrderEnvelope.Header.OrderNumber = 'X-123456789' THEN
|
When I tried to retrieve the data 'envelope' out of the Aggregate Reply node, no data was available, but there was an error msg telling me that it had all gone horribly wrong (sorry, I didn't capture it, and could not recreate it).
My conclusion is that the xml path used above is not correct. I am at a loss to work out what it should be. A google search yielded nothiing.
Is there someone out there who can help?
Regards, John |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Nov 25, 2020 5:50 am Post subject: Re: IIB10: Can't find value in o/p msg from Aggregate Reply |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| john.ormerod wrote: |
| I used the Flow Exercise to view the message contents. There are two xml elements before the first XMLNSC element (there are several in the whole msg). |
When you have this kind of "it's not where it should be" problem, nothing beats a old school Trace node. Debugger, Flow Exerciser, they all interpret what the tree looks like.
Trace out the Root immediately before the compute and this should give you a clearer indication of what your ESQL needs to look like.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| john.ormerod |
| Posted: Wed Nov 25, 2020 6:11 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2017
Posts: 49
|
Hi Vitor
Many thanks for your speedy reply.
I'm a 'Sunday driver' when it comes to IIB - just helping out.
Will do that.
Rgds, John |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 25, 2020 6:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| john.ormerod wrote: |
I'm a 'Sunday driver' when it comes to IIB - just helping out.
|
We've all been driving in the "why does that statement not find any value" car at some point.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| john.ormerod |
| Posted: Mon Nov 30, 2020 2:48 am Post subject: |
|
|
Apprentice
Joined: 14 Feb 2017
Posts: 49
|
Hi Vitor
My experienced colleague used the debuger to determine the path.
He concluded that my assumption was correct. He entered it his Toolklt and it worked when deployed!
Just goes to show that: it's not who you know, but what you know.
Anyway, topic closed and thanks for you help.
Regards, John |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 30, 2020 5:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| john.ormerod wrote: |
| My experienced colleague used the debuger to determine the path. |
a) Glad you got your problem resolved
b) I still maintain there's nothing better than an olde-timye Trace node
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
