Maintaining BAPI-ALE Interfaces 

The standard SAP system contains a large quantity of business objects and BAPIs. These include BAPI-ALE interfaces that are generated from BAPIs and enable asynchronous BAPI calls in ALE business processes.

You can develop your own BAPIs in the customer namespace and generate the associated BAPI-ALE interface.

The following objects are generated for a BAPI:

·         Message type

·         IDoc type including segments

·         Function module called in the outbound processing side. (It creates and sends the IDoc from the BAPI data).

·         Function module that calls the BAPI with the IDoc data on the inbound processing side

The difference to manually maintained message types is that the function module that processes the change pointers does not create an IDoc. Instead it fills the corresponding BAPI structures, determines the receivers and calls the generated ALE function module.

The message types, IDoc types and function modules that have been generated can also be used to distribute master data using the SMD tool.

Prerequisites

The essential prerequisite is that a BAPI exists:

·         You have developed your own BAPI in the customer namespace.

·         You have modified a BAPI from the standard system.

The BAPI-ALE interface is then created in the customer namespace for the new sub-type and a method assigned to it.

For more information see Implementing Your Own BAPIs.

 
Regardless of whether SAP delivers a BAPI-ALE interface for a BAPI with the new Release, any interface you have generated will continue to function in the same as in the earlier Release. You can regenerate the old interface to adapt newly added parameters, provided that SAP has not delivered a new interface in the new Release.

If SAP delivers a BAPI-ALE interface for a BAPI for which you have already generated an interface, you should use the new interface and delete the interface you generated. You can still use the old interface in the earlier Release. If you regenerate the old interface, some generated objects, such as segments of SAP objects could be overwritten, if the interface in your BAPI function module references BAPI structures but belongs to SAP.

If you want to take into account hierarchical dependencies between BAPI table parameters, then another prerequisite is that you define the hierarchy before generating the BAPI-ALE interface (see Defining Hierarchies Between BAPI Parameters). The specified hierarchy is evaluated when the interface is generated and incorporated in the interface coding. The BAPI-ALE interface must be regenerated following all subsequent changes made to the hierarchy.

Once the generated IDoc type has been released, the specified hierarchy of the asynchronous BAPI cannot subsequently be changed because of compatibility problems.

Refer also to the notes on related ALE topics at the end of this section. Here you will find information on data filtering and serialization of message types.

Procedure

On the ALE Development screen choose BAPIs ® Generate ALE Interface (BDBG).

In customer systems all object names must begin with Y or Z or with their own prefix.

Proceed as follows:

...

       1.      Enter the business object (object type) and the method underlying the interface.

       2.      In the menu path Interface choose one of the options - Create, Change, Display, Check or delete.

·         Create interface

Prerequisites An interface has not yet been generated for this BAPI or one already generated has been deleted using the option Delete.

Names for the objects to be generated are suggested. You can change these as required.

1.       Enter a name for the message type.

A dialog box appears.

The default names have the following naming convention:

Message type:              Business name
Example:                MYTEST

Confirm your entry.

2.       In the next dialog box you can enter the following:

IDoc type:                     <Message type>01
Example:                       MYTEST01

Outbound function module:     ALE_<OBJECT>_<METHOD>
                                          Example:    ALE_EXAMPLE_TEST

Inbound Function Module: IDOC_INPUT_<Message type>
                                          Example:    IDOC_INPUT_MYTEST                                

The default package and function group are those that the BAPI function module belongs to. You should use your own packages and function groups when you generate your own interface.

You have the following options:

·         Data filtering allowed

If you have filtered the data, you have to select the option Data filtering allowed in the dialog box when you are creating or changing the filters. With BAPI-ALE interfaces generated by SAP, this option is usually selected. Keep in mind the following notes:

·         Call in update task

If the database changes are carried out by methods using the update task, then this indicator must be selected.

·         Packet processing allowed

If you want to allow packet processing, you have to select this option. The associated BAPI must be able to process packets. You can set the packet size in ALE Customizing.

You can only generate the message type (mandatory field) and the IDoc type (mandatory field) by leaving the field blank for which no object is to be generated.

3.       Confirm your entries.

The dialog box Enter segment name appears.

4.       Enter a segment name.

The suggested segment type is derived from the message type or from the BAPI structure:

-          E1<Message type>  for individual fields as header segments
                                    Example:  E1MYTEST or

-          E1BP_XX...       for parameters of the structure BAPI_XX.
                                    Example:  E1BP_HUGO for BAPI_HUGO

If a segment contains more than 1000 bytes of data, child segments are automatically generated from it. Child segment names are extended with the digits 1, 2,...appended to the original segment provided that the length of the name is less than 27 digits.

·         Change interface

Prerequisites Objects have already been created for this BAPI.

To regenerate the objects of an existing ALE interface after an object method has been changed, choose Change. The IDoc type and the IDoc segments are regenerated, if the interface structures of the object method have changed. The function modules can only be regenerated, if the IDoc type or one of the segments has changed.

As when you create an object, a dialog box is displayed here also. The objects that already exist in the system are displayed in this dialog box. They are not input fields.

If a field is empty you can generate the associated object.

·         Display interface

Prerequisites Objects already exist for this BAPI.

All existing objects for this BAPI are displayed. This gives you an overview of the relationship between the BAPI method and the IDoc message type.

·         Delete interface

Prerequisites Objects have already been created for this BAPI.

The function modules can be deleted provided that they exist in the system.

The IDoc structure is deleted, provided it has not already been released.

The IDoc segments can only be deleted if they have not been released and are not used in other IDocs.

Finally, the message type is deleted, if it is no longer assigned to the IDoc type.

·         Check interface

Prerequisites Objects have already been created for this BAPI.

The system checks whether all the objects related to this BAPI are available in the system. The system also checks whether objects (IDoc type and segments) have been released.

The release status of objects can be changed (see set release and cancel release in the Notes below.

       3.      You can release the interface.

Developers can change the release status of IDoc types and segments (Edit ® Set release or Cancel release.  

The authorizations required are S_IDCDFT_AL+ and S_IDCDFT_ALL of the authorization object S_IDOCDEFT.

Before an object can be released, the BAPI must have already been released. If the object is released, the system first verifies that the generated interface in the BAPI method has the current status. If the object is not released, you are asked if you want to regenerate the interface. You are notified of the segments and IDoc type relevant for the release. The new status is assigned to objects not yet released.

The release can be reset at any time. This action is linked to the transport system.

The generated function modules are not released.

Result

The generated objects and their statuses are displayed on the screen. All changes are recorded in transport requests.

Notes

Keep in mind the following notes:

·         Namespace enhancement

As of 4.5A customers and partners can also enhance namespaces.

·         Filtering the Data Selection

The distribution of data can be linked to conditions that are defined as filters in the distribution model.

If you want to filter the data, you have to select the option Data Filtering Allowed in the dialog box when you are creating or changing the filters.

For more information see Data Filters.

The prerequisite for useful filtering at the functional and business levels is the existence of hierarchical dependencies between BAPI table parameters. The dependencies must be defined before the interface is generated. Choose BAPI Interface ® Data Filtering ® Maintain Hierarchy of Table Parameters (BDBP). Note that changes made to dependencies must be compatible, otherwise the filtering will have a different outcome. For further information see Defining Hierarchies Between BAPI Parameters.

·         Serialization

The function module on the outbound processing side has an optional parameter SERIAL_ID (reference to the channel number). This input parameter manages the assignment of messages to object channels. In an object channel all messages are processed in the target system in the same sequence they were created in the source system. An object channel is identified by a key from the object type of the BAPI and from the channel number.

For further information see Serialization Using Object Types.

·         Links

The links to ALE answers the following questions:

-          Outbound processing:

Which application object has the IDoc been created from?

The prerequisite is that the application has correctly filled the parameter APPLICATION_OBJECTS in the function module used for outbound processing.

-          Inbound processing:

From which outbound IDoc was the inbound IDoc created from and which application object was created from the inbound IDoc?

The prerequisite is that a key has been defined in the Business Object Repository (BOR) for the BAPI method and that this key is contained in the BAPI function module in the export and import parameters. This key may consist of several key fields. If there are no key fields in the BOR, a link to another object can be specified.

·         Documentation on Generated Function Modules

Documentation has been written on function modules generated for inbound and outbound processing. You can retrieve this documentation from within the interface. It describes the purpose of the parameters and their values.

·         BAPI Return Parameters and IDoc Status

Provided that the return parameter is filled by the application, the IDoc status and the associated information from the parameter is included in the IDoc. Message types determine the IDoc status.

If the return parameter is an EXPORTING parameter, only one IDoc status record is written:

Message type A:                  Status 51 (Application log not posted, with DB rollback)

Message type E:                  Status 51 (Application log not posted, no DB rollback)

Message type W, I or S: Status 53 (application document posted).

If the return parameter is a TABLE parameter, several IDoc status records can be written, according to the message types in the table:

Message type A:                  Status 51 (Application log not posted, with DB rollback)

(There is no status for message type S).

Message type E:                  Status 51 (Application log not posted, no DB rollback)

(There is no status for message type S).

No message type A or E:           Status 53 (application document posted).

The IDoc status records are written to the database in the same sequence as the messages in the return parameter.

If the return parameter has not been filled, it means that the BAPI has been successfully called by the IDoc. In this case, an IDoc status record with status 53 (application document posted) is written from the ALE layer.

If there is an error, only the first message from the return parameter is copied to the text in the associated error task (work item).

·         Restrictions on Generating Interfaces

-          If the reference structure of parameters in the BAPI function module (IMPORT and/or TABLES) is the same, you should not use the generation function. In this situation the IDoc segment is not uniquely mapped to the parameter. For this reason you cannot identify the parameters when the inbound IDoc is processed.

-          If the dataset has more than 1000 bytes in the reference structure of a parameter or in a field in the reference structure, you cannot set the generation function because only one segment can be loaded with a dataset of maximum size 1000 bytes.