What is ALE?

What is ALE?

>>>PREVIOUS>>>

Use transaction WE20 to maintain partner profiles, or from WEDI select IDOC -> Partner Profile, or from SALE (ALE Customizing guide) -> Communication -> Manual maintenance of partner profiles -> Maintain partner profiles.

The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.

The process can be divided into the following sub-processes:

1. Outbound Processing

1. • Receiver determination

2. • Calling the generated outbound function module

3. • Conversion of BAPI call into IDoc

4. • Segment filtering

5. • Field conversion

6. • IDoc version change

7. • Dispatch control

2. IDoc dispatch

IDocs are sent in the communication layer by transactional Remote Function Call (tRFC) or by other file interfaces (for example, EDI).

tRFC guarantees that the data is transferred once only.

3. Inbound Processing

1. • Segment filtering

2. • Field conversion

3. • Transfer control

4. • Conversion of IDoc into BAPI call

5. • BAPI function module call

6. • Determination of IDoc status

7. • Posting of application data and IDoc status

8. Error Control

Interrogating the Distribution Model

You do not have to interrogate the distribution model, it is optional.

There are two function modules that can interrogate the ALE distribution model: ale_model_determine_if_to_send and ale_model_info_get. ale_model_determine_if_to_send is called with the message type and possibly with the logical receiving system if it is already known in the application. A check is made in the ALE distribution model that a message flow has been maintained for the input parameters. If this is not so, the export parameter idoc_must_be_send is set to initial; otherwise, an "X" is returned. If there are filter objects in the distribution model that control this message flow, they are not evaluated. An IDoc must only be created if ale_determine_if_to_send returns an "X".

Module ale_model_info_get is used for more complex queries made to the ALE distribution model. It is called with the message type to be dispatched. In return, you get a table containing all the potential recipients of this message type, as well as the associated filter objects. Note that there may be several entries for one receiver in the table returned. If there are no entries in the distribution model, the exception no_model_info_found is issued. If an exception is issued, an IDoc does not have to be created. Otherwise an IDoc does have to be created. You will find the receiving logical system in the rcvsystem field in a table entry.

The end result, that is, whether the receivers receives an IDoc and what the IDoc looks like, is only determined after all the filter objects for a message flow in the distribution model have been evaluated. This is carried out in the ALE layer.

Structure of Control Records The control record consists of a field string for the structure edidc. The relevant fields are listed below; all other fields should be left with their initial values. List of fields for the control record Field Description Comment mestyp Logical message type. Conveys the business meaning of the message. Mandatory field idoctp Basic structure of the IDoc. Identifies the layout set that uses this message. Mandatory field cimtyp Structure of customer extension. If the customer extends an SAP basic structure, he must give a name to the structure of his extension. Mandatory field if customer has made an enhancement. Otherwise initial. rcvprt Partner type of the receiver; “LS” (i.e. logical system) for ALE. Optional field. See below. rcvprn Partner number of the receiver; the logical system for ALE. Optional field. See below. rcvpfc Partner function of the receiver; normally initial for ALE. Optional field. See below. When the receiving system has been determined from the distribution model, it can be written to field rcvprn. Then field RCVPFC must be filled with "LS" (for logical system). If necessary, the partner function can be written into the field RCVPFC. However, the partner function is not normally used in ALE. What is important, is that either both rcvprt and rcvprn are left empty or that both are filled. If rcvprt and rcvprn are passed with their initial values, the receivers are determined entirely in the ALE layer.

Structure of the Data Records Replacing SAP Codes with ISO Codes [Seite 67] The data records of an IDoc are created in an internal table with structure EDIDD. The relevant fields are shown below. Important Table Fields for Creating IDoc Data Records Field Description SEGNAM Segment type of the IDoc data record SDATA 1000 byte-long character field for the data used by the IDoc The remaining fields in EDIDD should be left initial. All the segment types and their sequence are specified in the IDoc structure. The data records are structured according to this sequence and included in the internal table. For each segment type of the IDoc structure, there is a DDIC structure with the same name. A field string with this structure is used for creating a data record. The application data is mapped to the field string. The segment type is written to the field SEGNAM, and the field string is written to the field SDATA. This data record is then included in the internal table with the structure edidd.

Converting Currency Amounts Currency amounts have to be converted from an SAP system format to a format that can be understood externally. In the SAP system, all currency amounts are stored with two decimal places. If a currency has a different number of decimal places, the currency amount has to be converted. You can use function module CURRENCY_AMOUNT_SAP_TO_IDOC for this conversion; it performs a suitable currency amount conversion for IDocs. We recommend that you encapsulate the code in a subroutine _CURRENCY_SAP_TO_IDOC.

Replacing SAP Codes With ISO Codes There are ISO codes for country keys, currency keys, units of measure and shipping instructions. According to SAP design guidelines, you should use ISO codes for an IDoc if they are available. When you set up the IDoc, the SAP codes have to be replaced by ISO codes. To do this, you can use these function modules: Function modules for converting SAP codes Domain Function module Currency keys CURRENCY_CODE_SAP_TO_ISO Country keys COUNTRY_CODE_SAP-TO_ISO Units of measure UNIT_OF_MEASURE_SAP_TO_ISO Shipping instructions SAP_TO_ISO_PACKAGE_TYPE_CODE We recommend that you encapsulate the code in a SUBROUTINE _CODES_SAP_TO_ISO.

Left-justified Filling of IDoc Fields All fields must be filled left-justified. This happens automatically for character fields. If the original field of the application is a non-character field, you must execute a condense on the corresponding field in the IDoc segment. To find out which fields require a condense, see the documentation structure for a segment type. The name of the documentation structure begins with "E3" or "Z3" (instead of “E1” or “Z1”); otherwise it is the same. This structure contains the same fields as the "E1" or "Z1" structure. But here you will find the original data elements and domains of the application. All fields with a data type unequal to char, cuky, clnt, accp, numc, dats, tims or unit require a condense. We recommend that you encapsulate the code in a subroutine _CON

Calling MASTER_IDOC_DISTRIBUTE After the MASTER_IDOC_DISTRIBUTE has been called, you must specify a COMMIT WORK; the standard Database Commit at the end of the transaction is not sufficient. The COMMIT WORK does not have to directly follow the call; it can be specified at higher call levels or after multiple calls of MASTER_IDOC_DISTRIBUTE. Note that the IDocs created remain locked until the called transaction has been completed. If you want to unlock them earlier, you can call one of the following function modules: • DEQUEUE_ALL releases all locked objects • EDI_DOCUMENT_DEQUEUE_LATER as a parameter releases the transferred IDocs If the application document is created via the update program, the call of MASTER_IDOC_DISTRIBUTE must also be performed in update task (if an update call has not already been performed at a higher level).

Exceptions and Export Parameters of MASTER_IDOC_DISTRIBUTE The module uses the table parameter COMMUNICATION_IDOC_CONTROL to return the control records of the IDocs that were created in the database. To find out the IDoc number and the current status for example, see fields DOCNUM AND STATUS. In general, this table is not relevant to the calling application. If the IDoc recipient was passed in the control record when MASTER_IDOC_DISTRIBUTE was called, but the distribution model does not allow the recipient to receive this IDoc, exception ERROR_IN_IDOC_CONTROL is output with an appropriate error message. If a receiver was not given in the control record and ALE does not find a recipient in the distribution model, an exception is not issued. If you want to react to this case, you must query the return table COMMUNICATION_IDOC_CONTROL. If this table is empty, no IDoc was created. This different behavior for the initial and non-initial receiver has historical reasons. The initial recipient is the standard case for master data replication: here it is of no further interest whether an IDoc was actually created. Presetting the receiver is the standard for dispatching transaction data: if an IDoc is not created, this is interpreted as an error.

>>>NEXT>>>