May RWB report the wrong or misleading message about RFC adapter?

[Former Member]

Dear Gurus,

We're working on a simple XI demo of an integration scenario of FILE/JDBC (Async) -> XI -> RFC. The function module BAPI_SALESORDER_CREATEFROMDAT2 is chosen on IDES.

However, we ecountered a weird situation that the RWB reports successfully devliered as

2005-11-19 02:34:53 Success The message was successfully received by the messaging system. Profile: XI URL: http://v61:50000/MessagingSystem/receive/AFW/XI

2005-11-19 02:34:53 Success Using connection AFW. Trying to put the message into the receive queue.

2005-11-19 02:34:53 Success The message was successfully retrieved from the receive queue.

2005-11-19 02:34:53 Success The message status set to DLNG.

2005-11-19 02:34:53 Success Delivering to channel: IDES_RFC_Receiver

2005-11-19 02:34:53 Success RFC adapter received an asynchronous message. Attempting to send tRFC for BAPI_SALESORDER_CREATEFROMDAT2 with TID XI0bl9O5XY4Tg62007wIGhZm

2005-11-19 02:34:54 Success The message status set to DLVD.

2005-11-19 02:34:54 Success The message was successfully delivered to the application using connection AFW.

Also, SXMB_MONI doesn't reprot any error. But we can't find any relevant SalesOrder documents via VA03. Any solution, specific way of troubleshooting, or any other inputs are welcome. Many thanks!

Regards,

Matthew

[Former Member · Accepted solution]

looks like transaction commit is required for this BAPI...

Refer this thread for more info..

If you are on SP14 then commit control is possible from adapter itself.

Commit Control for Individual BAPI Calls

If you want to use this communication channel to call BAPIs as remote-enabled function modules that change data in the database, set the indicator.

If executed successfully, the transaction is written to the database by calling the function module BAPI_TRANSACTION_COMMIT explicitly. If an error occurs, the transaction is rolled back by BAPI_TRANSACTION_ROLLBACK.

The result is determined by the value of the field TYPE in parameter RETURN. If successful, the tables are empty and the values “”, “S”, “I”, and “W” are displayed. All other values are regarded as errors.

To change this setting, set the indicator BAPI Advanced Mode.

In the Successful RETURN-TYPE Values table, enter the values that should lead to a successful execution.

http://help.sap.com/saphelp_nw04/helpdata/en/c8/e80440a832e369e10000000a155106/content.htm

Otherwise you need to create a wrapper to commit the transaction.

Anand

Message was edited by: Anand Torgal

[Former Member · Accepted solution]

Anad,

Many thanks. You reply does work, as we tried to program a BAPI wrapper "ZAPI_SALESORDER_CREATEFROMDAT2" calling both BAPI_SALESORDER_CREATEFROMORDER2 and BAPI_TRANSACTION_COMMIT. However, we ecountered another weird problem, as follows:

On SE37, ZAPI_SALESORDER_CREATEFROMDAT2 is successfully tested and generates the Sales document with the following input.

ORDER_HEADER_IN

DOC_TYPE OR

SALES_ORG 1000

DISTR_CHAN 10

DIVISION 00

PURCH_NO_C XXXX-10000

ORDER_ITEM_IN

ITEM

ITEM_NUMBER 10

MATERIAL 100-100

TARGET_QTY 1,000

ORDER_PARTNERS

ITEM

PARTN_ROLE AG (Automatically changed to SP)

PARTN_NUMB 99999

ORDER_SCHEDULES_IN

ITEM

ITM_NUMBER 10

REQ_QTY 1

ORDER_CONDITIONS_IN

ITEM

ITEM_NUMBER 10

COND_TYPE PR00

COND_VALUE 100

CURRENCY EUR

However, the same data input from XI got the error return like

<TYPE>E</TYPE>

<ID>V1</ID>

<NUMBER>312</NUMBER>

<MESSAGE>Sales document type OR is not defined</MESSAGE>

<LOG_NO />

<LOG_MSG_NO>000000</LOG_MSG_NO>

<MESSAGE_V1>OR</MESSAGE_V1>

<MESSAGE_V2 />

<MESSAGE_V3 />

<MESSAGE_V4 />

<PARAMETER />

<ROW>0</ROW>

<FIELD />

Here is the RFC XML generated by XI:

<?xml version="1.0" encoding="UTF-8" ?>

<ns0:ZAPI_SALESORDER_CREATEFROMDAT2 xmlns:ns0="urn:sap-com:document:sap:rfc:functions">

<ORDER_HEADER_IN>

<DOC_TYPE>OR</DOC_TYPE>

<SALES_ORG>1000</SALES_ORG>

<DISTR_CHAN>10</DISTR_CHAN>

<DIVISION>00</DIVISION>

<PURCH_NO_C>XXX-20051120-B2005</PURCH_NO_C>

</ORDER_HEADER_IN>

<ORDER_CONDITIONS_IN>

<item>

<ITM_NUMBER>10</ITM_NUMBER>

<COND_TYPE>PR00</COND_TYPE>

<COND_VALUE>100</COND_VALUE>

<CURRENCY>EUR</CURRENCY>

</item>

</ORDER_CONDITIONS_IN>

<ORDER_ITEMS_IN>

<item>

<ITM_NUMBER>10</ITM_NUMBER>

<MATERIAL>100-100</MATERIAL>

<TARGET_QTY>1</TARGET_QTY>

</item>

</ORDER_ITEMS_IN>

<ORDER_PARTNERS>

<item>

<PARTN_ROLE>AG</PARTN_ROLE>

<PARTN_NUMB>1000</PARTN_NUMB>

</item>

</ORDER_PARTNERS>

<ORDER_SCHEDULES_IN>

<item>

<ITM_NUMBER>10</ITM_NUMBER>

<REQ_QTY>1</REQ_QTY>

</item>

</ORDER_SCHEDULES_IN>

</ns0:ZAPI_SALESORDER_CREATEFROMDAT2>

Many thanks for your time and support.

Regards,

Matthew

[Former Member · Accepted solution]

Anad,

We've solved the issue, mentioned in my previous reply, with the SAP Note 206068. Again, many thanks for your great support and time.

Regards,

Matthew

[Former Member · Accepted solution]

Thx.. This was a good posting. (Scenario: Webservice <-> XI <-> 'SAP', synchr. )

In the RFC adapter both sent and received message were present and message status was set to DLVD. However SXMB_MONI shows only a Log version of the message. (last step Technical routing). If such a message was succesfull the log-version will be deleted/replaced in the Pipeline and one can see the Call Adapter.

Finally I noticed that in the Return Table in the returning message there were lines with a type 'A' and 'E'.

I assume with the new found information I can by-pass this problem.

Today I received a msg with types 'E' and 'A' and it was in the Pilepine and it was processed !

Thus there are some doubts if the provided answer is 100% valid.

Sorry...

Message was edited by:

Jack Otten