ALEAUD chooses bad success message for IDOC wrapped around BAPI when 2+ msg

[Sandra_Rossi]

I created a custom BAPI...something...CREATE to create data, and we created one IDOC message type via BDBG transaction.

Now we use ALEAUD to return the error or success message.

Unfortunately, it does not return the most appropriate message when the BAPI returns several messages, among which warning and information messages:

- If BAPI creates the object and it returns a warning followed by a success, the IDOC is created with messages reversed (success followed by warning), thus ALEAUD returns the warning (always the last message of idoc), so we miss the id of object created.

- If BAPI doesn't create it, and returns a warning followed by an error, the IDOC is created with messages reversed, the ALEAUD returns the warning (status 51).

The problem is really the reversal algorithm.

I found that it is located in the ZIDOC_INPUT_* function module generated by BDBG: messages of the bapi are transferred to idoc_status with "INSERT idoc_status INDEX 1". Why don't SAP just use "APPEND idoc_status"?

Did you have this problem, and how did you solve it?

Do you know if SAP recommends something about BAPIs returning warning or information messages?

Thx a lot !

[shivhare]

Hi

check go to your acknowladgement IDOC and check its partner profile.

i think when acknowladgement IDOC create something missing in partner profile

Thanks

Amit Shivhare

[Sandra_Rossi]

thx Amit, but it's not the point. I guess my question was not clear.

The ALEAUD idoc is successfully generated but the message it contains is not the one I expect.

In fact, the problem is not really the ALEAUD idoc, but the original IDOC it refers to (assume it's message type ZMYMSGTYPE). This idoc contains several messages (in table EDIDS) which are not ordered in the same sequence than the messages output by the BAPI that is called by ZMYMSGTYPE.

[Sandra_Rossi]

SOLUTION:

I cannot simply correct function module generated via BDBG to replace "INSERT idoc_status INDEX 1" with "APPEND idoc_status", because, as SAP says, "this function module is generated, never change it manually, please!" (loss of changes in case of regeneration).

Solution is explained in note 513785 "UTI: Extending the source code generated by BDBG/BDFG" explains how to modify the generated function module, so that changes are kept when function module is regenerated. An example is provided by Note 595831 - IDoc status from export modules generated with BDBG.

What I did:

INSERT IDOC_STATUS INDEX 1.

was replaced by:

* context-of-insertion <-- SAP keyword, do not change (cf note 513785)
  INSERT IDOC_STATUS INDEX 1.
* begin-of-insertion <-- SAP keyword, do not change (cf note 513785)
  DELETE IDOC_STATUS INDEX 1.
  APPEND IDOC_STATUS.
* end-of-insertion <-- SAP keyword, do not change (cf note 513785)

Be careful : do NOT enter lines wider than 72 characters, it would dump during regeneration!

As I am not modest, I give 10 points to myself

Other solution for "lazy" persons:

If we are lazy and want in the future to make all function modules be generated directly and automatically with "APPEND idoc_status" (instead of "INSERT idoc_status INDEX 1"), a solution could be to repair the SAP template source LBDBGIBS used by BDBG transaction and replace "INSERT idoc_status INDEX 1" with "APPEND idoc_status". Another solution would be to "reverse the reversed messages", by implementing an implicit enhancement point at the end of BAPI_IDOC_INPUT1 function module, to reverse the sequence of messages in IDOC_STATUS if the called function module is custom (starts with Y or Z) so that to not impact the standard.

Edited by: Sandra Rossi on Oct 16, 2008 5:21 PM

[shivhare]

Good Explanations

Thanks