OSS Quick News

Note 682381 has some example code for hacking operations on planned orders using BADI /SAPAPO/CL_EX_CIF_IP. Note 693043 has a new user exit and example implementation for deactivating R3 planned order BOM explosion.

Python and SAP

Python is my by far my favorite computer programming language. This is a subjective matter, everybody has their preferences. I'm not saying it is the best. Only that I like so much that I try to use it whenever I can. Of course I cannot use it inside SAP, it has to be ABAP (at least in version 46C). But for integration with external systems there are some ways to use python.

One way is to use jython (python language implemented in java) with the SAP jCO java connector (connectors link requires SAP customer login). This connector is quite powerful and well documented. And with jython the development is much faster than with java, so, when doing scripts that are to be used only once or twice (loading/downloading data, etc), this is my favorite choice.

The main drawback of this approach is that jython and python are not the same thing. I had several situations were I would like to use numeric or GUI libraries that are only available in python. And interfacing with zope (python main web application framework) would also be a great option if available. For interfacing with python one can use the DCOM library (works only in windows). I find the DCOM framework ok for calling SAP functions (although a lot harder than jython/jCO) but it is not a good option for developing servers to receive calls from SAP.

Other possible options that I've yet to explore include the new SAP .NET connector and the RFC python wrapper done by Piers Harding. This last one is not complete and, as far as I could tell, only includes support for RFC clients. The .NET option, together with Python .NET might be a good solution for python SAP integration.

At last, the new SAP kernel (for v47) also supports SOAP interfacing. It shouldn't be hard to use python with this kind of interface. I haven't had the change to try it though.

The Control Panel

The success or failure of software tools may have reasons totally unrelated to the software quality. This is true for all software and is certainly true for APO. The key point is that users must like the tool. I'm also a user, so it's fair to ask myself what do I like in a software tool. Well, I like powerful tools and I also like good-looking software. These are software characteristics, so as far as APO is concerned there is nothing we can do here. I also like the software to be fast, and this is a combination of software and hardware, so better hardware can make a difference.

There are other hardware choices that can also make a difference for APO users. In my opinion, having a large control panel is a very attractive goodie for a person responsible for operations planning and control. And currently it is very cheap and easy to setup workstations with multiple screens. One just need to add several video boards to the PC and connect each screen to each board (there are also other solutions like special video boards with multiple screen outputs).

Having an APO workstation with, for example, three screens will enable the user to simultaneously look at the planning board, product view and possibly check some R3 data on the third window. Or in other usage scenario he can compare the results of two different planning strategies. The bottom line is that the planning task needs to be done with access to many sources of information, and a good way to do it is to have a large display area.

There is no new technology here. Probably many APO users already work with multiple displays. The main point of this blog is to point out that some simple things like installing multiple display workstations with new APO software roll out may have impact on the user productivity and overall user satisfaction. But this is just a wild guess, I don’t actually know users working with multiple displays (do you know? I would really like to ear about it).

The APO Loader Tool

I saw this reference to the ApoLoader tool in a sapfans post by James Craig. The tool can be downloaded from the service marketplace. It is attached to note 551972.

The ApoLoader is an Excel file with macros that wrap calls to APO BAPIs. I just gave it a quick ride and found it to be quite interesting. It's easy to fetch APO data and it's possible to save data (it's called a loader after all!). But that is something I will reserve for a second ride.

I guess some quick reports could be done with this tool. The Visual Basic macro code can be changed easily. And users are very fond of having data in Excel. Something to check again, one of these days.

Search helps in R3 for APO data

Some quick notes on building search helps in R3 with data from APO system. When developing in APO, sooner or later one will need to build programs that use data from both systems (APO and R3). And for selection screens we end up needing to have search helps for data fields from the remote system.

SAP has an example search exit function named F4IF_SHLP_EXIT_EXAMPLE. To speed development you can copy this function rather than start from scratch. But since the function needs other code from the function group, better to copy all the function group to the customer namespace. Quick instructions: go to SE38 and make a copy of SAPLSDHI to, for example ZSDHI; then select only the function F4IF_SHLP_EXIT_EXAMPLE to copy to this new group (for example use name ZF4IF_SHLP_EXIT_EXAMPLE). Now go to the new function and make a copy for this example (example name ZAPO_ATPCAT_SHLP). In the search help exit a lot can be done. You can make some fields mandatory, you add authorizations, filter data, etc. You can find here documentation on the search help framework.

I will use the exit select control step to get the data from the APO system. Bellow is the code that is needed in the search help exit function (ZAPO_ATPCAT_SHLP). The first function call in the code is to make a remote call to the APO system to get the data (in this example I fetch the ATP categories with descriptions. Then use the F4UT_RESULTS_MAP function to map the data from the zs_atpcat structure (just ATP cat. and description) to the internal search help structures.

  DATA: lt_atpcat TYPE TABLE OF zs_atpcat WITH HEADER LINE.

  IF callcontrol-step = 'SELECT'.

    CALL FUNCTION 'Z_ATPGET_ATPCAT'
         DESTINATION 'RFCAPO'
         EXPORTING
              p_spras  = sy-langu
         TABLES
              p_atpcat = lt_atpcat
         EXCEPTIONS
              communication_failure = 1
              system_failure        = 2.

    CALL FUNCTION 'F4UT_RESULTS_MAP'
         EXPORTING
              source_structure  = 'zs_atpcat'
         TABLES
              shlp_tab          = shlp_tab
              record_tab        = record_tab
              source_tab        = lt_atpcat
         CHANGING
              shlp              = shlp
              callcontrol       = callcontrol
         EXCEPTIONS
              illegal_structure = 1
              OTHERS            = 2.

    IF sy-subrc = 0.
      callcontrol-step = 'DISP'.
    ELSE.
      callcontrol-step = 'EXIT'.
    ENDIF.
    EXIT. "Don't process STEP DISP additionally in this call.
  ENDIF.
  EXIT.

Now just go to SE11 and create a search help with the fields ATP category and description and with ZAPO_CATATP_SHLP being the search help exit.

This development pattern is simple and effective, for example to make reports in R3 with mixed data. APO has good BAPIs with fast access to data from the LiveCache. It’s quite easy to build reports based on those BAPIs. The most annoying thing is that most data structures used in APO BAPIs are not available in R3. So, in order to use these BAPIs one needs to create these dictionary elements, which ends up being a lot of boring work. Wouldn’t it be great if SAP added the APO BAPI structures to R3. And it would make sense, it’s already done for all the R3-APO remote functions that are part of the standard code.

SAP Help Documents in Word

Ever felt that you would like to have the SAP help documents in word document format? I find it more comfortable to read documentation on paper. On the other hand, the formatting of SAP PDF makes documents with an enormous number of pages. I wrote a script to do just that, convert SAP help files to word documents. Then I remove parts I don’t want to print and setup small margins to save some trees. There must be better ways, but this one works and it might be useful for others.

Here is how to do it. First you need to decompile the html help file. For this task I use the free program keytools that can be downloaded here. Then, with the script (that can be downloaded here), choose the directory with the html files and the destination for the word document (in the GUI). Each html file will be inserted in a new word document. You need to have python, wxpython and windows extensions installed in order to run the script).

Getting the current call stack

Sometimes, especially inside user-exits that are called in several different places, we need to know where it was called to decide what to do.

Some fields in the "sy" structure can be useful for this: sy-tcode (transaction), sy-repid (current main program), sy-cprog, sy-xprog, sy-xform, etc.

This info might not be enough, however: we might need to know if we are inside a given form, for example, even if we might be several levels below (the form called another form, which in turn called another form, that then called a function, that called our exit..).

To know this, we need to get the current call stack. In debug mode, we can see it by clicking the button "Calls". Getting that info in our programs is just as easy: just use function SYSTEM_CALLSTACK, and you'll get an internal table with that same information.