Tuesday, December 23, 2003

Some debug tips for R3 and APO

These are some assorted tips for debugging APO developments. This is the same information I had in my homepage.

How to debug APO processing done in ATP checks

The ATP code is started in R3 but runs in APO. If you place a breakpoint in APO with your user, debugging won't work because in APO the execution is done with the communications service user.

You must first place a breakpoint before the call to the APO ATP function. The function name is BAPI_APOATP_CHECK and the call is in program SAPLATPC. Just search this program for the function and place a breakpoint in the call for your release of APO (or just put a breakpoint in each call). Then, when triggering the ATP in the sales order, the program stops in the BAPI. You can step into the function and you'll be debugging in the APO server.

How to debug CIF integration models

To debug CIF integration models, setup your username in transaction CFC2. Set the debug option to "Debugging on and T/QRFC will only be recorded". Then, when you execute integration models the transfer data will be kept in the queue and available for debugging with SMQ1.

How to debug the CIF integration models without using CFC2

You know the function name in APO and you need to find out where this function is called in R3. You can do it using one of the reports to search the source (RPR_ABAP_SOURCE_SCAN, RSRSCAN1) and place as a restriction the CIF function groups (to get this list search for the function groups with CIF in the description).

Place a breakpoint before in the function call. Then run the integration model and when the program stops, with another session, stop the CIF queues with function TRFC_QOUT_STOP. Then continue the execution. You can now go to the outbound queue (SMQ1) and run the function in debug mode.

Labels: ,

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home