Maintaining the BAPI-ALE Interface

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 on the outbound processing side

  (It creates the IDoc using the BAPI data and dispatches it.)

• 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.

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.

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 for compatibility reasons.

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.

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 Interface menu, choose one of the options - Create, Change, Display, Check, or Delete.

   Create Interface

   Prerequisite: An interface has not yet been generated for this BAPI or one already generated has been deleted using the Delete option. Names for the objects to be generated are suggested. You can change them.

   Specify 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.

   You can make the following entries in the following dialog box:

   IDoc type:	<Message type>01
   Example:	MYTEST
   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. The following options are available: Data filtering allowed 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. With BAPI-ALE interfaces generated by SAP, this option is usually selected. Also keep the notes outlined below in mind. 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 generate only the message and IDoc types (required fields), or only one of the function modules (optional fields), by leaving the field for which no object is to be generated, empty.

   Confirm your entries.

   The dialog box Enter Segment Name appears.

   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 segment Example: E1MYTEST
   E1BP_XX...	For parameters of 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

   Prerequisite: Objects have already been created for this BAPI.

   To regenerate the objects of an existing ALE interface after the BAPI 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 its object.

   Display Interface

   Prerequisite: 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

   Prerequisite: 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 if it has not yet been released.

   The IDoc segments are only 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

   Prerequisite: Objects have already been created for this BAPI.

   The system checks whether all the objects related to this BAPI are available in the system. It also checks whether objects (IDoc type and segments) have already 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 (by choosing  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. The segments and IDoc types which are relevant for the release are determined. The new status is assigned to objects which have not yet been released.

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

   The generated function modules are not released.

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

Keep in mind the following notes:

• Namespace enhancement

  Namespace enhancements are also supported for customers and partners.

• Filtering for 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 Filtering of Data.

  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 more 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. All the messages in the target system are processed in an object channel in the same order 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 more information, see Serialization By Object Type.

• Links

  The link in ALE answers the following questions:

  Outbound processing: From which application object has the IDoc been created? 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 display 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, one single IDoc status record is written:

  Message type A	Status 51 (Application document not posted, with DB rollback)
  Message type E	Status 51 (Application document not posted, no DB rollback)
  Message type W, I or S	Status 53 (Application document posted)

  If the return parameter is a TABLES parameter, multiple IDoc status records can be written, depending on the message types in the table:

  Message type A	Status 51 (Application document not posted, with DB rollback) (There is no status for message type S)
  Message type E	Status 51 (Application document 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 is the same in the BAPI function module (IMPORT and/or TABLES), 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 use the generation function because only one segment can be loaded with a dataset of maximum size 1000 bytes.