Overview of ALE / IDOCs March, 2006 © Copyright IBM Corporation 2004

Topics to cover What is ALE? Components of ALE. Anatomy of an IDoc. ALE Processing Transactions For Monitoring and Processing IDocs. Questions ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

ALE Terminology ALE - Application Linking & Enabling IDoc - Intermediate Document EDI - Electronic Data Interchange ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

ALE Objective © Copyright IBM Corporation 2004 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

ALE!! What is it ?? It is a set of Tools, programs and data definitions that provides the mechanism for distributing functionality and data across multiple system. 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

What Data can be Exchanged ? Transaction Data SD, MM, FI, CO, etc. Master Data Material, Customer, Vendor, etc. Control Data Organizational Reference Information Plants, Sales Orgs, etc. Data required to enable tightly coupled, distributed applications Separate HR, Separate Treasury, etc. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Features –ALE / IDocs Distributed System yet integrated with SAP R/3 Based on ‘Application-to-Application integration using ‘Message Architecture’ Reliable communication Data is exchanged using “IDocs” Support both R/2, R/3 and External system If network problem, message is buffered ALE support backward compatibility ALE ensure that , data is transferred only once ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

ALE Scenario SAP System R/3 EDI Subsystem Document IDoc ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Topics to cover What is ALE ? Components of ALE. Anatomy of an IDoc. ALE Processing Transactions For Monitoring and Processing IDocs. Trouble Shooting Questions ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Components of ALE Services: Application Services Distribution Services Communication Services Tools: Customizing Tools Development Tools ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Application Services Services: Application Services Distribution Services Communication Services Tools: Customizing Tools Development Tools This is where the SAP applications ( SD, FI, MM etc. ) generate their data and documents ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Distribution Services Application Services Distribution Services Communication Services Tools: Customizing Tools Development Tools Recipients Formats and Filters the data Creates IDocs ( Intermediate Documents ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Communication Services Application Services Distribution Services Communication Services Tools: Customizing Tools Development Tools TCP/IP RFC tRFC etc ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

(for configuring the flow of data Model Maintenance Tool. (for configuring the flow of data between systems ) Shared Master Data(SMD)tools (for distributing master data ) Customization parameters (within SAP for IDoc filtering and conversion. ) Development Tools Services: Application Services Distribution Services Communication Services Tools: Customizing Tools Development Tools ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Tools for creating and modifying IDocs Customizing Tools Services: Application Services Distribution Services Communication Services Tools: Customizing Tools Development Tools Tools for creating and modifying IDocs ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Distribution/ ALE Layer In a Nut Shell Application Layer Distribution/ ALE Layer Communication Layer Master IDOC Application Determine Receipients Filter/Convert Data, Create IDOC Comm. IDOC Carrier Application Data Comm. IDOC Application Functions Filter/Convert Data ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Topics to cover What is ALE ? Components of ALE. Anatomy of an IDoc. ALE Processing Transactions For Monitoring and Processing IDocs. Trouble Shooting Questions ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

IDoc Concept R/3 System System 1 EDI subsystem R/2 System SAP Document EDI subsystem R/2 System 3rd party software System 2 IDoc ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

IDoc Structure Control Record Data Record Status Record IDoc-ID Status information Data Record IDoc-ID Sequence/Hierarchy Segment Format definition for header data item data Control Record IDoc-ID Sender-ID Receiver-ID IDoc type and logical message External structure ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

“Intermediate Document” Control record Data Record Status Record IDOC “Intermediate Document” 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Control Record The very first record of an IDoc package is always a control record. The structure of this control record of the structure EDIDC and describes the contents of the data contained in the package. The control record goes to table EDIDC 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 ! ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Message Type Message Type indicates How to Know what the data Means Data Exchanged by IDOC and EDI is known as Messages Message of same kind belong to the same message type Message types are stored in table EDMSG 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 ! ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

All records in the IDoc, which come after the control record, are the IDoc data. They are all structured alike, with a segment information part and a data part, which is 1000 character in length, filling the rest of the line. Data & Segment info is stored in EDID4 for release 4.x and EDID3 for release 2.x and 3.x. Data Record 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Status Record Information about the IDoc status like: IDoc identification number Status number - table verified IDoc type Direction Data and time stamp; Structure: EDIDS Status Record 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Status of IDOC A two-digit status is assigned to an IDoc to allow the processing to be monitored. The statuses for outbound IDocs are between '01' and '49', while the statuses for inbound IDocs begin with '50'. Status confirmation when using port type 'File': The external system writes the status records in a status file, which is read by the R/3 System. In this case, the confirmation always refers to outbound IDocs. Status confirmation using IDoc type SYSTAT01: The system sending the confirmation writes the status records as data records of IDoc type SYSTAT01. All port types and both directions can be entered. 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 ! ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Idoc Segments TCODE: WE31 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Idoc Types TCODE: WE30 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

How to Attach Segments 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) ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Message Types WE81 WE82  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 : 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 Message type : Z…… Basic IDOC type: Z….. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

IDOC Type/ Message Type/ Processing Function Module Valid combination of Message type and IDOC type are stored in table EDIMSG Combination of message type and IDOC type determine the processing algorithm. This is usually a function module and is set up in table EDIFCT. 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 ! ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Topics to cover What is ALE ? Components of ALE. Anatomy of an IDoc. ALE Processing. i.Outbound Processing ii.Inbound Processing Transactions For Monitoring and Processing IDocs. Trouble Shooting Questions ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Outbound Processing ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Outbound processing: direct Application posting ALE layer Comm. layer Comm. layer Customer Distribution Model Need to create IDOC? asynch. RFC or EDI Create master IDOC M Receiver determination Segment filter Field value conversion Application document posted simultaneously with IDOCs Version change C 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. Dispatch control C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Customer Distribution Model Querying the Model Application posting ALE layer Comm. layer Comm. layer Customer Distribution Model Need to create IDOC? ALE supplies APIs (function modules) to allow applications to query the model Is anybody interested in my message type? Optional: what filter objects are they interested in? asynch. RFC or EDI Create master IDOC M Receiver determination asynch. RFC or EDI Segment filter Field value conversion Application document posted simultaneously with IDocs Version change C 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. Dispatch control C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Customer Distribution Model Handover IDoc to ALE Application posting ALE layer Comm. layer Customer Distribution Model Need to create IDOC? The application creates the IDOC Technically it is stored as an internal table Passed to ALE via an API (function module) asynch. RFC or EDI Create master IDOC M Receiver determination Segment filter Field value conversion Application document posted simultaneously with IDocs Version change C 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. Dispatch control C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Receiver determination Application posting ALE layer Comm. layer Customer Distribution Model Need to create IDOC? If the application has no specified recipients ALE refers to the customer distribution model to determine them Data not relevant to receiver (according to model) is removed in ALE layer. asynch. RFC or EDI Create master IDOC M Receiver determination asynch. RFC or EDI Segment filter Field value conversion Application document posted simultaneously with IDocs Version change C 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. Dispatch control C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Customer Distribution Model Segment filter Application posting ALE layer Comm. layer Customer Distribution Model Need to create IDOC? asynch. RFC or EDI The filter is data-independent IDOC segments that are not required can be removed The filter is message and receiver-specific Create master IDOC M Receiver determination asynch. RFC or EDI Segment filter Field value conversion Application document posted simultaneously with IDocs Version change C 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. Dispatch control C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Field value conversion Application posting ALE layer Comm. layer Customer Distribution Model Need to create IDOC? asynch. RFC or EDI The contents of individual fields can be translated to new values suppressed The filter is message and receiver-specific Create master IDOC M Receiver determination asynch. RFC or EDI Segment filter Field value conversion Application document posted simultaneously with IDocs Version change C 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. Dispatch control C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Customer Distribution Model Version change Application posting ALE layer Comm. layer Comm. layer Customer Distribution Model Need to create IDOC? asynch. RFC or EDI Create master IDOC M Receiver determination asynch. RFC or EDI IDOCs can be changed to older versions Systems with different release levels can communicate without additional application logic Segment filter Field value conversion Application document posted simultaneously with IDocs Version change C 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. Dispatch control C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Customer Distribution Model Make Links Application posting ALE layer Comm. layer Customer Distribution Model Need to create IDOC? asynch. RFC or EDI Create master IDOC M Receiver determination Segment filter Field value conversion Links are written between IDOC and Application object contained in IDOC Communication-Layer's "Transaction-ID" Application document posted simultaneously with IDocs Version change C 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 C C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Customer Distribution Model Dispatch control Application posting ALE layer Comm. layer Customer Distribution Model Need to create IDOC? asynch. RFC or EDI Create master IDOC M Receiver determination asynch. RFC or EDI Technical comms parameters are defined EDI or aRFC (asynch. remote function call) Send immediately or cumulate and send via batch job If batch, packet size is determined Segment filter Field value conversion Application document posted simultaneously with IDocs Version change C 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. Dispatch control C C Links Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Scenario analysis How does the IDOC look like ? How is data being sent ? How is the data being received ? 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Outbound program development Program logic “How is the IDOC being created ?” Triggering “How is the IDOC creation kicked off ?” 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Program logic IDOC program Select data from application tables Fill data into IDOC Pass IDOC to ALE layer (Call function MASTER_IDOC_DISTRIBUTE) Commit Work MASTER_IDOC_DISTRIBUTE Receiver determination Segment filtering Version Control Dispatch Control 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. ALE layer ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

MASTER_IDOC_DISTRIBUTE Call function ‘MASTER_IDOC_DISTRIBUTE’ Exporting master_idoc_control: IDOC control record Tables communication_idoc_control: returned information about the distribution master_idoc_data: IDOC data segments 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Filling an EDIDD structure Header (55bytes) SDATA (1000bytes) …. SEGNAM …. EDIDD Z1SEG Field1 Field2 Field3 Field4 “10” “ABC” MOVE “Z1SEG” to EDIDD-SEGNAM MOVE “10” to Z1SEG-FIELD1 MOVE “ABC” to Z1SEG-FIELD2 MOVE Z1SEG to EDIDD-SDATA 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

General Programming rules Design Guidelines for creating IDOC data records: Left-justified filing of IDOC Fields Replacing SAP codes with ISO codes currency keys country keys unit of measure shipping instructions Converting Currency Amounts 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Left-justified Filling All fields must be left-justified Character fields: automatic Non-character fields: ‘Condense’ statement must be used Check IDOC documentation to find out which fields require a ‘condense’ All types unequal to ‘char’, ‘cuky’, ‘clnt’, ‘accp’, ‘numc’, ‘dats’, ‘tims’ or ‘unit’ require a condense 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Replacing SAP codes with ISO codes Code Conversions Replacing SAP codes with ISO codes 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_iso_package_type_code’ Conversion of currency amounts ‘currency_amount_sap_to_iso’ 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Basic Configuration Elements Create and allocate Logical System Define Ranges (Idocs, Ports, etc ) Define RFC Destinations Define Ports Maintain Customer Model Create Partner Profiles ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Logical System TCODE: BD54; Stored in table T000  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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Allocate Logical System to the client TCODE: SCC4 SALE > BASIC SETTINGS > SET UP LOGICAL SYSTEM > ASSIGN LOGICAL SYSTEM TO THE CLIENT ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Number Ranges Maintain number ranges for ports Maintain number ranges for IDocs Maintain number ranges for IDoc types and segment version Maintain number range for change pointers ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Maintaining RFC Destinations TCODE: SM59 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Displaying and Maintaining Ports TCODE: WE21 A port is a logical representation of a communication channel in SAP with the data communicated being IDocs.   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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Partner Profiles TCODE: WE20  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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Partner Profiles-Outbound ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Partner Profiles-Inbound ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Distribution Model TCODE: BD64   TCODE: BD64  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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Transfer of data Transfer master data for material, customer, vendor to different client or system with BALE 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 ! ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Filter Objects BD95 BD59   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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Sending Master Data Idocs Only send objects that have changed ? Change Pointer available? Master data ? Standalone with custom logic to keep track of changes Change Pointer based Program y N Y Standalone program with user-definable selection criteria 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) ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Sending Transactional Data Idocs Y Ensure trans- actional Integrity? N See Master data Y Output Determination available ? User-Exit available? N hard coded ALE layer Modification N y Y 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. Output determination based Program Hardcoded ALE layer no Modification ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Change Pointers Application Posting Batch Program ALE configuration (RBDMIDOC) Master data Post Application document Create Change Document Are changes ALE relevant ? Write Change Pointers Commit Work Determine IDOC module Call IDOC module ALE configuration ALE relevant Fields IDOC Module (Masteridoc_Create_ SMD_<MSGTYPE>) Read Change Pointers Fill IDOC Call ALE layer Update Change Pointer Change pointers 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. ALE layer Master_IDOC_DISTRIBUTE ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

CD objects record the changes in table CDHDR & CDPOS. Change Pointers BD61 BD50  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.    ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Change Pointers… Continued BD52 BD60   ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

IDOC module IDOC module has to be implemented as function module Naming Convention: MASTERIDOC_CREATE_SMD_<msgtype> Function module reads change pointers information to get data that needs to go into IDOC Function module logic: Read change pointers Fill IDOC structure Call ALE layer Update Change Pointer status Commit Work ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

ALE Configuration For Change Pointers Define change pointer creation Define which change document fields are to be logged Change pointer activation Activate generally Activate per message type “Publish” new function module Link message type to function module 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

ALE For Transactional data ---- Output Determination NACE ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Output Determination -- Access Sequence ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Output Determination -- Output Types ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Output Types -- Details ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Output Types -- Partner Functions ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Output Types -- Processing Routines ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Output Types -- Procedures ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Output Types -- Procedures Control ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Output Types -- Condition records ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Inbound Processing ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Inbound Processing. Comm. layer asynch. RFC or EDI ALE layer Application posting C Version change Segment filter Field value conversion Input control A A Serialization Process IDOC Simultaneously update IDOC's status 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. Post application document Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Input Control Comm. layer asynch. RFC or EDI ALE layer Application posting C Version change For each message type and sender one can define when to process (immediate/batch) whether to call application directly or start customer workflow who should get work items in case of error Incoming IDOC packets are passed to application Segment filter Field value conversion Input control A A Serialization Process IDOC Simultaneously update IDOC's status Post application document Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Application Input Comm. layer asynch. RFC or EDI ALE layer Application posting C Version change Segment filter Field value conversion Inbound IDOCs are passed to the application via a standardized function interface Input control A A Serialization Process IDOC Simultaneously update IDOC's status Post application document Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Serialization Comm. layer asynch. RFC or EDI ALE layer Application posting C Version change When processing the inbound IDOC, the application can call an ALE API (function module) to check that the IDOC has not been overtaken If change No. 1 arrives after change No. 2, the IDOC containing it has been overtaken (by the IDOC containing the later change) Segment filter Field value conversion Input control A A Serialization Process IDOC Simultaneously update IDOC's status Post application document Database ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

FM Assignment to Message Type and IDoc type TCODE: WE57 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Process Codes WE41 WE42 © Copyright IBM Corporation 2004   ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Process Codes in Inbound and Outbound TCODE: WE64   ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

FM For Inbound EDI TCODE: BD67 © Copyright IBM Corporation 2004   ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Inbound Program Development ALE configuration Partner Profiles Process Code Function module attribute Function module registry IDOC INBOUND_IDOC_PROCESS Version change Segment filter Field conversion Call function IDOC_INPUT_<MSGTYPE> Read IDOC data Post Application data Send Success info back to ALE layer Return Variables If ERROR, trigger Workflow Task 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. ALE layer ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

ALE error handling 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

ALE error handling Necessary Steps: Create new object type in Business Object Repository for IDOC; object is child of IDOCAPPL Create new customer task Create event-couplings linking Event ‘inputErrorOccured’ linked to standard task Event ‘inputFinished’ to function module To support mass processing: Create new object type as child of IDOCPACKET Maintain process code to refer the above objects and events 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Advanced Inbound Topics Data consistency Serialization Individual vs. mass processing Call transaction function modules 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Data Consistency Problem: Ensure transactional integrity Don’t process and IDOC twice Allow for IDOC reprocessing after rollback of application document posting Solution: Application document must be posted in the same LUW as the IDOC status records IDOC function module must not use a ‘Commit Work’ 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Data Consistency 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 ! ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Serialization Receiver Comm. Layer Sender 1 2 Object X, changed twice: First IDOC overtaken Comm. Layer Sender !? Input from IDOC 1 must be prevented in order not to lose information from IDOC 2 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Check, if IDOC has been overtaken Serialization Check, if IDOC has been overtaken Use function module ‘IDOC_SERIALIZATION_CHECK’ react to overtaken IDOCs according to your needs Prerequisite is the definition of a serialization object 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Processing more than one IDOC can improve throughput: Mass Processing Processing more than one IDOC can improve throughput: more than one IDOC is processed per Commit Work the function can be coded to add multiple entries to a table with one update command (‘array insert’) Function module has to be coded in a way that it supports mass processing Attribute of delivered function module specifies if mass processing is supported or not 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. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Call Transaction Pros: Cons: Recommendation: Error reprocessing in foreground Easy to program Cons: Call Transaction has significant performance overhead Automatic Commit work, no data consistency Recommendation: Try to use function modules that update database directly If you want to use ‘Call transaction’, they have been ‘ALE-enabled’ to guarantee data concistency 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 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Topics to cover What is ALE ? Components of ALE. Anatomy of an IDoc. ALE Processing Transactions For Monitoring and Processing IDocs. Questions ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

Monitoring IDocs The IDoc interface offers 2 different approaches for tracking of data load and data flow: Reports for monitoring Workflow for notifications Both approaches are based on the concept of status transitions, i.e. an IDoc changes its status from a given value to another value. ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

List Of All IDocs Created. (Default, Additional, EDI)-- WE02/ WE05 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Selection Program For Issuing Output -- WE15 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Process All Selected IDocs. WE14 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Test Tool For Idoc Processing (WE19) ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Select IDocs BD87 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Idoc Search For Business Contents (Database). WE09 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Status Conversion With Trfc Execution. BD75 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018

Questions © Copyright IBM Corporation 2004 ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018 © Copyright IBM Corporation 2004

ABAP | Confidential | ALE For ABAPers .ppt | 9/18/2018