| Author |
Message
|
| gags0409 |
 Posted: Mon Mar 25, 2019 2:13 am Post subject: Environment Variable & Monitoring |
 |
|
Novice
Joined: 25 Mar 2019
Posts: 22
|
Hi Team,
I have a scenario , in which I have to save the incoming message to an environment Variable like m SET Environment.Variables.inpMsg = InputRoot.
But during monitoring when I am using this same string Environment.Variables.inpMsg I am getting parser exception ,
So, I tried using this statement
CREATE LASTCHILD OF Environment.Variables DOMAIN ('XMLNSC') TYPE XMLNSC.Folder NAME 'XMLNSC';
SET Environment.Variables.XMLNSC = InputRoot.XMLNSC;
Everything is working fine except I
1. I am not able to log entire input message
2. WHat if a message other than Xmlnsc is invoked
Please assist. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Mar 25, 2019 4:56 am Post subject: Re: Environment Variable & Monitoring |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gags0409 wrote: |
| But during monitoring when I am using this same string Environment.Variables.inpMsg |
What monitoring? Why exactly are you trying to save this message? What do you use it for?
| gags0409 wrote: |
| 1. I am not able to log entire input message |
What other parts of the message do you want to log and why can't you use the same method to store them?
| gags0409 wrote: |
| 2. WHat if a message other than Xmlnsc is invoked |
You use the domain appropriate to that message.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gags0409 |
| Posted: Mon Mar 25, 2019 6:25 am Post subject: |
|
|
Novice
Joined: 25 Mar 2019
Posts: 22
|
What monitoring? Why exactly are you trying to save this message? What do you use it for?
Sorry , I believe I was not clear enough. By monitoring I mean triggering Monitoring events in IIB 10 .
Scenario is as per requirement we need to store and log the original message after the transaction has ended , so we are storing the original message in Environment.Variables.inpMsg and at the end sending this as monitoring event in one of the node, which triggers logging flow where we have MQ/inp node set as XMLNSC (message domain) . In this flow I am getting parser exception .
What other parts of the message do you want to log and why can't you use the same method to store them?
I need properties , http headers as well to log . |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 25, 2019 6:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gags0409 wrote: |
| Sorry , I believe I was not clear enough. |
Still not clear enough. Because this:
| gags0409 wrote: |
| By monitoring I mean triggering Monitoring events in IIB 10 . |
is at odds with
| gags0409 wrote: |
| we are storing the original message in Environment.Variables.inpMsg and at the end sending this as monitoring event in one of the node |
If you're using the inbuilt monitoring events in IIB, there's no need to put anything in the environment tree. Having the event include the original input message is one click box. As stated here:
| Quote: |
A monitoring event can also contain the following items:
- Application data extracted from the message.
- Part or all of the message bit stream. All nodes can produce bit streams, which can be included in monitoring events.
|
If instead you mean that you're storing in in the environment tree so you can generate your own monitoring message, then clearly I ask why, but you can include the HTTP headers and the properties in the environment tree (under the relevant domain) as easily as you can store the XML.
Note that if you feed the HTTP headers to an MQ input node that's expecting XML, you're going to get a parser exception for obvious reasons. Likewise with the properties.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 25, 2019 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Before one of our regular readers pings me for quoting IIBv10, it's true in ACEv11 as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gags0409 |
| Posted: Thu Mar 28, 2019 11:37 pm Post subject: |
|
|
Novice
Joined: 25 Mar 2019
Posts: 22
|
Thanks for the information ,
1. We are storing in environment the original Payload , as per the requirement that once the transaction is successfuly we need to log the original message by emitting monitoring event from one of the nodes by using Monitoring tab and in Payload selecting $Root/. , and this is OutputRoot = Environment.Variables.inpMsg .
The problem is we are not sure of the headers which we might receive so is there any generic approach to handle the entire paylaod instead of
CREATE LASTCHILD OF Environment.Variables DOMAIN ('XMLNSC') TYPE XMLNSC.Folder NAME 'XMLNSC';
SET Environment.Variables.XMLNSC = InputRoot.XMLNSC; |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Fri Mar 29, 2019 1:34 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
hi...not sure why you are copying the payload temporarily to the Environment tree in order to emit the payload along with the monitoring event. You could achieve the same by either enabling monitoring directly on the last node of the flow which creates the output message (eg:- MQOutputnode) Or using a logging node/subflow connected after this node and enable monitoring events on it.
Eg:- Go to the 'Monitoring' properties of the node and add an event to it, you can include the payload (as bitstream usually with base64binary encoded which means you don't need to worry about the domain of the data at this point) by selecting 'Include bitstream data in payload'.
You can later extract the payload bitstream from the emitted events and do further logging processing on it (eg:- save it somewhere).
You can do the same for logging the input message by enabling monitoring as explained above directly on the Input node/logging node/subflow |
|
| Back to top |
|
|
| gags0409 |
| Posted: Fri Mar 29, 2019 2:25 am Post subject: |
|
|
Novice
Joined: 25 Mar 2019
Posts: 22
|
| Hi , I am copying the payload in environment because there is transformation of the payload downstream , so at the we are logging both the messages original and xformed one. |
|
| Back to top |
|
|
| abhi_thri |
| Posted: Fri Mar 29, 2019 2:57 am Post subject: |
|
|
Knight
Joined: 17 Jul 2017
Posts: 516
Location: UK
|
| gags0409 wrote: |
| Hi , I am copying the payload in environment because there is transformation of the payload downstream , so at the we are logging both the messages original and xformed one. |
hi...where exactly are you transforming the payload? if you take the simplest case of message transformation within a compute node, you can log both the input message coming into the node and the transformed output message send out of the node by configuring monitoring events - configure one for the 'in' terminal along with the payload, do the same for the 'out' terminal...no need to use the Environment tree |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 29, 2019 4:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| abhi_thri wrote: |
| gags0409 wrote: |
| Hi , I am copying the payload in environment because there is transformation of the payload downstream , so at the we are logging both the messages original and xformed one. |
hi...where exactly are you transforming the payload? if you take the simplest case of message transformation within a compute node, you can log both the input message coming into the node and the transformed output message send out of the node by configuring monitoring events - configure one for the 'in' terminal along with the payload, do the same for the 'out' terminal...no need to use the Environment tree |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
