Create SAP IDocs from BAPI

In SAP, the Business Application Programming Interface (BAPI) makes it possible to update points on a supply chain when used with Application Link Enabling and IDocs. Here's how one consultant makes it work.

The whole point of SAP—or any ERP system, for that matter—is to automate processes and facilitate data transport. SAP provides a number of mechanisms to automatically move data along in a business process as various steps are completed. But with so many powerful tools on hand, it’s often difficult to know which one is right for the job.

In SAP, the IDoc is the primary mechanism for moving data from one system or module to another, and for exchanging data with foreign systems. Appropriately, SAP provides a triggering mechanism to set IDocs in motion: Application Link Enabling (ALE). Business processes are configured to trigger ALEs, and ALEs set IDocs in motion, passively sending business documents where they need to go.

But it’s the Business Application Programming Interface (BAPI) that facilitates data creation, storage, and retrieval in SAP applications. And it’s possible to set the ALE/IDoc trains in motion with no user intervention whatsoever. Here’s how you can make this work on your next SAP engagement.

Hitting 100 percent automation
When you create an application that creates or modifies data, you’re interacting with a business object residing in SAP. The interface that enables this is the BAPI, and every business object in SAP generally has at least one BAPI that ties it to an outside application.

Every BAPI has a method interface, which is defined at the time the BAPI is stored in the Business Object Repository. From this interface, you can set up and execute ALE triggering, which in turn, can set IDocs in motion every time a new business object of a particular class is created, or any time such an object is modified. In other words, the method you associate with the objects to be created or modified will automatically trigger downline processes whenever an object of that class is created or modified. You don’t even have to put ALE triggers in your application, as you’re probably used to doing. You’ll never have to think about it again.

SAP utility: Set it and forget it
As an example, let’s imagine that your client is a manufacturer with a lengthy supply chain. Imagine being able to set up product pricing so that every time the pricing of one of your client’s products is changed, all of your client’s distributors, brokers, and customers are notified electronically, with a digital record of the change to load into their databases (eliminating potential data entry errors). Would that be a useful feature? You bet it would, and you don’t need to do anything to make it happen. The act of updating a master product record sets the entire process in motion.

Automation in action
Here’s how it works:
  1. Whenever a business object (any master record or transactional record) is updated in SAP via an application program, the BAPI assigned to that record or its class is executed. In my example, this is the creation of a pricing record associated with a product record, or an update to a pricing record.
  2. The BAPI is configured to trigger a workflow event once it has executed. You can set this up with a powerful but seldom-used SAP utility, transaction BDBG, which includes a screen you can configure to generate an ALE interface and all the required IDocs. So, in my example, any interaction with product pricing would configure pricing records as subobjects of product records.
  3. Any BAPI has an associated method that is defined, along with the BAPI object, in transaction SW01, the Business Object Builder. The associated method is configured at the time of the BAPI’s creation. Since a product pricing record update modifies the SAP business object, its selected method will be ChangeFromData (remember that this is in the Business Object Repository). When this object and this method are called, a custom message (created for this purpose and stored in the messaging table EDMSG) is generated. In my example, a product pricing record change will generate a custom message via the ChangeFromData method.
  4. You must set up the custom message’s type beforehand via transaction BDBG to associate that unique message type with the IDoc types and function modules that the processing routines need in order to send messages announcing the price change. The option to insert these appears on the transaction screen after you’ve entered the name of the object you want to work with and its associated message.
    In my example, the ALE trigger that is activated by a product pricing record update will now distribute the updated product pricing data according to the distribution that is now part of the customized pricing update message. This will include the sending of the information to partner companies, by whatever interfaces are normally used to communicate with them.

Why this is so helpful
The only way to truly appreciate this level of automation is to work with a system that requires human intervention for ALL these steps—or, even worse, if you had to create systems to do it. I’ve been there, and to ice the cake, I did most of it via EDI. Once you’ve done it the hard way, the easy way is all the more welcome.

This process will give you a BAPI generation report that details every action carried out by the system as a result of activity on your BAPI object. This makes testing a breeze: All your generated IDoc types will be on this report, and you can click on any of them to view the objects that are created by the process. It doesn’t get any easier than that!

About Scott Robinson

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks