Generating the ALE Interface: Procedure and
Programming Model 
Procedure
To generate an ALE interface from a complex data type, proceed as follows:
...
1. Start transaction BDFG.
2. Enter the function module and business object type that the interface is based on.
3. To create, change, display, check or delete an interface, from the menu choose Interface and the appropriate option or choose the appropriate symbol.
The following functions are available:
· Create interface
The names of the objects to be generated are suggested. You can change these as required.
1. Enter a name for the message type.
Confirm your entry.
2. In the next dialog box you can enter the following:
IDoc type
Outbound function module
Inbound Function Module
The proposed package and function group are those that the function module belongs to. You should use your own packages and function groups when you generate your own interface.
The following options are available in ALE inbound processing:
- In update task
If the database changes are carried out by function module in the update task, then this option must be selected.
- Mass processing
If you want to use mass processing for IDocs, you have to select this option. The associated application function module must be able to process IDocs in mass.
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 in a hierarchy. From here you can access the individual objects. All changes are recorded in transport requests.
· Change interface
To regenerate the objects of an existing ALE interface after a function module has been changed, choose Change. 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 the associated object.
· Display interface
Choose Display, to display all the existing objects for this interface. An overview of the relationship between the function module and the ALE interface is displayed. Should the application function module no longer be available, the objects are displayed anyway.
· Delete interface
To delete an ALE interface choose Delete.
The inbound and outbound function modules are always 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
To check if all objects relevant to this ALE interface are available in the system, choose Check. 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 below). If the application function module is no longer available ,a warning is issued in the log.
· Release the interface
Developers can change the release status of the IDoc type and segments.
If the object is released, the system first verifies that the generated interface under the function module has the current status. If it has 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 not yet released.
During development the release of objects can be reset at any time. This action is linked 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 like:
*"--------------------------------------------------------------------
*"*"Update function module:
*”
*"*"Local interface:
*" 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 interrogating 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 several 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 Your own logical system is 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 during runtime and for which communication partners 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.
*"--------------------------------------------------------------------
*"*"Local interface:
*" 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.
*"-------------------------------------------------------------------
*"*"Local interface:
*" 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 the appropriate 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 the communication partners are to determined via the ALE distribution model, you should call the determined outbound function module with the appropriate data, without explicitly transferring the communication partners through the RECEIVERS parameter. However, if you want to send the message only to specific communication partners, you should transfer the communication partners using the RECEIVERSparameter.
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:
*"----------------------------------------------------------------------
*"*"Local interface:
*" 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 the section Interface and Naming Convention, the application function module is not allowed to raise a COMMIT WORK. The application should also submit the processing results in the return parameter with which the appropriate IDocs obtain the correct status.
Applications can also find out the communication data of the IDocs by calling the following function module from within their own function module:
FUNCTION ALE_IDOC_INFO_IMPORT.
*"----------------------------------------------------------------------
*"*"Local interface:
*" TABLES
*" IDOC_INFO STRUCTURE EDIDC
*"----------------------------------------------------------------------