| Author |
Message
|
| Abhinay185127 |
 Posted: Thu Oct 31, 2013 3:09 am Post subject: Reg: Error Handling |
 |
|
Acolyte
Joined: 20 May 2013
Posts: 58
|
Hi,
I have come across a situation.
We are getting one of the request parameters from SAP as string while the one expected at Mainframes is unsigned long.
Now we are using their copybook to create the DFDL.
Although the value passed in the request parameter should have been strictly digits and the flow was working fine. But when we are getting an alphanumeric character the error occurs as expected.
The flow has
MQInput--> FlowOrder -->Compute -->MqOutput
MqInput catch terminal is connected to a exception handler and MqOutput terminal again to a subflow which retries to put the message in queue suppose the queue is down.
Now when the message comes out of Compute node it does not throws an error and the alphnumeric field gets mapped with unsigned long (debugger mode) but when it proceeds to put it in MQ Output it comes out of failure terminal and goes into the subflow with following error.
Unable to serialize element '#xscd(the element). The DFDL serializer cannot convert the xs:string value 'AD123131' o the declared type 'xs:unsignedLong' THE ELEMENT BEING SERIALIZED The Path DFDLErrorHandler.
But since it is a parsing error it was expected that it will go to MQ Input catch terminanl and then to Exception handler but instead it is going to failure terminal of MQ Output.
Kindly please give any suggestions. |
|
| Back to top |
|
 |
| gs |
| Posted: Thu Oct 31, 2013 3:13 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
This sounds like less of a technology issue and more of a an agreement issue.
Either the sending system is corrected/changed to use numerical values only or the integration solution and the receiving system is changed to handle alphanumerics.
I'd initiate a discussion with the sending system and have a look at the requirements that defined the solution. Hope this helps |
|
| Back to top |
|
|
| Abhinay185127 |
| Posted: Thu Oct 31, 2013 3:19 am Post subject: |
|
|
Acolyte
Joined: 20 May 2013
Posts: 58
|
But still why the broker is behaving this way.
In case of a parsing exception shouldn't it go back to the catch terminnal of MQ Input.
Moreover why the error is coming only once the message is trying to go in the MQ Output. The error should have happened as soon as it comes out of the compute. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Oct 31, 2013 3:31 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Abhinay185127 wrote: |
But still why the broker is behaving this way.
In case of a parsing exception shouldn't it go back to the catch terminnal of MQ Input.
|
Not when the parsing error happens for the output message.
| Abhinay185127 wrote: |
| Moreover why the error is coming only once the message is trying to go in the MQ Output. The error should have happened as soon as it comes out of the compute. |
Wrong. In the compute node you construct the logical message structure. It's the MQOutput node that will serialize the message using DFDL. So this is where the parsing error happens. |
|
| Back to top |
|
|
| Abhinay185127 |
| Posted: Thu Oct 31, 2013 3:35 am Post subject: |
|
|
Acolyte
Joined: 20 May 2013
Posts: 58
|
Thanks Esa for clarifying my doubt.
So in that case if we have to send it to the exception handler is there any other way to do it because we want that MQ Failure to be connected only to the subflow that retries to put it again in the queue if queue is down. |
|
| Back to top |
|
|
| Simbu |
| Posted: Thu Oct 31, 2013 3:45 am Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
| Abhinay185127 wrote: |
Thanks Esa for clarifying my doubt.
So in that case if we have to send it to the exception handler is there any other way to do it because we want that MQ Failure to be connected only to the subflow that retries to put it again in the queue if queue is down. |
you can do the validation in Compute node or examine the ExceptionList and act upon it in the failure path. |
|
| Back to top |
|
|
| Abhinay185127 |
| Posted: Thu Oct 31, 2013 3:50 am Post subject: |
|
|
Acolyte
Joined: 20 May 2013
Posts: 58
|
We are just trying to test this with diffrent scenarios.
If that will be the case then we might have to do n no of validations inside the compute.
We also don't want to insert any other node in between the MQ failure terminal and subflow.
But as Esa told that the
| Quote: |
| It's the MQOutput node that will serialize the message using DFDL |
So i think it leaves us only with carrying out some validations inside the compute onnly before mapping.
Thanks for the replies.  |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Oct 31, 2013 3:57 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Abhinay185127 wrote: |
But as Esa told that the
| Quote: |
| It's the MQOutput node that will serialize the message using DFDL |
|
That is true if you haven't configured the compute node to validate the message, as Simbu pointed out. Take a look at the Validation tab in the compute node. With the validation setting you can force the compute node to serialize the message. Then you will get the parsing error in the compute node instead of MQOutput. |
|
| Back to top |
|
|
| Abhinay185127 |
| Posted: Thu Oct 31, 2013 4:00 am Post subject: |
|
|
Acolyte
Joined: 20 May 2013
Posts: 58
|
| But Inn the validation tab of compute i have already given Content and Value but still the same thing persists. |
|
| Back to top |
|
|
| gs |
| Posted: Thu Oct 31, 2013 4:54 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
| Abhinay185127 wrote: |
| But Inn the validation tab of compute i have already given Content and Value but still the same thing persists. |
You need to set Parse timing to Immediate for the full validation to take place in the beginning of the flow.
About the MQ Output Failure terminal, I'm assuming you have something connected there causing the exception to get there? Either leave it unconnected or throw the exception again to redirect it upstream in the message flow. |
|
| Back to top |
|
|
| Abhinay185127 |
| Posted: Thu Oct 31, 2013 5:30 am Post subject: |
|
|
Acolyte
Joined: 20 May 2013
Posts: 58
|
Hi gs,
The parse timing is set to immediate only.
As i have already mentioned the failure terminal of MQ Output is connected to a subflow that tries to put the same thing in the queue if the queue is down.
If the failure terminal is not connected then it is working fine obviously.
I don't want to connect any other thing between the MQ failure terminal and retry subflow.
So it seems doing validation in the compute is what i am left with. |
|
| Back to top |
|
|
| gs |
| Posted: Thu Oct 31, 2013 5:48 am Post subject: |
|
|
Master
Joined: 31 May 2007
Posts: 254
Location: Sweden
|
| Abhinay185127 wrote: |
The parse timing is set to immediate only.
|
The field with the alphanumerical field, how is it defined in the schema/message format?
| Abhinay185127 wrote: |
As i have already mentioned the failure terminal of MQ Output is connected to a subflow that tries to put the same thing in the queue if the queue is down.
If the failure terminal is not connected then it is working fine obviously.
I don't want to connect any other thing between the MQ failure terminal and retry subflow.
So it seems doing validation in the compute is what i am left with. |
Sorry, I managed to miss that part of your post. Yes, you need to do validation either in the MQInput node if the message format is strict enough (see question above) or in your Compute node. |
|
| Back to top |
|
|
| Abhinay185127 |
| Posted: Thu Oct 31, 2013 5:54 am Post subject: |
|
|
Acolyte
Joined: 20 May 2013
Posts: 58
|
Actually the source datatype is string whereas the destination datatype is unsignedLong.
So MQ Input just checks the input part so its fine with alphanumeric.
Problem occurs when it maps with the destination part which is expecting unsignedLong. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Oct 31, 2013 6:38 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| Abhinay185127 wrote: |
| But Inn the validation tab of compute i have already given Content and Value but still the same thing persists. |
Maybe you need to modify OutputRoot.Properties to make validation work, or something. Sorry, I have no time to test anything now.
But maybe you could test putting a Validate node after the compute node. Configure it to validate the output DFDL. |
|
| Back to top |
|
|
|
|
