Application Link Enabling –SAP data interfacing ALE is SAP proprietary technology that enables data communications between two or more SAP systems and or R/3 and external systems. ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time . ALE is SAP’s solution to support distributed applications.
An IDOC Type: is an SAP Data Dictionary defined structure provides the highest level definition for a file has a predefined structure represents a series of related business documents An IDOC (formally ‘Message’): is the occurrence of a message type is the actual representation of a business transaction
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
The IDOC data records contain the data of the message. The data records are passed in an internal table and they have to match the structure of the IDOC (sequence of segments, min/max, hierarchy etc.) EDIDD is a generic structure used for all IDOC segments SEGNAM field identifies the segment type SDATA contains the actual data of the segment
Status Record- table EDIDS –Information we get from Status record: Status number Message IDoc type Direction Data and time stamp Detailed description of status by code and text Location of exception in Intermediate Document Detector of exception by program and user. The statuses for outbound IDocs are between '01' and '49', while the statuses for inbound IDocs begin from '50'. When an IDoc is created, the IDoc Interface sets the status in the function module EDI_DOCUMENT_CLOSE_CREATE. All additional status records are written explicitly by the function module EDI_DOCUMENT_STATUS_SET. It is possible to have Custom Statuses also.
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
The first step in creating a new IDOC is to create all the segments that go into that IDOC. There are some rules that have to be followed while creating the segments: The name of that segment type must start with ‘Z1’ For each field in the segment you have to define a field name, a data element for the segment structure and a data element for the segment documentation. The data element for the segment structure has to be of data type ‘CHAR’ The IDOC tools create overall three structures: Z1nnnnn - field names Z2nnnnn - data elements for structure definition Z3nnnnn - data elements for documentation IDoc type IDoc structure type Receiver port/partner type/partner number Sender port/sender type/sender number
The next step is to create the IDOC type by “assembling” all the necessary segments. Part of our scenario analysis was to define the layout of the IDOC. We should have addressed the following questions: Which segments should be used ? What is the hierarchy of the segments ? Which segments are mandatory and which are optional ? How often may a segment be repeated ? SAP recommends to create the structures as flat as possible. Usually each level of segment hierarchy results in a looping structure in the corresponding program. Therefore it’s easier to deal with flat structures. Conceptually the IDOC type describes the technical structure of the message
Here is how to create a new IDOC type by assembling previously defined segments: Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type Select creation of new basic IDOC type Put segments into the IDOC Segment -> Create Enter segment name Enter attributes (Mandatory/Minimum/Maximum number)
Once the IDOC type is defined a message type has to be created. A message type determines how the data in the IDOC is being processed. This allows to use the same IDOC in different scenarios but process the data differently through different message types. A Message Type is the equivalent of a business document type. It characterizes the data being sent across systems, e.g. MATMAS is a message type for Material Master. Here is how to define a new message type : Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type Go to message type maintenance: Environment -> Message types Table view -> Display -> Change New entries Customer message types should be in the customer name range (starting with Z) Last step of the IDOC creation process is to link the new IDOC type with the new message type. Later in the process the message type will be linked to the outbound and inbound programs. With these configurations it is determined how the IDOC is being processed. The relationship between IDOC type and message type is a 1-to-many relationship. That means an IDOC can be associated with multiple message types thus allowing the IDOC to be processed differently, but a message type refers to exactly one IDOC type. Here is how to link the message type with the IDOC type : Go to the maintenance of IDOC types In the ALE-IMG: Extensions->IDOC types -> Maintain message type for Intermediate structure Choose function “EDI: Message types and assignment to IDOC types” Link your message type with your IDOC type Table view -> Display -> Change New entries Message type : Z…… Basic IDOC type: Z…..
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
The application drives distribution: ALE does not read application tables to build messages, instead the applications have ALE-calls built in. Data consistency is ensured by the database: the application document and the ALE-document (IDOC) are posted in the same LUW (logical unit of work). Hence if one fails to post, both fail. The following slides give more details on output processing.
At the point in an application where an ALE message may need to be sent, the application can query the distribution model to determine whether its message type is in use. The query can also determine the filter objects required by the recipient(s), allowing IDocs to be built containing only the relevant information if need be. The alternative is to build an IDOC containing all the application data and use the ALE recipient determination to remove unwanted data segments.
If the previous query showed that an ALE message is required, the application builds an IDocs an internal table and passes it to the ALE layer via a function call.
If no recipients have been specified by the application, ALE will refer to the distribution model to determine recipients. The recipient determination is data-dependent: segments containing data not specified in the model are removed from the IDOC. For example, if the model states that only information for company code 1000 is to be transmitted, segments containing information for other company codes would be deleted. The ALE distribution model is discussed later.
For each recipient and message type, segments can be removed independent of their contents. This allows transmission costs to be reduced in cases when the receiving system cannot or need not process the filtered segments.
Individual field values can be converted if needed; for example, two-digit plant codes in R/2 would need to be converted to four digit values for R/3. Field conversion should be used sparingly for performance reasons. If many fields need conversion, with many different values, customers should consider using a third party converter. SAP is in contact with a number of manufacturers and is planning to certify those that meet ALE requirements.
The version changer allows systems with different release levels (e.g. 3.0 and 4.0) to communicate with one another. This is technically possible because extensions to messages are restricted to make the version changer work efficiently. The section on intermediate documents (IDocs) deals with this in more detail.
Links needed to be able to keep track of the documents created for the initial application document. The application document is linked to the IDOC, which is in turn linked to the communication layer's transaction ID.
Dispatch control is where technical parameters are maintained: whether to pass the IDocs to the file interface for EDI-subsystems, or to other systems via asynchronous remote function calls. whether IDocs should be sent immediately or cumulated and sent periodically by a batch job; in the latter case the packet size (see later) is determined here.
First step in creating our own ALE scenario is to do a scenario analysis. We have to understand what the data looks like that is going to be exchanged, how we it is being extracted and how it is being processed. We have to consider the following questions: How is the Data Container (IDOC) being structured ? Which data fields have to be transferred ? How many logical groups of data (header vs. line item) do we have ? Do we have hierarchical structures ? Are there any optional or mandatory groups ? How long are the data fields ? When should which data be sent ? How does the triggering work ? Where is the data being extracted from ? What should the receiver to with the data ? Once we have done our analysis we should have a clear understanding about the IDOC structure. Assuming we have designed the layout of our IDOC it is fairly simple and straightforward to define that IDOC in SAP with the so called IDOC definition tools. There are 4 main steps involved in creating the IDOC: Create segments Create IDOC type Create message type Link message type with IDOC type
In implementing an outbound program we have two deals with mainly two issues: Designing the program logic Defining a trigger mechanism for the program The program logic defines how the data gets extracted from the application tables and how the IDOC is being created. The trigger mechanism defines how the interface (and an ALE scenario is nothing else than a SAP-to-SAP interface) gets kicked off. In the following, we will first focus on program logic and than explore different options to trigger the outbound IDOC creation.
The fundamental logic of an outbound IDOC program is fairly simple. It can be subdivided into 3 steps: Select the data from the application tables Fill the data into the IDOC Pass the IDOC to the ALE layer Compared to a traditional interface program the main difference is that the data is selected into the IDOC format and send to the ALE layer as opposed to writing the data out to a flat file. The selection logic itself is the pretty much the same. The entry point into the ALE layer is the function module “MASTER_IDOC_DISTRIBUTE”. All ALE functionality that was introduced earlier (Receiver determination, Segment filtering, Version Control, Dispatch Control) is buried in that function module. That functionality is totally transparent to a programmer - all he is concerned with is to call MASTER_IDOC_DISTRIBUTE with the appropriate parameters.
Let’s have a closer look at the function module “MASTER_IDOC_DISTRIBUTE” Conceptually “MASTER_IDOC_DISTRIBUTE” accepts as a parameter exactly one IDOC. That IDOC is passed in the two structures “master_IDoc_control” and “master_IDoc_data”. “master_IDoc_control” is a one-dimensional data structure (field string) that holds the IDOC control record. We will see shortly the minimal information that needs to go into the IDOC control record. “master_IDoc_data” is a two-dimensional data structure (table), that holds all the data records of the IDOC to be sent out. We will shortly see what information needs to put into the data records of an IDOC. “communication_IDoc_control” is a data structure that returns back additional control record information of the IDOC that was created. The most important information passed back is the IDOC number. This data structure doesn’t have to be filled before “MASTER_IDOC_DISTRIBUTE” is called.
Since the EDIDD structure is used for all different type of IDOCs containing all sorts of Segments, filling the EDIDD structure is a little bit tricky. First you have to fill the 55-byte header with the Segment name. Second the 1000-byte SDATA field needs to be filled. This is a two-step process (similar to a COBOL - redefine construct): First, fill the data into a field string that has the structure of the segment type you want to fill Secondly, move the whole field string into the SDATA field Note: The receiver of the IDOC needs to execute the reverse logic. The SEGNAM information helps to parse out the SDATA field by moving it into a field string that matches the layout of the segment type specified in the SEGNAM field.
There are a couple of general rules that have to be followed when constructing the IDOC program: All fields must be left-justified Currency Amounts must be converted All SAP codes must be converted into ISO codes SAP codes that have to be converted include Currency keys, country Keys, Unit of measure and Shipping instructions.
All fields in the IDOC are defined with a data type of ‘CHAR’. SAP choose that approach to ensure independency of any internal binary representations. All fields have to left-justified. ABAP automatically converts different data types into each other. However, this automatic conversion doesn’t produce the desired left-justification for all data types. SAP requires to convert the all data types with the exception of ‘char’, ‘cuky’, ‘clnt’, ‘accp’, ‘numc’, ‘dats’, ‘tims’ or ‘unit’. The easiest way to left-justify the fields is with the ‘Condense’ statement
SAP decided not to use any SAP specific codes in the IDOC. Instead they recommend to use ISO codes. Note: This decision a relict from the EDI world. In an SAP-to-SAP scenario it doesn't make sense, because the receiver program has to do the conversion back into the SAP code ! As long as the sender and receiver have the same assumptions about the codes, there is no technically reason to do code conversions. SAP delivers a set of function modules to do these conversion: 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’ The Currency Amounts has also be converted with the function module ‘currency_amount_sap_to_idoc’ Note: There is a similar set of function modules to do the conversion in the opposite directions (from ISO to SAP). These function modules have to be used on the receiving side.
The distribution of systems (ALE) makes it necessary to be able to identify every system individually within a network. The "logical system" is used to do this. A logical system is an application system within which the applications are coordinated to work in one database. In the SAP sense of the word, a logical system corresponds to a client.
The Remote Function Call is controlled via the parameters of the RFC destination. The RFC destinations must be maintained in order to create an RFC port. The name of the RFC destination should correspond to the name of the logical system in question. The following types of RFC destinations are maintainable: · R/2 links · R/3 links · internal links · logical destinations · CMC link · SNA/CPI-C connections · TCP/IP links · links of the ABAP/4 drivers
You specify the technical characteristics of the link between the SAP System and the other system in the port definition. The following port types are supported: Asynchronous RFC R/2 System File interface The ALE interface generates ports automatically. The EDI interface assigns numbers internally for these ports. Hence the ports can be identified explicitly. The system can only generate the numbers if a number range is entered for the number range object EDIPORT in number range 01.
Tells the ALE Layer how to send Msg. Between systems. The Partner No. is the logical system name of the other system. The Partner type is ‘LS’ ( logical system) for ALE. The Partner Class is a free text field that classifies Partners.
The Distribution Model is a tool that stores information about the flow of messages across various systems. The model stores data that dictates which messages flow to which logical systems. It Combines logical systems, message types, and filter objects to represent the distribution scenario and is maintained with in the IMG (transaction SALE).In the IMG, the model is maintained from a senders perspective A distribution model is owned and mastered by one logical system and distributed to other logical systems
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like IDOC type (“what data is in the IDOC”) Message type (“how is the IDOC being processed”) Sender information (“who is the sender of that IDOC”) Receiver information (“who is the receiver of that IDOC”) Latest status of EDI processing. EDI standard and version. The only two mandatory fields that must be filled are the Message type (MESTYP) and IDOC type (IDOCTP) Note that you have to use uppercase literals when you fill the two fields The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”) The receiver information is optional: If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created. If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
A filter object type is used in the Customer Distribution Model to impose a selection criterion on the message type flowing to a logical system. A filter object type with a value associated with it is called a filter object . A Filter Object Type is used in the Customer Distribution Model to impose a selection criterion on the message (type) flowing to a logical system A Filter Object is a Filter Object Type with a value associated with it, e.g. BUKRS (company code) is a filter object type available for message type DEBMAS (Customer Master). A filter object with value BUKRS = 1001 will allow distribution of Customer Master data for Company Code ‘1001’ only for that specific Logical System
For master data the decision what trigger mechanism to use is mainly a question if there is a requirement to send out only data objects that have been changed since the last time the object has been sent or not (e.g. only send materials that have been added/changed since the last run). If only changed objects should be send out, then change pointers are a natural way of triggering if they exist. Typically a change pointer exists whenever a change document exists. However there are certain exceptions (e.g. Classification writes change pointers but no change documents). If no change pointers exists than a standalone program is the solution. The program needs to keep track of all the changes since the last run (e.g. in a custom table w/ date/timestamp and key to data object). If there is no need to send out changed objects than a standalone program similar to the exercise (and RBDMSEMAT) is sufficient. Typically there is a need to specify the the objects to be sent out (e.g. Selection screen with Material number from/to)
For transactional data the main criteria to pick a solution is to decide if transactional integrity is a requirement. If so, than data has to be posted within the same LUW as the application document and non- or double-processing of IDocs has to be avoided. That leaves only the options of hard coding the ALE logic or using output determination. In the case of hardcode calls to the ALE layer the existence of a user-exit determines if this scenario can be implemented within the enhancement concept of SAP (No Modification vs. Modification). However, there is not always a need for transactional integrity. For example in SAP-to-Legacy scenarios one could decide to implement an interface in a less restrictive way (since the legacy system can typically not ensure transactional integrity anyway). An example could be an interface were all open orders are extracted in IDOC format from SAP and send to legacy. For those kind of solutions the same trigger mechanism than for master data can be used.
Change Pointers is a technique that was specifically developed to support master data distribution for changed data only. Change Pointers are (usually) based on change documents. Change documents (table CDHDR, CDPOS) are documents that are written to provide an audit trail about changes made to certain data (old value, new value, person who made the change etc.). While change documents keep track of all the changes made in the system, the change pointers are temporary in a sense that they have a status associated with them that keeps track if the change has already been processed or not. The change pointers therefore give a clear picture what changes need to be sent out. Change Pointer based IDOCs are usually generated with a batch job (RBDMIDOC) RBDMIDOC determines and calls a message type-specific function module that loops over the open change pointers and generates an IDOC for each of them.
Change Pointers are R/3 objects that mark changes to SAP Master data. Change Pointers are managed by mechanisms in a SMD tool and are based on Change Document Objects. CD objects record the changes in table CDHDR & CDPOS. Internal mechanisms update table BDCP & BDCPS, which host the change pointer. In case there are any changes to the data by running transaction BD21for the particular message type we can pick up the changed materials for that particular message type. Activate change pointers for message type or generally.
There are three major pieces of configuration necessary for a change pointer-based outbound scenario: Change Pointer creation definition Change Pointer activation Function module related configuration Change Pointer creation: IMG: Extensions -> Master data distribution -> Activate change pointer per change document item With this configuration you define which change document element are relevant for creating a change pointer Change Pointer activation: This configuration is not any different from any of the existing change pointer-based ALE scenarios. There are two steps involved: Activate change-pointers generally Activate change-pointers per message type Function module related configuration: IMG: Extensions -> Master data distribution -> Set up additional data for message type This configuration is necessary to “publish” new function module to RBDMIDOC. It ties the message type to the function module.
The first part of input processing mirrors output processing, with version change, segment filter and field value conversion. The IDOC is first written to the database, with a link to the IDOC in the sending system, and then input control takes over: the type of input is determined (function module, workflow, workitem) the input timing is determined (immediate or cumulated and processed in batch) who should be informed in case of error If serialization is necessary, the application posting function can call an ALE-API (function module) to determine whether the IDOC has been overtaken (explained later). IDOC processing is complete when an application document is created or changed; to signal this, a success status record is added to the IDOC in the same LUW (logical unit of work) as that in which the application document is processed. The only exception to the above is the with ORDERS and ORDCHG, where a call transaction is first called and then the status is updated.
On the inbound side there are 3 major elements that need to be developed to finalize a custom ALE scenario: Inbound function module: The function module is responsible for processing the IDOC and creating an application document from the IDOC data. The function module is called by the ALE layer and has to return back information about the success of the document posting. ALE configuration: The ALE layer has to have knowledge which function module to call for a certain message type / IDOC type. These assignments are made through ALE configuration Workflow task: ALE error handling is done via workflow. A workflow task has to be defined that can be executed for the case that the application document posting in the function module was not successful. The ALE layer gets the information about the success of the posting passed from the inbound function module. The workflow takes is started by the ALE layer. Here is a more detailed look at these 3 components and how they interact. INBOUND_IDOC_PROCESS is the generic entry point for all inbound IDOC processing. This function module is called by the sending SAP systems and gets one or more IDocs passed as parameter. All the ALE layer functionality that we learned about previously (Version change, segment filtering, field conversions) are handled in that function module. INBOUND_IDOC_PROCESS takes information out of the control record of the IDOC to access the partner profile. Part of the partner profile is a process code that is tied to an inbound IDOC function module. This function module is then being called. The SAP naming convention for an inbound function module is IDOC_INPUT_<MSGTYPE>. Since we have to stay within the customer name space, a custom inbound module typically is called Z_IDOC_INPUT_<MSGTYPE>. The inbound function module reads the rest of IDOC data and posts the application document. It returns status information back to the ALE layer about the success of that posting. Depending on the return information of the inbound function module, the ALE layer (INBOUND_IDOC_PROCESS) triggers a workflow task to initiate error handling. The information which task to start is part of the ALE configuration.
Here is a example scenario for Material master Error handling: Inbound function module tells ALE layer that an error has occurred ALE triggers object’s (I.e. IDOCMATMAS) event ‘inputErrorOccured’ Object’s event is linked with standard task (I.e 0007946: MATAMAS_Error) Work item appears in user’s inbox When user executes work item, object’s method ‘InputForeground’ is executed When IDOC was successfully processed, object’s event ‘inputFinished’ is triggered, which completes work item.
Unfortunately there is not enough time in this class to cover more of workflow. Please refer to the workflow class and the ALE programmers guide. Here is a summary of the necessary steps to enable IDOC error handling: Create a new Business Object for IDOC as child of IDOCAPPL Create new customer task Create event-couplings linking InputErrorOccured to standard task InputFinished to function module Update Process Code to refer to the above mentioned objects and events To support mass processing: Create new object type as child of IDOCPACKET
There are a number of issues you have to keep in mind when developing inbound IDOC programs. We will briefly discuss four of them. For a more detailed description please refer to the ALE programmers guide.
On the outbound side, we discussed the problem of transactional integrity (for transaction data). We noted, that the IDOC has to be created within the same LUW than the application document. Both together make up the successful transaction. The similar concept applies to the inbound side. It is imperative to ensure that an incoming IDOC only gets processed once and that in the case of a rollback both the IDOC and the application document are backed out. The key is to update the IDOC status record (which indicates that the IDOC has been processed) and the application document within the same LUW. Since the application document gets posted by the IDOC function module and the status records get updated by the ALE layer (INBOUND_IDOC_PROCESS), NO Commit work should be issued by the IDOC function module. This constraint doesn’t doesn’t apply to master data since a second posting would not lead to duplicate documents.
This slide depicts the interaction between the ALE layer and the IDOC function module in more detail. Note, that the application document is posted by the function module whereas the IDOC status records are updated by the ALE layer. To make both updates part of one LUW, the IDOC function module should NOT issue a Commit Work !
For some IDOC types it might be a problem if one IDOC is overtaken by another IDOC, because later updates would be overwritten by earlier ones. Since this is dependent on the IDOC type this serialization function is not build in to the ALE layer. It needs to be coded within the application function module.
SAP delivers a function module (IDOC_SERIALIZATION_CHECK) that detects overtaken function modules. Prerequisite for using that function module is the definition of a serialization object. Note, that there is no automatic handling of serialization errors. All you can do is to feed back an error status to the ALE layer and then kick of a workflow task to deal with that error.
Instead of processing one IDOC at a time it is possible to run in “mass processing mode”. In this mode the IDOC function module receives a number of IDOCs as input parameter and it processes them with one Commit Work. This can have performance benefits. The inbound function module has to be coded so that it can handle multiple IDOCs and the attributes of the function module in the ALE configuration has to be set to mass processing. For examples on how to program ‘mass processing’ function modules please refer to the ALE programmers guide.
The easiest way to write Inbound function modules is to use a ‘Call Transaction’ statement to create an application document out of the IDOC data. This is easy to program and the programmer doesn’t need knowledge about the underlying data structures. Another benefit is the ability to process error IDOCs in foreground, which actually runs the transaction in foreground, allowing the user to step through the screens of the transactions. However there are two big drawbacks in using call transactions within IDOC function modules: Call transaction is slow Call transactions issue an implicit COMMIT WORK. Therefore data consistency can not be guaranteed !! SAP recommends not to use Call Transactions because of the data consistency problems. They require a transaction to be ALE-enabled instead. However, there are a number of delivered IDOC function modules that use non-ALE-enabled transactions. Bottom line: Use a function modules to post your documents, if possible. Use can use Call Transaction, if transaction is ALE-enabled If Transaction is not ALE-enabled, you use it at your own risk For master data, data consistency is not that big of an issue