| Author |
Message
|
| smeunier |
 Posted: Mon Dec 19, 2005 1:11 pm Post subject: IDOC Parser error |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
I'm converting IDOC message fromats headed to R3LINK interface, to be handled by WBI mySap.com adapter. This in no problem as I have prototyped and validated the process. As I enter test phase to accept IDOC formats from the sender, which work through R3LINK, I encounter the following error:
| Code: |
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 '1695'. The message appears to have been truncated.
|
This is the size of the transaction which is curently being sent to R3LINK. This includes an SAPH header and a IDOC DC and DD structure. The DC and DD structures appear to be of the correct length and obviously must as they are acceptable by SAP. So I'm lost as to why the IDOC structure does not map. The messageSet map was created via the hdrFiddle.pl script from ia0f support pack. The structure maps to:
SAPH=108
DC=524
DD=1063
Ideas?
[/code] |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Dec 19, 2005 2:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You do not specify the version.
You do not specify whether trailing spaces are removed...
Yes the structure is 1063 long with 1000 significant chars. However if the segment needs less than 1000 chars the rest is usually set to space.
Now if this gets stripped because of trailing spaces you might get a message like what you did.
Enjoy  |
|
| Back to top |
|
|
| smeunier |
| Posted: Mon Dec 19, 2005 5:16 pm Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
By version I expect you meant, what version of the message broker? If you this is version 5 with CSD04
The message coming in is padded with spaces, so there is only about 100 off the 1000 bytes filled in, the rest are spaces. Are trailing spaces stripped? Not by me. The Message set uses spaces as the default padding. How would I control the stripping of spaces? Is there a setting as part of the input node? this is where the message is failing. I could verify that, by sending in one full with bogus data. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Dec 20, 2005 2:00 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I can answer a couple of your questions:
| Quote: |
| The Message set uses spaces as the default padding |
This is probably not relevant - it looks as if it is the entire message which is being truncated. The 'padding' settings in a message set apply to individual fields.
| Quote: |
| Are trailing spaces stripped? Not by me. |
Nor by the message broker. The MQInput node has no such behaviour.
So...what length is your input message. I'm not familiar with SAP messages, but it obviously needs to be at least 1695 bytes long. Have you checked this? |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Dec 20, 2005 5:19 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| The messages coming in are of the correct length, which is why this is even more confusing. I have removed the spaces and added characters. Same message. If I increase the message size to greater than the range of the expected structure in the MRM, I get the same message, just with a different length specified. I have tried running a user trace to determine what may be causing the problem, but I do not see a possible cause. Any suggestions? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 20, 2005 5:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Do you have an embedded null in the message?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Dec 20, 2005 6:24 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
The data as shown via the rfhutil utility, does not show any hex zeros' representing nulls. Here is the data shown as the blob on the error message:
See the following messages for details of the error.
2005-12-20 09:17:38.114505 10281 ParserException BIP5902W: An error occurred in parser 'Root' whilst parsing the field named 'IDOC' on behalf of node 'IDOC_IN_ZMDP_CLASS01.MD_SAP.TEST'. The data being parsed was '4d442020000000020000000000000008ffffffff0000000000000222000001b520202020202020200000000000000000414d51204d445341504544312020202043836e0920014501000000000000000000000000000000000000000000000000000000002020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020204d44534150454431202020202020202020202020202020202020202020202020202020202020202020202020202020206d716d75737220202020202016010515000000bf785ec850db68c9ffc129b0f401000000000000000000000b20202020202020202020202020202020202020202020202020202020202020200000000b202020202020202020202020202020202020202020202020202020203230303531323230313431373338303920202020000000000000000000000000000000000000000000000000000000010000000000000000ffffffff4544495f44433430202030313720202020202020202020202020202020343643202020322020205a4d44505f434c41535330312020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020205a4d44505f434c415353202020202020202020202020202020202020202020202020202020202020202020202020202020413030303030303030314c5320204d51535f41534d5f444220202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020534150454431342020204c532020454431453031374d444420202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020205a324d44505f434c415353303030202020202020202020202020202020203031372020202020202020202020202020202030303030303130303030303030324d4444455630313a4d445453544630313a32303034303131333133333634313a35363432343a55504441544550415254303030303034375032303637323030303431313331333336343130303030303230303030304a4a52303030312020202020204d4f4420303120202020202020202020202020203030315a4d5f50524f44554354494f4e5f312020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020200d0a'.
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-12-20 09:17:38.114612 10281 ParserException BIP6118E: The remaining bitstream is too small to |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 20, 2005 6:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Can you compare this with the output from amqsbcg...
Cause I see a lot of '00' pairs in that BLOB data.....
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Dec 20, 2005 8:48 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
| I wrote the data to a queue. Ran AMQSBCG. No sure where that data gets written to, so I used a facility called SNOOP. That identified that the message contained imbedded nulls. From what I can tell, and see, those null characters are only in the SAPH header and not in the body of the message. The error messahe indicates a structure error from the IDOC parser not the SAPH header parser. Ahh, but perhaps that is part of the problem? The broker does not know how to handle the message header!?!? and considers it part of the data. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 20, 2005 9:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
AMQSBCG writes data to standard output...
So, "amqsbcg .. >myoutput.txt"...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Dec 20, 2005 10:31 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
The IDOC parser should stand in with MRM parser: only SMQ, DC and DD header can parse, DD data need an MRM definition. Is this correct in your config?
Tibor |
|
| Back to top |
|
|
| smeunier |
| Posted: Tue Dec 20, 2005 11:21 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
I had redirected the output as you mentioned. There were only what messages that the program had written: such as completed. It consumed the messages off the queue. So whats with that I don't know. However, I think the problem may lie with the SAPH header that is with the message. I had assumed that the broker would consume this, leaving just the IDOC message itself.
Example: SAPH??????l????3MQSTR ????
So I come to this question. Apparently there is no parser for this header withing the broker. So I'm left with best how to handle this situation.
1) Have external interface remove the SAPH record, which was not part of the plan or add it to the messageSet which I'm not sure if that just becomes another message and type. I think so. I hate to do this, because this means adding this to numerous messages. how best can I strip this part of the message out? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 20, 2005 3:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You have to define the SAPH header as what it is a HEADER.
It is not part of the message payload and as such is not to be parsed by the IDOC handler.
On top of that the SAP header deals with binary information in part for its numerical information as the IDOC is supposed to be only text.
Your parser will kill you if you did not strip the SAPH header (R3-Link)as header from the message.
Enjoy |
|
| Back to top |
|
|
| smeunier |
| Posted: Wed Dec 21, 2005 7:56 pm Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
To resolve the issue. I now receive the message as a BLOB. In a compute node I strip off the first 108 bytes(SAPH) and then send the message to a RCD node and convert to IDOC parser usage. This worked fine.
Thanks all! |
|
| Back to top |
|
|
|
|
