| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| IDOC Parser (error handling issues) |
« View previous topic :: View next topic » |
| Author |
Message
|
| Ramphart |
 Posted: Tue Jun 14, 2005 1:42 pm Post subject: IDOC Parser (error handling issues) |
 |
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
Hi,
- WMQI 2.1 CSD 07 on Windows 2000.
- I'm trying to handle parsing, etc errors in the same way (via a subflow) no matter which parser is used on the main flows input node (MRM, IDOC, etc) but IDOC parser exceptions give unexpected results.
1. I'm parsing an IDOC using the IDOC domain and CWF etc as per support pack ia0f (WebSphere MQ Integrator - IDoc parser for SAP)
2. When the input data is correct the document parse and everything is ok, as expected.
3. The issue comes in when I submit an erroneous IDOC. I can't catch the exception when using the IDOC domain since my error routine (that’s wired to the catch terminal of the input node) falls over as well.
4. The problem seems to be that when an exception is raised using IDOC as the Message Domain (on the input node), the output produced when rolling back, i.e. the original message (IDOC), cannot be RCD'd as a BLOB. Really odd.
5. I’ve done a simple flow to validate my suspicion:
| Code: |
[out terminal]
InputNode (Msg Domain=IDOC, MsgSet=... MsgFormat=CWF, Validation=Content and Value, Exception ,Deferred) => Trace {Root}
[catch terminal]
Input Node => RCD (Message Domain=BLOB, Reset Msg Domain)
An invalid message fails and rolls back to the catch terminal then fails again on the RCD (to BLOB) and the exceptions end up in the Windows Event Log. |
6. I can catch the error by ${ExceptionList} via a Trace node on the InputNode catch terminal instead of a RCD (BLOB). Here's an example of an exception:
| Code: |
(0x1000000)RecoverableException = (
(0x3000000)File = 'F:\build\S210_BP\src\DataFlowEngine\ImbTraceNode.cpp'
(0x3000000)Line = 329
(0x3000000)Function = 'ImbTraceNode::evaluate'
(0x3000000)Type = 'ComIbmTraceNode'
(0x3000000)Name = '38ae7a77-0401-0000-0080-fdb80a98d8e7'
(0x3000000)Label = 'IDOC.Blob.Trace1'
(0x3000000)Text = 'Caught exception and rethrowing'
(0x3000000)Catalog = 'WMQIv210'
(0x3000000)Severity = 3
(0x3000000)Number = 2230
(0x1000000)ParserException = (
(0x3000000)File = 'F:\build\S210_BP\src\MTI\MTIforBroker\MtiImbParser2\MtiImbSyntaxElement.cpp'
(0x3000000)Line = 292
(0x3000000)Function = 'CpContext::setToParse'
(0x3000000)Type = ''
(0x3000000)Name = ''
(0x3000000)Label = ''
(0x3000000)Text = 'ImbRecoverableException caught from worker->initializeParse/setFIHandler.'
(0x3000000)Catalog = 'WMQIv210'
(0x3000000)Severity = 3
(0x3000000)Number = 5285
(0x1000000)Insert = (
(0x3000000)Type = 5
(0x3000000)Text = 'ramo'
)
(0x1000000)Insert = (
(0x3000000)Type = 2
(0x3000000)Text = '1'
)
(0x1000000)Insert = (
(0x3000000)Type = 5
(0x3000000)Text = 'CWF'
)
(0x1000000)Insert = (
(0x3000000)Type = 5
(0x3000000)Text = 'E3WVINH001 '
)
(0x1000000)ParserException = (
(0x3000000)File = 'F:\build\S210_BP\src\cpi\pwf\cwf\cwfworker.cpp'
(0x3000000)Line = 410
(0x3000000)Function = 'CWFWorker::initializeParse'
(0x3000000)Type = ''
(0x3000000)Name = ''
(0x3000000)Label = ''
(0x3000000)Text = 'Message Id not in CWF File'
(0x3000000)Catalog = 'WMQIv210'
(0x3000000)Severity = 3
(0x3000000)Number = 5180
(0x1000000)Insert = (
(0x3000000)Type = 2
(0x3000000)Text = '0'
)
(0x1000000)Insert = (
(0x3000000)Type = 5
(0x3000000)Text = 'CWFWorker::initializeParse'
)
(0x1000000)Insert = (
(0x3000000)Type = 5
(0x3000000)Text = 'E53RSK40DC001'
) |
7. Has anyone experienced this with the IDOC parser. Is it a bug?
_________________
Applications Architect |
|
| Back to top |
|
 |
| Tibor |
| Posted: Wed Jun 15, 2005 2:19 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
Hi,
Can you send a detailed trace? Sometimes the exception handling drops an error by stealth... 
Otherwise, I personally prefer using a BLOB input node then an RCD node to switch the needed domain.
Tibor |
|
| Back to top |
|
|
| Ramphart |
| Posted: Mon Jun 20, 2005 3:17 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| Tibor wrote: |
Hi,
Otherwise, I personally prefer using a BLOB input node then an RCD node to switch the needed domain.
Tibor |
I only need to BLOB the message if there's an exception. Also, if I BLOB the message on InputNode then use the RCD to switch to the needed domain i'll probably lose out on the Validation associated with the InputNode.
Anyway, here's my message flow and trace files:
InputNode [out terminal] (Msg Domain=IDOC, MsgSet=... MsgFormat=CWF, Validation=Content and Value, Exception ,Deferred) => Trace {Root}
Input Node [catch terminal] => RCD (Message Domain=BLOB, Reset Msg Domain
Trace with a successful message
Timestamps are formatted in local time, 120 minutes past GMT.
2005-06-14 19:06:54.514999 3004 UserTrace BIP4060I: Data '
' from trace node 'IDOC.Blob.Trace4'.
The trace node 'IDOC.Blob.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-14 19:14:18.077999 3256 UserTrace BIP4060I: Data '
' from trace node 'IDOC.Blob.Trace4'.
The trace node 'IDOC.Blob.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-15 09:03:18.733999 2128 UserTrace BIP4060I: Data '' from trace node 'A.Trace4'.
The trace node 'A.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-15 09:03:19.733999 2128 UserTrace BIP4060I: Data '' from trace node 'A.Trace4'.
The trace node 'A.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-15 09:03:20.733999 2128 UserTrace BIP4060I: Data '' from trace node 'A.Trace4'.
The trace node 'A.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-20 13:02:35.467998 3560 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'ramo.AA.TEMP'.
2005-06-20 13:02:35.467998 3560 UserTrace BIP6060I: Parser type 'Properties' created on behalf of node 'ramo.AA.TEMP' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2005-06-20 13:02:35.467998 3560 UserTrace BIP6061I: Parser type 'MQMD' created on behalf of node 'ramo.AA.TEMP' to handle portion of incoming message of length '364' bytes beginning at offset '0'.
Parser type selected based on value 'MQHMD' from previous parser.
2005-06-20 13:02:35.467998 3560 UserTrace BIP6061I: Parser type 'IDOC' created on behalf of node 'ramo.AA.TEMP' to handle portion of incoming message of length '12217' bytes beginning at offset '364'.
Parser type selected based on value 'IDOC' from previous parser.
2005-06-20 13:02:35.467998 3560 UserTrace BIP2538I: Node 'ramo.TraceFile': Evaluating expression 'Root' at (2, 3).
2005-06-20 13:02:35.484001 3560 UserTrace BIP4067I: Message propagated to output terminal for trace node 'ramo.TraceFile'.
The trace node 'ramo.TraceFile' has received a message and is propagating it to any nodes connected to its output terminal.
No user action required.
2005-06-20 13:02:35.625000 3696 UserTrace BIP7082I: Node '': Publishing to destination CLVX36.LIVE.QMGR:SYSTEM.BROKER.ADMIN.REPLY:4366674d677253756233 for user wmqi.
A publication destination is being added to the list of destinations to CLVX36.LIVE.QMGR:SYSTEM.BROKER.ADMIN.REPLY:4366674d677253756233 for user wmqi.
No user action required.
Threads encountered in this trace:
2128 3004 3256 3560 3696
Trace with an unsuccessful message
Timestamps are formatted in local time, 120 minutes past GMT.
2005-06-14 19:06:54.514999 3004 UserTrace BIP4060I: Data '
' from trace node 'IDOC.Blob.Trace4'.
The trace node 'IDOC.Blob.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-14 19:14:18.077999 3256 UserTrace BIP4060I: Data '
' from trace node 'IDOC.Blob.Trace4'.
The trace node 'IDOC.Blob.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-15 09:03:18.733999 2128 UserTrace BIP4060I: Data '' from trace node 'A.Trace4'.
The trace node 'A.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-15 09:03:19.733999 2128 UserTrace BIP4060I: Data '' from trace node 'A.Trace4'.
The trace node 'A.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-15 09:03:20.733999 2128 UserTrace BIP4060I: Data '' from trace node 'A.Trace4'.
The trace node 'A.Trace4' has output the specified trace data.
This is an information message provided by the message flow designer. The user response will be determined by the local environment.
2005-06-20 13:02:35.467998 3560 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'ramo.AA.TEMP'.
2005-06-20 13:02:35.467998 3560 UserTrace BIP6060I: Parser type 'Properties' created on behalf of node 'ramo.AA.TEMP' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2005-06-20 13:02:35.467998 3560 UserTrace BIP6061I: Parser type 'MQMD' created on behalf of node 'ramo.AA.TEMP' to handle portion of incoming message of length '364' bytes beginning at offset '0'.
Parser type selected based on value 'MQHMD' from previous parser.
2005-06-20 13:02:35.467998 3560 UserTrace BIP6061I: Parser type 'IDOC' created on behalf of node 'ramo.AA.TEMP' to handle portion of incoming message of length '12217' bytes beginning at offset '364'.
Parser type selected based on value 'IDOC' from previous parser.
2005-06-20 13:02:35.467998 3560 UserTrace BIP2538I: Node 'ramo.TraceFile': Evaluating expression 'Root' at (2, 3).
2005-06-20 13:02:35.484001 3560 UserTrace BIP4067I: Message propagated to output terminal for trace node 'ramo.TraceFile'.
The trace node 'ramo.TraceFile' has received a message and is propagating it to any nodes connected to its output terminal.
No user action required.
2005-06-20 13:02:35.625000 3696 UserTrace BIP7082I: Node '': Publishing to destination CLVX36.LIVE.QMGR:SYSTEM.BROKER.ADMIN.REPLY:4366674d677253756233 for user wmqi.
A publication destination is being added to the list of destinations to CLVX36.LIVE.QMGR:SYSTEM.BROKER.ADMIN.REPLY:4366674d677253756233 for user wmqi.
No user action required.
2005-06-20 13:05:52.484001 3560 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'ramo.AA.TEMP'.
2005-06-20 13:05:52.484001 3560 UserTrace BIP6060I: Parser type 'Properties' created on behalf of node 'ramo.AA.TEMP' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2005-06-20 13:05:52.484001 3560 UserTrace BIP6061I: Parser type 'MQMD' created on behalf of node 'ramo.AA.TEMP' to handle portion of incoming message of length '364' bytes beginning at offset '0'.
Parser type selected based on value 'MQHMD' from previous parser.
2005-06-20 13:05:52.484001 3560 UserTrace BIP2231E: Error detected whilst processing a message 'ramo.AA.TEMP'.
The message broker detected an error whilst processing a message in node 'ramo.AA.TEMP'. The message has been augmented with an exception list and has been propagated
to the node's failure terminal for further processing.
See the following messages for details of the error.
2005-06-20 13:05:52.484001 3560 RecoverableException BIP2230E: Error detected whilst processing a message in node 'ramo.TraceFile'.
The message broker detected an error whilst processing a message in node 'ramo.TraceFile'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2005-06-20 13:05:52.484001 3560 ParserException BIP5902W: An error occurred in parser 'Root' whilst parsing the field named 'IDOC' on behalf of node 'ramo.AA.TEMP'.
The data being parsed was '4d442020020000000000000008000000ffffffff0000000022020000b501000020202020202020200000000000000000414d5120434c565833362e4c4956452e6f78b64220002e010000000000000000000000000000000
0000000000000000000000000202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020434c565833362e4c4956452e514d47522020202020202020202020202020202020202020202020202
020202020202020776d7169202020202020202016010515000000f17a11f1236d425f0519427feb03000000000000000000000b20202020202020202020202020202020202020'.
This message gives the name of the field in the parser that was being parsed at the time the error occurred.
You should check for other messages issued with this one for the full context of the error.
2005-06-20 13:05:52.500000 3560 ParserException BIP6118E: The remaining bitstream is too small to contain the indicated structure.
The bitstream, as presented to the 'IDOC' parser, is too small to contain the 'IDOC' structure. The length of this structure as given in the structure header is '12216'.
The message appears to have been truncated.
Check with the support group responsible for the parser in question.
2005-06-20 13:05:52.500000 3560 Error BIP2232E: Error detected whilst handling a previous error in node 'ramo.rcdBLOB'.
The message broker has detected an error in node 'ramo.rcdBLOB' whilst handling a previous error.
See the following messages for details of the exception list associated with the original error. Thereafter messages will be associated with the new error.
2005-06-20 13:05:52.500000 3560 RecoverableException BIP2230E: Error detected whilst processing a message in node 'ramo.TraceFile'.
The message broker detected an error whilst processing a message in node 'ramo.TraceFile'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2005-06-20 13:05:52.500000 3560 ParserException BIP5902W: An error occurred in parser 'Root' whilst parsing the field named 'IDOC' on behalf of node 'ramo.AA.TEMP'. The data being parsed was
'4d442020020000000000000008000000ffffffff0000000022020000b501000020202020202020200000000000000000414d5120434c565833362e4c4956452e6f78b64220002e010000000000000000000000000000000000000000000000000000000020
2020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020434c565833362e4c4956452e514d47522020202020202020202020202020202020202020202020202020202020202020776d716920202
020202020202020202020202020202020202020202020'.
This message gives the name of the field in the parser that was being parsed at the time the error occurred.
You should check for other messages issued with this one for the full context of the error.
2005-06-20 13:05:52.500000 3560 ParserException BIP6118E: The remaining bitstream is too small to contain the indicated structure.
The bitstream, as presented to the 'IDOC' parser, is too small to contain the 'IDOC' structure. The length of this structure as given in the structure header is '12216'.
The message appears to have been truncated.
Check with the support group responsible for the parser in question.
2005-06-20 13:05:52.500000 3560 Error BIP2628E: Exception condition detected on input node 'ramo.AA.TEMP'.
The input node 'ramo.AA.TEMP' detected an error whilst processing a message. The message flow has been rolled-back and, if the message was being processed in a unit of work,
it will remain on the input queue to be processed again. Following messages will indicate the cause of this exception.
Check the error messages which follow to determine why the exception was generated, and take action as described by those messages.
2005-06-20 13:05:52.500000 3560 RecoverableException BIP2230E: Error detected whilst processing a message in node 'ramo.TraceFile'.
The message broker detected an error whilst processing a message in node 'ramo.TraceFile'. An exception has been thrown to cut short the processing of the message.
See the following messages for details of the error.
2005-06-20 13:05:52.500000 3560 ParserException BIP5902W: An error occurred in parser 'Root' whilst parsing the field named 'IDOC' on behalf of node 'ramo.AA.TEMP'.
The data being parsed was '4d442020020000000000000008000000ffffffff0000000022020000b501000020202020202020200000000000000000414d5120434c565833362e4c4956452e6f78b64220002e0100000000000000000000000000000000
000000000000000000000000202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020434c565833362e4c4956452e514d47522020202020202020202020202020202020202020202020202020
202020202020776d7169202020202020202016010515000000f17a11f1236d425f0519427feb03000000000000000000000b20202020202020202020202020202020202020202020202020202020202020200b000000636b735c696830335f5246485574696c
5c7266687574696c2e6578653230303530363230313130353532343820202020000303'.
This message gives the name of the field in the parser that was being parsed at the time the error occurred.
You should check for other messages issued with this one for the full context of the error.
2005-06-20 13:05:52.514999 3560 ParserException BIP6118E: The remaining bitstream is too small to contain the indicated structure.
The bitstream, as presented to the 'IDOC' parser, is too small to contain the 'IDOC' structure. The length of this structure as given in the structure header is '12216'.
The message appears to have been truncated.
Check with the support group responsible for the parser in question.
2005-06-20 13:05:53.514999 3560 UserTrace BIP2638I: The MQ output node 'ramo.AA.TEMP' attempted to write a message to the specified queue 'HUBCLV.DLQ' connected to queue manager 'CLVX36.LIVE.QMGR'.
The MQCC was 0 and the MQRC was 0.
2005-06-20 13:05:53.514999 3560 UserTrace BIP2615I: The MQSeries input node 'ramo.AA.TEMP' has backed out the message to the backout requeue or the dead letter queue.
Message backout processing has been invoked, and the message has either been backed out by being written to the backout requeue or dead letter queue, as determined by
the MQSeries queue manager and queue configuration.
No user action required.
Threads encountered in this trace:
2128 3004 3256 3560 3696
Notes
-The message propagates down the InputNode Catch Terminal but fails when i'm trying to BLOB it on RCD. This is just insane I'd think.
-Anyway, I need to BLOB it because eventually ill have a SUBFLOW error routine wired to the catch terminal which will BLOB the errenuous message and log it to a database with the {ExceptionList}.
-The RCD to BLOB [when a message fails] works great with all the other Domains.
-Please assist me guys.
_________________
Applications Architect |
|
| Back to top |
|
|
| Tibor |
| Posted: Mon Jun 20, 2005 7:05 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Ramphart wrote: |
| I only need to BLOB the message if there's an exception. Also, if I BLOB the message on InputNode then use the RCD to switch to the needed domain i'll probably lose out on the Validation associated with the InputNode. |
You don't lose the validation when using BLOB input. The documentation writes about it:
| Quote: |
You can use validation options to validate the following messages:
* Input messages that are received by the MQInput node
* Output messages that are created by the Compute node
* Output messages that are created by the Mapping node
|
However, I don't understand why WMQI writes *this* trace messages, because the hex dump is not an IDOC header, but an MQMD header:
| Code: |
0000 4D 44 20 20 02 00 00 00-00 00 00 00 08 00 00 00 MD ............
0010 FF FF FF FF 00 00 00 00-22 02 00 00 B5 01 00 00 ........".......
0020 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 ........
0030 41 4D 51 20 43 4C 56 58-33 36 2E 4C 49 56 45 2E AMQ CLVX36.LIVE.
0040 6F 78 B6 42 20 00 2E 01-00 00 00 00 00 00 00 00 ox.B ...........
0050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 20 20 20 20-20 20 20 20 20 20 20 20 ....
0070 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
0080 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
0090 20 20 20 20 43 4C 56 58-33 36 2E 4C 49 56 45 2E CLVX36.LIVE.
00A0 51 4D 47 52 20 20 20 20-20 20 20 20 20 20 20 20 QMGR
00B0 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
00C0 20 20 20 20 77 6D 71 69-20 20 20 20 20 20 20 20 wmqi
00D0 16 01 05 15 00 00 00 F1-7A 11 F1 23 6D 42 5F 05 ........z..#mB_.
00E0 19 42 7F EB 03 00 00 00-00 00 00 00 00 00 00 0B .B..............
00F0 20 20 20 20 20 20 20 20-20 20 20 20 20 20 20 20
0100 20 20 20 |
How does your WMQI and SAP build the communication? (There is no SAPH, that's why this shouldn't be an R3Link traffic.)
Tibor |
|
| Back to top |
|
|
| Ramphart |
| Posted: Mon Jun 20, 2005 1:20 pm Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| Tibor wrote: |
You don't lose the validation when using BLOB input. The documentation writes about it:You can use validation options to validate the following messages:
* Input messages that are received by the MQInput node
* Output messages that are created by the Compute node
* Output messages that are created by the Mapping node
|
- I understand that the validation is not lost when using BLOB on InputNode, but then the validation is against BLOB and not against the MRM definition. Also, if I BLOB it on InputNode then RCD it to MRM I will then lose the validation that I would have had if I had MRM on the InputNode [with validation switch on].
| Tibor wrote: |
However, I don't understand why WMQI writes *this* trace messages, because the hex dump is not an IDOC header, but an MQMD header:
[code]0000 4D 44 20 20 02 00 00 00-00 00 00 00 08 00 00 00 MD ............
0010 FF FF FF FF 00 00 00 00-22 02 00 00 B5 01 00 00 ........".......
0020 20 20 20 20 20 20 20 20-00 00 00 00 00 00 00 00 ........
0030 41 4D 51 20 43 4C 56 58-33 36 2E 4C 49 56 45 2E AMQ CLVX36.LIVE. |
The SAPH header will be present when the message comes directly from SAP. You can do without it though [if you want] when you put the message on the queue as MQSTR [with RHFUtil say]. It's like having an RFH2 or no RFH2. As long as you indicate to the parser what follows all is fine.
My problem is really that my generic error handler [a subflow] logs the errenuous message [original data that was put onto the Queue] to a database table in one column and the exceptionlist to another column. Since the subflow have no idea what came onto a queue in the main flow [which domain etc.] I simply BLOB it and log it. This operation works fine for ALL the Domains when messages fail but falls over when a message fails using the IDOC parser. Surely this is something to do with the way the IDOC parser raise the error when is rolls back to the InputNode.
This is whats odd about the IDOC parser:
1. When the InputNode is for instance the MRM parser and I put, say a csv message and map this to an IDOC and gets a failure, the message rolls back to the InputNode and the SubFlow error handler works fine.
2. When the InputNode is the IDOC parser and I map this to a csv message and gets a failure the message rolls back to the InputNode and the SubFlow error handler FALLS over when I try to BLOB the input.
What now 
_________________
Applications Architect |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jun 20, 2005 5:27 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Ramphart wrote: |
| but then the validation is against BLOB and not against the MRM definition. |
This is, I think, why Compute nodes have Validation properties.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Tibor |
| Posted: Mon Jun 20, 2005 8:52 pm Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Ramphart wrote: |
| This is whats odd about the IDOC parser... |
Perhaps, it's coming from the working of the IDOC parser, because this is a two-level parser:
- #1 parsing DC and DD header
- #2 parsing DD data through MRM parser - depend on DD.segnam
Tibor |
|
| Back to top |
|
|
| Ramphart |
| Posted: Tue Jun 21, 2005 1:31 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| Tibor wrote: |
| Ramphart wrote: |
| This is whats odd about the IDOC parser... |
Perhaps, it's coming from the working of the IDOC parser, because this is a two-level parser:
- #1 parsing DC and DD header
- #2 parsing DD data through MRM parser - depend on DD.segnam
Tibor |
I think it definitely comes from #1 parsing DC and DD header. Question now is, how do we fix this? Is it a bug?
_________________
Applications Architect |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Jun 21, 2005 6:06 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Quote: |
| Question now is, how do we fix this? Is it a bug? |
Perhaps a bug, IMHO doesn't matter... because in this case you should have to do a workaround. I can repeat my suggestion (very simple)
- MQInput, Domain=BLOB
- TryCatch
- RCD to IDOC
- other...
Tibor |
|
| Back to top |
|
|
| Ramphart |
| Posted: Tue Jun 21, 2005 11:39 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2004
Posts: 150
Location: South Africa, JHB
|
| Tibor wrote: |
Perhaps a bug, IMHO doesn't matter... because in this case you should have to do a workaround. I can repeat my suggestion (very simple)
- MQInput, Domain=BLOB
- TryCatch
- RCD to IDOC
- other...
Tibor |
Since you suggest that I use BLOB on inputNode I won't need the TryCatch.
If I get an exception after RCD to IDOC it will roll back the inputNode (BLOB domain inititally) so my SubFlow error handler will work just fine.
Thx for all your advice.
_________________
Applications Architect |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
