How to see the APO product view from R3

The product view transaction, /SAPAPO/RRP3, is usefull for users other than planners. For instance, people related to sales may want to have accurate view of the product stocks and requirements. As these users will seldom need to work in APO. Thus it is very unconfortable to have to login in APO just to execute the product view. In this document I present a simple way for users to see the product view without leaving the R3 environment.

First create an RFC enabled function in APO with the following code:

FUNCTION z_show_productview.
*"----------------------------------------------------------------------
*"*"Local interface:
*"  IMPORTING
*"     VALUE(P_MATNR) TYPE  /SAPAPO/MATNR
*"     VALUE(P_PLANT) TYPE  WERKS_D
*"  EXCEPTIONS
*"      PLANT_NOT_FOUND
*"      MATERIAL_NOT_FOUND
*"----------------------------------------------------------------------

  DATA: l_matid TYPE /sapapo/matid,
        l_locid TYPE /sapapo/locid,
        l_fcode TYPE syucomm,
        l_loc   TYPE /sapapo/locno.

  l_loc = p_plant.

  CALL FUNCTION '/SAPAPO/DM_LOCNO_GET_LOCID'
       EXPORTING
            iv_locno           = l_loc
       IMPORTING
            ev_locid           = l_locid
       EXCEPTIONS
            location_not_found = 1
            OTHERS             = 2.
  IF sy-subrc <> 0.
    RAISE plant_not_found.
  ENDIF.

  CALL FUNCTION '/SAPAPO/DM_MATERIAL_GET_MATID'
       EXPORTING
            iv_matnr        = p_matnr
       IMPORTING
            ev_matid        = l_matid
       EXCEPTIONS
            matid_not_found = 1
            OTHERS          = 2.

  IF sy-subrc <> 0.
    RAISE material_not_found.
  ENDIF.

  CALL FUNCTION '/SAPAPO/RRP_IOLIST_SHOW'
       EXPORTING
            iv_simid = '000'
            iv_matid = l_matid
            iv_locid = l_locid.

ENDFUNCTION.

Then create the following report in R3 that calls the remote function. You need to have a remote connection between R3 and APO (for example the CIF connection).

REPORT zshowproductview.

PARAMETERS: p_matnr TYPE matnr,
            p_werks TYPE werks_d.

START-OF-SELECTION.

  CALL FUNCTION 'Z_SHOW_PRODUCTVIEW'
         DESTINATION 'YOUR_APO_DESTINATION'
         EXPORTING
              p_matnr = p_matnr
              p_plant = p_werks
         EXCEPTIONS
              communication_failure = 1
              system_failure        = 2
              plant_not_found       = 3
              material_not_found    = 4.

    IF sy-subrc = 1 OR sy-subrc = 2.
      "RFC communication error &1 &2 &3 &4
      MESSAGE ID 'TN' TYPE 'E' NUMBER '059'.
    ELSEIF sy-subrc = 1 OR sy-subrc = 2.
      "The material specified is not available in plant &
      MESSAGE ID 'LD' TYPE 'E' NUMBER '171' WITH p_werks.
    ENDIF.

  ENDIF.

Now when you execute in R3 the report, the executing will go to APO and product view screen will be shown. You might want to set setup some authorization schemes to avoid giving to much permissions in APO to the R3 users.

You may also want to call "LEAVE TO TRANSACTION sy-tcode" after the remote function in order to close the APO session.

Using a generic RFC destination

When developing APO programs that make RFC calls to the R3 system I used to need some logic to determine the correct RFC destination, in order for the code to work correctly in the development, quality testing and productive systems.

But a cleaner way to do it is to create a generic destination, for example RFCR3, and configure in each APO machine the RFC destination to link to the corresponding R3 (using SM59). Then I just use this destination in the function call and it works in all servers.

The APO market for next year

There is a discussion at sapfans about how the APO market will be next year. Everybody seems to agree that BW is hot and APO is kind of slow.

It makes sense. Optimization is the most complex and most rewarding step. But if people don't understand well what's happening in the supply chain, it will be quite hard for them to do optimization. So they first need to have good reporting.

From my experience in research, I remember that before any optimization we needed to evaluate very well the model, and before modelling we needed to do good exploratory data analysis. We can't just go directly to the cake. But optimization is the best cake around. 8-)

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.