Closing the gap between transaction functionality and application programming interfaces

I have had a couple of conversations with different prospects and customers around the use of SAP's standard application programming interfaces (API) instead of transaction recordings. The biggest hurdle thus far has been with identification of the BAPI or RFM that is most appropriate to what one wants to do.

BAPI's and RFM's as delivered 'standard' by SAP are a great choice if you want to retain the Microsoft Excel-centric experience. Also good if you want to quickly enable an integration between your SAP system and something external like a web form or an external source like a workbook or small database. The key word  here is STANDARD. If you have custom fields or complex user exits, or enhancements to your SAP transaction that are not incorporated into the standard BAPI/RFM, or a Z version of that API,  then you will have an incomplete or potentially incomplete process.

The flow logic of your SAP transaction may have business logic within it that the API does not. If however you have implemented the standard SAP system and you're interested in handling some of the quirks of the requirements of that process or sub-process using an API then Winshuttle Direct may be a perfect fit. This is especially true if you are not able to run GUI scripting on your SAP system which is often disabled at the behest of auditors, security, or BASIS.

Some SAP transactions don't work particularly well in batch and non batch mode and therefore have to be recorded using GUI scripting mode. The alternatives are not very elegant, they might involve dozens of specific combination scripts that have to be passed over the same transaction data numerous times with a lot of IF.. statements to trap specific scenarios. While those multi-script, multi-pass activities do lend themselves to consistency, they are inefficient and sometimes manual entry/editing seems more expedient. So what might some of these scenarios for GUI scripting look like?

Well, for starters, look at the screen in the transaction. Is the data laid out in a grid or a table? If it is, does the screen have controls that allow you to search, filter or sort the data? These controls may be rendered as buttons or menu commands but if they exist, they may suggest that you can avoid GUI scripting. When you enter the data as new data, does the table or gird, auto-sort the data or does it simply append the item to the end of the grid or table? Under these circumstances, GUI scripting may be unavoidable. Some common scenarios are the multi-language options in MM02 under additional data.

You have very limited choices in this screen. You can pick a row and delete the line or you can navigate to the last visible row and simply insert data. This screen interestingly, always shows your logon language as the first language. So what you could do, if you wanted to change all the descriptions for a specific language, without using GUI scripting, is to logon with a script that uses that specific language and then always choose the first row and change that. Again, not very efficient.

Another transaction screen  in the same transaction (MM02) that can prove challenging is the Units of Measure (UoM) screen. Again, the ordering here is not always consistent  between materials and the exact position of the alternates may be difficult to determine in advance.  Additionally, the Alternate Unit (AUn) is read only as is the Base Unit (BUn). You can experiment with these screens a little, and depending on the complexity of your material master, you may have relatively good success with batch/non batch or even GUI scripting. Eventually you may simply decide that you need a different approach.

Fortunately a search on Google and in particular on SAP's SCN quickly reveals that you have a BAPI that you can use to perform some of these maintenance actions. Again, I don't want to downplay the complexity of this activity as it is complex. You are now using something that was never really designed to be leveraged by 'ordinary' users of SAP transactions. However, if you know your SAP transaction and more importantly, know your SAP data then this kind of artifact in your arsenal of Winshuttle business process automations may prove to be indispensable and the envy of other SAP users in your business.

The BAPI concerned is BAPI_MATERIAL_SAVEDATA. A quick search on Google revealed some 22,500 hits for this BAPI so it is clearly a popular one.  The implementation with Winshuttle is very straight forward - you simply select the BAPI from the Business Object Repository (BOR) using Direct and select the fields and tables that you want to use. There are some mandatory ones, but you will quickly determine which those are, especially if you spend the time looking at the documentation and examples on SCN. You can also look at notes like Note 545626 - FAQ: Data transfer problems in SAP's Service Market Place however you generally need an S number to access these kinds of reference materials.

You will need to select the BASIC_VIEW and the MATERIAL in the Headdata section of Input structures. Then to make life a little easier with the UNITSOFMEASURE and UNITSOFMEASUREX tables, Direct provides the ability to create a category that enables the combining of the two tables. For non ABAPers, understand that the tables suffixed with an X are marker tables. For some inexplicable reason, you have to explicitly tell the BAPI_MATERIAL_SAVEDATA program which fields you plan to send data in. I am guessing that the reason for this is that you may be using fields that contain nulls, and the nulls may be valid. If you want to clear data out. using an X indicator makes it clear to the program which fields you are using and which fields should be acknowledged with the update.

Now within Transaction, you will map the fields to a Microsoft Excel workbook or other datasource and then simply fill your workbook up with the data and run your integration to SAP by way of this BAPI rather than a transaction recording. Take special note of the use of constants 'X' for the BASIC DATA field and for the flags. Also note that the table data is automatically wrapped with a loop. You will still need to assign H/D column indicators but the loop is automatically inserted.

Though this particular implementation has been designed to specifically delete alternate UoMs from materials, it is a method that can be used in a variety of ways to manipulate many attributes of the material master and therefore help with your SAP Master Data Management (MDM).