An ALE interface can be generated from an application function module.
Caution
Both parts of this interface (function module and ALE interface) must be kept stable from one release to the next:
This applies specifically to the importing parameter, which passes data with a complex data type, and the exporting parameter, which returns the processing results. These are the only parameters that the interface can contain.
The importing parameter can reference a structure type for processing an individual object or reference a table type for mass processing of objects. To improve system performance, mass processing is recommended.
The parameters have to be documented in sufficient detail, including those in deeply-nested components and structures. This is especially important for the initial data transfer.
The processing results are returned in a predefined structure in the exporting parameter
For individual processing - reference to type BAPIRETS
Type BAPIRETS is a structure with the following fields: BAPIRETS:
OBJECT_KEY |
Business Document Service: Object Key |
OBJECT_MSG |
Table type of BAPIRETC |
OBJECT_KEY is the key of the processed object. OBJECT_MSG is a table type of BAPIRETC. BAPIRETC has a similar structure to BAPIRET2, but contains a new field COMPONENT with type CHAR255 to address a component in the complex data type. This enables the applications to return multiple messages for a specific object with component addresses.
For mass processing – reference to type BAPIRETM
Type BAPIRETM is a table type of structure BAPIRETI. BAPIRETI:
OBJECT_IDX |
Object index |
.INCLUDE BAPIRETS |
Return parameter with key for individual object |
This enables the applications to return multiple messages for an object determined by OBJECT_IDX.
Message type and commit work or rollback work procedures of the caller (for example, ALE layer):
Usually an object is processed by the application function module successfully or with warnings. In this case, a message of type S (success) or W (warning) is returned and the caller sets a commit work
.
In some cases, an object cannot be processed, for example, if an error is identified, but the transaction can still continue. Then at least one message of type E (error) is returned. The caller sets a commit work
.
If the transaction cannot be processed further because of errors, for example, if a posting is partially made and then an error occurs and a rollback work
is required. Then at least one message of type A (abort) is returned. The caller sets a rollback work
.
With mass processing, the rollback work is applied to all objects. The reaction of the ALE layer in this case is described in the Generating ALE Interfaces: Procedure section.
If the exporting parameter has not been filled, this means that processing was successful. In this case, the caller sets a commit work
.
Before the interface can be delivered, it must be released
This means that only compatible changes are permitted (similar to behavior with BAPIs).
Released interfaces can be enhanced, but with restrictions
The interface owner (such as SAP), can insert the following new objects, for example:
Elementary fields
Structure types
Table types
Append structures
Modifications such as deleting existing objects or changing references are not allowed (similar to behavior with BAPIs).
Partners or customers can enhance the interface after it has been released only in append structures. Modifications are not permitted at this point.
Caution
Restrictions (see also the Generating ALE Interfaces: Procedure section).
A commit work
is not allowed in the function module.
A component with the name APPL_SNAME in the structure of the complex data type is also not allowed.