Author |
Message
|
KIRANP |
Posted: Wed Jun 30, 2004 9:43 am Post subject: Reading message |
|
|
Acolyte
Joined: 23 Jul 2002 Posts: 51
|
I would like to read a message(IDOC) before it is put to a DLQ or BAD message queue. Does anyone has a idea how it is done?This will help the developers to re-send the IDOC if there is a problem.
Thanks
Kiran P |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jun 30, 2004 10:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
What would you like to use to read this IDOC message? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
KIRANP |
Posted: Wed Jun 30, 2004 10:09 am Post subject: hi |
|
|
Acolyte
Joined: 23 Jul 2002 Posts: 51
|
When message(IDOC) is in the INBOUNDQUEUE the MQLink for R/3 inboundserver trys to send it to SAP .If there is something wrong with the IDOC it puts it in BADMESSAGE queue. I want to have some script to be triggered on the BADMESSAGE queue wich will read the IDOC number message type and generate a e-mail notification.So that they can resend the same IDOC or troubleshoot if there is some problem with the IDOC. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jun 30, 2004 10:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
|
Back to top |
|
 |
Michael Dag |
Posted: Wed Jun 30, 2004 10:37 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jun 30, 2004 10:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Or at least understand that, if I personally haven't indicated how to parse an IDOC, it might actually mean that I don't know how to parse an IDOC. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Michael Dag |
Posted: Wed Jun 30, 2004 10:42 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
jefflowrey wrote: |
it might actually mean that I don't know how to parse an IDOC. |
You DON'T??? tsk tsk ... ROFL
(just having a very funny day... ) _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jun 30, 2004 10:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I'm lucky I can spell IDOC, much less SAP.
I'm really trying to understand why this seems so difficult to people, and failing.
Isn't IDOC a tagged format? Aren't IDOC messages simply regular MQSeries messages with IDOC data in them?
So if you know what IDOC messages look like, and you know how to read an MQSeries message, then you know how to solve this problem? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Michael Dag |
Posted: Wed Jun 30, 2004 11:50 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
I took this sample idoc from IA0F: MQSeries Integrator - IDoc parser as you can see no magic... again, you need to know what you are looking for...
I would just put the IDOC itself in an e-mail message and mail it to the developer with the accompanying text: This went wrong
Code: |
EDI_DC40 100000000000004189145B 3014 MATMAS01 MATMAS E MATMASSAPC11 LS C11CLNT100 A000000002LS HURSDEV 20000929121045 20000929121044 E2MARAM002 100000000000004189100000100000002005DINGHY-BUZZ 19981102MJOHNSON 00000000 K FERT101 KGM 000 0.000 0.000 KGM0.000 FTQ 01 0.000 0.000 0.000 0.000 0.000 0.000 0.00.0 0 0 0 0 0 K 0000000000000000 00 0.0 0.0 E2MAKTM001 100000000000004189100000200000103005EBuzz by Topper International EN E2MARMM 100000000000004189100000300000103005KGM1 1 0.000 0.000 0.000 0.000 FTQ0.000 KGM |
_________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Jun 30, 2004 2:46 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Michael, Jeff,
If the IDOC lands on the bad message queue usually it is the format that is at fault and not the content. If the content is at fault the IDOC should make it to SAP but be rejected and visible in SAP.
Now with the format at fault it becomes much more difficult to understand what is wrong. It can be as simple as the sequence of the segments not conforming to the SAP IDOC specification or a lot more complicated to figure out. I don't believe that a simple email with the content will really help the developers.
Here both parties need to get involved. The only way I know that things get finally checked is by sending the IDOC as a file attachment to the developer because there he can check every position for the right information.
Not to forget that the MQ message contains in its payload an additional MQLINK for R3 Header. This header can have the wrong length and that could be reason enough for landing on the bad message queue.
We request the MQLINK log entry in the case of a message on the bad message queue because this gives us already quite a clue as to what might be wrong.
Hope it helps give some direction.
F.J. |
|
Back to top |
|
 |
KIRANP |
Posted: Thu Jul 01, 2004 5:25 am Post subject: Thanks |
|
|
Acolyte
Joined: 23 Jul 2002 Posts: 51
|
Hi fjb_saper,
Your info is really helpful.My issue is a particular IDOC type say MATMAS 99% of time goes to SAP without any problem through MQ,MQLink for R/3.Once in a while lands in BADMESSAGE queue.
But the sending side program which extracts the IDOC and sends is the same.What may be the reason for the format to change? There is no manual intervention.The sending side program is the same all the time.
Thanks
Kiran P.  |
|
Back to top |
|
 |
KIRANP |
Posted: Thu Jul 01, 2004 6:59 am Post subject: Re: Thanks |
|
|
Acolyte
Joined: 23 Jul 2002 Posts: 51
|
[quote="KIRANP"]Hi fjb_saper,
Your info is really helpful.My issue is a particular IDOC type say MATMAS 99% of time goes to SAP without any problem through MQ,MQLink for R/3.Once in a while lands in BADMESSAGE queue.
But the sending side program which extracts the IDOC and sends is the same.What may be the reason for the format to change? There is no manual intervention.The sending side program is the same all the time.
Thanks
Kiran P. [/quote] |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jul 01, 2004 7:11 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Hi Kiran,
No two IDOCS are the same. The IDOC structure has a lot of optional segments. So if your application putting the IDOCS is the same I suspect that for a particular case the IDOC sent does not conform to SAP Standard.
So every once in while, when the sending data hits the case the IDOC does not get build according to SAP standard and lands on the bad message queue.
Talking about optional segments. If you ever need to populate an optional segment in an IDOC, all the segments (optional or not) in its hierarchy (with a hierarchy level lower than itself) MUST be present. Otherwise the IDOC format is not valid....
Like I said: get the MQLink log and decipher what clues may lay therein.
Check the Hierarchical structure of the IDOC against SAP and watch out for differences. If you have an optional level 2 with an optional level3 and you are sending the level 3 segment without sending the level 2 segment you have a malformed IDOC....
Quote: |
The sending program is the same all the time. |
The sending program is wrong all the time. But it hits only 1 % of the cases as those require the additional information to be sent. Now when building the IDOC with this additional info the format of the IDOC does not conform to SAP.
I assumed here that no matter what you do you are never able to process these IDOCS. One way of testing this would be to extract the message from MQ, strip the MQLink header from it, dump it into a file and try and upload the file in SAP using program rseinb00.
This should then give some information in SAP about what is wrong.
Hope this helps some.  |
|
Back to top |
|
 |
JasonE |
Posted: Thu Jul 01, 2004 11:54 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
If you take the message off the bad msg q and resubmit, does it go through or get rejected again? I know sometimes if comms type errors occur, msgs may be put on the bad msg q |
|
Back to top |
|
 |
fschofer |
Posted: Thu Jul 01, 2004 11:45 pm Post subject: |
|
|
 Knight
Joined: 02 Jul 2001 Posts: 524 Location: Mainz, Germany
|
Hi,
you have to distinguish between messages which go to the R3 Link badmessagequeue (defined in your inbound in file)
and messages which go to a backout queue (if used and backout count treshhold is reached)
and messages which go the dead letter queue.
badmessagequeue:
To get back the original messages you to cut of the 80 bytes bad mesage header and change the message format to 'SAPH'
You may analyse the information in the bad mesage header to find out what went wrong.
backout queue:
message stays in the original status
dead letter queue:
remove DLQ header and change message format to 'SAPH'
If your message content is fine and you only had same problems with sap or something else
you can resubmit your message to the R3 Link inbound queue.
Otherwise send it back to the developer or where ever it came from.
Greetings
Frank |
|
Back to top |
|
 |
|