Show TOC

Generating the ALE Interface: Procedure and Programming ModelLocate this document in the navigation structure

Use
Process

To generate an ALE interface from a complex data type, proceed as follows:

  1. Start the transaction with the transaction code BDFG.

  2. Enter the function module and business object type that the interface is based on.

  3. To maintain, display, check, or delete an interface, choose an option in the Interface menu, or choose the relevant icon.

The following functions are available:

  • Create Interface

    Names for the objects to be generated are suggested. You can change them.

    • Specify a name for the message type.

      Confirm your entry.

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

      IDoctyp

      Outbound function module

      Inbound Function Module

    The proposed package and function group are those to which the function module belongs. You should use your own packages and function groups to generate your interfaces.

The following options are provided for the ALE inboung page:

  • In Update Task

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

  • Mass Processing

    If you want to allow mass processing, you have to select this option. The associated application module must support mass processing.

    You can only generate the message type (mandatory field) and the IDoc type (mandatory field) or only one of the function modules (optional field), by leaving the field blank for which no object is to be generated.

    Confirm your entry.

    If a structure is to be more than 1000 bytes long, then whilst the interface is being generated, the structure is mapped to a parent segment with child segments.

    The generated objects are displayed as a tree structure. From here you can access the individual objects. All changes are put in transport requests.

  • Change Interface

    Choose Change to regenerate the objects of an existing ALE interface after a change to the module. The IDoc type and the IDoc segments are regenerated only if the interface structures have been changed. The function modules are always regenerated.

    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

    Choose Display to display all existing objects for this interface. You get an overview of the relationship between the module and the ALE interface. The objects are displayed even if the application module no longer exists.

  • Delete Interface

    Choose Delete to delete an ALE interface.

    The function modules (inbound and outbound) are deleted if they are 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

    Choose Check to check whether all objects relevant to this ALE interface 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). If the application module no longer exists, a warning is logged.

  • Release Interface

    Developers can change the release status of the IDoc type and segments.

    A check is made that the generated interface of the module is up-to-date, before it is released. If not, it cannot be released. You are notified of the segments and IDoc type relevant for the release. The new status is assigned to objects which have not yet been released.

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

    The generated function modules are not released.

Programming Model

Application Interface for the ALE Layer in Outbound Processing

The generated outbound function module for the ALE layer which is called from applications on the outbound side looks as follows:

*"--------------------------------------------------------------------    
*"*"Verbuchungsfunktionsbaustein:    
*"    
*"*"Lokale Schnittstelle:    
*" IMPORTING    
*" VALUE(APPLICATION_OBJECTS) TYPE COMPLEX_DATA_TYPE    
*" VALUE(RECEIVERS) TYPE BDI_RCVT OPTIONAL    
*" TABLES    
*" COMMUNICATION_DOCUMENTS TYPE COMM_RETS OPTIONAL    
*" EXCEPTIONS    
*" ERROR_CREATING_IDOCS    
*"--------------------------------------------------------------------

In addition to the parameter of the application module APPLICATION_OBJECTS, the interface contains the following parameters:

RECEIVERS

This parameter is optional.

  • If this parameter does not contain a value, the communication partners for the message type are determined according to the information in the ALE distribution model. If no valid communication partners are found, an IDoc is still created but no message is sent. Otherwise an IDoc is created and the message is sent to the partners. In this context all the communication partners are logical systems.

  • If this parameter contains values (partner number and partner type as communication partners), an IDoc is always created and the system attempts to send the message to the communication partners without reading the ALE distribution model.

COMMUNICATION_DOCUMENTS

Provided the function module is not called in the update task and IDocs can be created, this return parameter is filled. It has different structures depending on the processing type:

  • Individual processing - the function module can only process one object. In this case the return table contains in the field OBJKEY the IDoc number that was sent to the partner in fields RCVPRN and RCVPRT.

  • Mass processing - the function module can process multiple objects at a time. Information is returned in the same way as with individual processing but there is also an index in field OBJ_INDEX for each object determined from the sequence of the transferred objects.

    This means that application programs can request details of the created IDocs stored in the database through the return parameter COMMUNICATION_DOCUMENTS. For example, the communication partners can be determined from fields RCVPRN and RCVPRT and the appropriate IDoc number from the OBJKEY field. If this parameter does not contain a value (function module call is not in update task), no IDoc is created.

    In principle, errors in outbound processing should be purely technical and trigger the exception ERROR_CREATING_IDOCS. Serious errors such as Separate logical system not defined, No message type available, Missing or incorrect IDoc type, or No data records have been transferred are issued directly from the ALE layer with an A message (abort). The calling program is responsible for other cases. Usually an abort automatically results in a rollback of the changes made in the database.

    If the function module is called in the update task, the return parameter COMMUNICATION_DOCUMENTS is not filled and no ERROR_CREATING_IDOCS exception is triggered.

Communication Partners, ALE Distribution Model, and Partner Profiles

According to the enhancement concept several ALE interfaces generated by partners or customers may be available for one application module with a complex data type. Which ALE interface is called at runtime and for which communication partner is determined by one of the message types defined in the ALE distribution model. This means that the applications should first determine this information from the interface provided by ALE, and then call the ALE interface:

FUNCTION ale_model_determine_outbound.    
*"--------------------------------------------------------------------    
*"*"Lokale Schnittstelle:    
*" IMPORTING    
*" VALUE(APPL_FUNCTION) TYPE RS38L_FNAM    
*" EXPORTING    
*" VALUE(PARAM_OUTBOUND) TYPE BDI_OUTBT    
*" EXCEPTIONS    
*" OWN_SYSTEM_NOT_DEFINED    
*" NO_AUTHORITY    
*"--------------------------------------------------------------------

Similarly, the outbound parameters can also be determined by the partner profiles:

FUNCTION ale_pprof_determine_outbound.    
*"------------------------------------------------------------------
*"*"Lokale Schnittstelle:    
*" IMPORTING    
*" VALUE(APPL_FUNCTION) TYPE RS38L_FNAM    
*" EXPORTING    
*" VALUE(PARAM_OUTBOUND) TYPE BDI_OUTBT    
*"-------------------------------------------------------------------

The application function module name, from which the ALE interface is generated, is transferred in the parameter APPL_FUNCTION. Provided that corresponding messages have been maintained in the ALE distribution model, the return parameter PARAM_OUTBOUND is filled. The application ascertains which ALE outbound function module is to be called from the FUNCNAME field of the PARAM_OUTBOUND parameter (referenced to table type) and ascertains which message this function module corresponds to from the MESTYPE field. The application also ascertains from the RECEIVER field whether the call concerns several, one or no valid communication partners. If you want the communication partners to be determined using the ALE distribution model, you should call the determined outbound function module with the relevant data, without explicitly passing the communication partners using the RECEIVERS parameter. However, if you want to send the message only to specific communication partners, you should transfer the communication partners using the RECEIVERS parameter.

Commit Work

After calling the generated outbound function module COMMIT WORK must be included in the programming in the application. Commit work closes the current transaction and starts further tasks such as update task and background task through which the database is updated by a posting or an IDoc is dispatched through tRFC or file interfaces.

The COMMIT WORK does not have to be executed immediately following the call, it can also be executed at higher call levels or following several outbound function module calls. Since many processes have to be carried out in the COMMIT WORK step, IDoc locks created for the outbound function module call must not be removed before the COMMIT WORK. This prevents any unwanted actions being carried out on these IDocs.

ALE Layer Interface to Applications on the Inbound Side

The generated inbound function module called by the ALE layer on the inbound side has the following standard interface:

*"----------------------------------------------------------------------    
*"*"Lokale Schnittstelle:    
*" IMPORTING    
*" VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD    
*" VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC    
*" EXPORTING    
*" VALUE(WORKFLOW_RESULT) LIKE BDWF_PARAM-RESULT    
*" VALUE(APPLICATION_VARIABLE) LIKE BDWF_PARAM-APPL_VAR    
*" VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK    
*" VALUE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS    
*" TABLES    *" IDOC_CONTRL STRUCTURE EDIDC    
*" IDOC_DATA STRUCTURE EDIDD    
*" IDOC_STATUS STRUCTURE BDIDOCSTAT    
*" RETURN_VARIABLES STRUCTURE BDWFRETVAR    
*" SERIALIZATION_INFO STRUCTURE BDI_SER    
*" EXCEPTIONS    *" WRONG_FUNCTION_CALLED    
*"----------------------------------------------------------------------

In this inbound function module the application module with the application data is called. As described in section Interfaces and Naming Conventions, the application module cannot execute a COMMIT WORK. The application should return the processing results in the return parameter with which the corresponding IDocs obtain the correct status.

Applications can also determine the communication data of the IDocs by calling the following function module from within their own function module:

FUNCTION ALE_IDOC_INFO_IMPORT.    
*"----------------------------------------------------------------------    
*"*"Lokale Schnittstelle:    
*" TABLES    
*" IDOC_INFO STRUCTURE EDIDC    
*"----------------------------------------------------------------------