Data Management

Save time and effort with SAP's ALE change pointers

Application link enabling (ALE) allows SAP integrators to distribute their applications across multiple SAP systems. If you're a consultant working on an SAP implementation, you need to know how this feature of SAP works.

The SAP R/3 Application Link Enabling (ALE) feature is one of the critical components in SAP’s provision of stable data distribution across domains. Keeping all systems in a company (and better yet, intercompany data communication) on the same page results in a substantial reduction in errors from reentry and misentry of data, as well as increased efficiency. It’s one of the biggest reasons companies implement SAP and keep SAP consultants working.

SAP’s features are so thoroughly integrated, however, and provide so many options, that conventional IT thinking can take over if you’re unaware of its conveniences. It’s often difficult to break old habits, even when SAP provides labor-saving shortcuts.

Let’s take a look at how ALE enables some of these labor-saving characteristics. Change pointers can become a virtual administrative assistant, performing essential follow-up tasks when database changes are made. And with some creativity, ALE can keep a company similarly in step with partner companies.

Mastering master data
SAP recognizes that a company’s master data—customer records, product records, employee records, supplier records—are the seed data from which all other data grows. ALE gives you a great deal of control over your client’s master data, for the obvious reason of keeping master data stable between multiple systems. And the demands of the modern workplace necessitate that users have the capability to modify master data via a business system. In the past, modification of master data was a direct, permission-drive process, often handed off by a user in authority for IT to handle. These days, there’s no time for that.

To meet this need, a conventional solution is to put a program in place to inform every system when a change is made in any arbitrary master record. Though this is somewhat provisional—some middleware could be necessary to send out the word to different systems because your client undoubtedly has a number of different logical types of master records—it can be accomplished without much difficulty. Stand-alone programs for this purpose are grouped under the master data transaction screen. You can find this via one of SAP’s transaction interfaces, BALE (from the Main Menu, go to Logistics, then Central Functions, then Distribution).

Replacing programs with change pointers
But you don’t even need to go that far. You can trigger outbound master data updates with ALE change pointers. With this technique, you can configure the passive triggering of an outbound process whenever a master record is created or changed, without putting a program in place for the purpose.

SAP includes a scheduled program, RBDMIDOC, that runs periodically to check the change pointers for a particular message type. Distribution of any new or revised master data is automatically initiated via ALE. RBDMIDOC references the correct IDoc program for any given type via TBDME (the TBDME table also cross-references message types with the ALE change pointer table) so that the data goes where it should and is processed accordingly. Transaction BD60 is the interface provided by SAP for maintaining the TBDME table. The mechanism to distribute the new or modified data, then, is already in place.

Enabling master data distribution
Because master data is so sensitive, you must enable your client’s SAP system to handle master data distribution when changes are made. You can do this either globally or by message type.

The global transaction is BD61. Just check the flag. You get there via ALE customizing-IMG | Distribution Scenarios | Global Organizational Units | Master Data Distribution | Activate Change Pointer | Activate Change Pointer.

For enabling by message type, use transaction BD50 (same path as above, but your last step is Activate Change Pointer For Message Types. The transaction gives you a list of message types and an Active Flag that may be checked for each one.

Limiting the change pointer to specific fields
As an added convenience, ALE allows you to narrow the outbound trigger to specific fields in a master record. That is, the process of distributing the change throughout the system will occur only if specific fields are changed.

For example, your client may wish to send modified product master records to the warehousing system only if the dimensions of the product packaging are altered. You would mark the fields used for storing dimension values in the product master record for the ALE change pointer, and the master record would be outbound to the warehousing system only if changes occurred in those fields (see Figure A).

Figure A

To do this, use transaction BD52 (ALE customizing-IMG | Extensions | Master Data Distribution | Activate Change Pointer Per Change Document Item). You can select fields within your message type for change pointer enabling or suppress the pointer for fields already listed. Note that SAP provides a default list of live change fields for any given message type.

Testing your change pointer changes
The net effect of your reconfiguration will be the generation of an IDoc, of course, when a master record is changed. And this IDoc is generated when RBDMIDOC is executed, as it detects the change pointer.

RBDMIDOC is usually a scheduled program. However, you can execute it manually as needed. To prevent premature systemwide IDoc generation based on production transactions, your manual run of RBDMIDOC can be limited to the specific message type you’re testing (you’ll be given a selection screen for this). The program will report back to you the number of updates it executes.

You’ll want to view the generated IDoc. SAP provides two transaction interfaces that allow you to view IDocs: WE02 and WE05. Remember that it’s not enough to just look the IDoc over and note the particular data item you intended to change. To be thorough, look for a status 03, which will verify data passed to port (if you don’t have this status record, you have a problem).

The value-added consultant: Updating partner companies
The concept of configurable passive data distribution extends, of course, beyond your client to your client’s clients. Whether or not your client’s trading partners have SAP systems, you have the opportunity to suggest increases in efficiency and accuracy in those trading relationships by using the techniques above.

For example, changes in the pricing structure of a product may be configured to initiate, via change pointers, communications to outside customer systems—a process that is usually conducted via EDI, with deliberate manual steps preceding the actual generation of the EDI document. Not only does this technique eliminate those manual steps, but the direct transmission of price numbers from the master database to the customer’s database greatly reduces the chance of error through the manual reentry of data. You can even use a change pointer to generate EDI, if that’s what your client’s client uses.

Care must be taken, of course, that such powerful options are employed where errors cannot occur that will harm the business relationship (such as the accidental ordering of products or the sending of duplicate invoices), or that safeguards are put in place to soften the effects of any outbound misfires. But with forethought and good communication, you can take your client to a new level of automation and convenience with outside parties, enhancing relationships all around.


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