Overview of ALE / EDI / IDOCs

Overview of ALE / EDI / IDOCs
11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

EDI What is EDI? Type of EDI process Outbound EDI Process
Inbound EDI Process 11/7/2018 Overview of ALE/IDOCs

What is EDI? EDI is electronic exchange of business documents between the computer systems of business partner using a standard format over a communication network EDI is also called a paperless exchange. 11/7/2018 Overview of ALE/IDOCs

Typical EDI/IDOC Scenario
11/7/2018 Overview of ALE/IDOCs

Outbound Process With Message Control
Directly -With out Message Control 11/7/2018 Overview of ALE/IDOCs

Inbound Process With Function Module 11/7/2018 Overview of ALE/IDOCs

EDI Configuration How to Set Up an RFC Destination in SAP
The Port Definitions Configure Partner Profile Configure Message Control 11/7/2018 Overview of ALE/IDOCs

Complete EDI/ ALE scenario

ALE What is ALE? Components of ALE. Anatomy of an IDoc. ALE Processing
Transactions For Monitoring and Processing IDocs. Questions 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

ALE Terminology ALE - Application Linking & Enabling
IDoc - Intermediate Document EDI Electronic Data Interchange 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

ALE Objective 11/7/2018 Overview of ALE/IDOCs
© Copyright IBM Corporation 2004

ALE!! What is it ?? It is a set of
Tools, programs and data definitions Provides distribution model and technology that enables SAP Customer to interconnect programs across various platforms and systems. 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. 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

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 11/7/2018 Overview of ALE/IDOCs

ALE Scenario SAP System R/3 EDI Subsystem Document IDoc 11/7/2018
Overview of ALE/IDOCs

Topics to cover What is ALE ? Components of ALE. Anatomy of an IDoc.
ALE Processing Transactions For Monitoring and Processing IDocs. Trouble Shooting Questions 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Components of ALE Services: Application Services Distribution Services
Communication Services 11/7/2018 Overview of ALE/IDOCs

Application Services Services: Application Services Distribution Services Communication Services This is where the SAP applications ( SD, FI, MM etc. ) generate their data and documents 11/7/2018 Overview of ALE/IDOCs

Distribution Services
Application Services Distribution Services Communication Services Recipients Formats and Filters the data Creates IDocs ( Intermediate Documents 11/7/2018 Overview of ALE/IDOCs

Communication Services
Application Services Distribution Services Communication Services TCP/IP RFC tRFC etc 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

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 11/7/2018 Overview of ALE/IDOCs

ALE Processing Transactions For Monitoring and Processing IDocs. Trouble Shooting Questions 11/7/2018 Overview of ALE/IDOCs © 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 11/7/2018 Overview of ALE/IDOCs © 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 11/7/2018 Overview of ALE/IDOCs © 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 11/7/2018 Overview of ALE/IDOCs © 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 ! 11/7/2018 Overview of ALE/IDOCs © 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 ! 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Data Record 11/7/2018 Overview of ALE/IDOCs
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. 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 11/7/2018 Overview of ALE/IDOCs © 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. 11/7/2018 Overview of ALE/IDOCs © 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'. 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 ! 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Idoc Segments TCODE: WE31 11/7/2018 Overview of ALE/IDOCs
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 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Idoc Types TCODE: WE30 11/7/2018 Overview of ALE/IDOCs
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 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

How to Attach Segments 11/7/2018 Overview of ALE/IDOCs
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) 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Message Types WE81 WE82 11/7/2018 Overview of ALE/IDOCs
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….. 11/7/2018 Overview of ALE/IDOCs © 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 ! 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

ALE Processing. i.Outbound Processing ii.Inbound Processing Transactions For Monitoring and Processing IDocs. Trouble Shooting Questions 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Outbound Processing 11/7/2018 Overview of ALE/IDOCs

Outbound processing: direct
Application posting ALE layer Comm. layer Comm. layer Customer Distribution Model Need to create IDOC? asynch. RFC or EDI System call FM ( INBOUND_ IDOC_ PROCESS ) On destination 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 11/7/2018 Overview of ALE/IDOCs © 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 11/7/2018 Overview of ALE/IDOCs © 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 11/7/2018 Overview of ALE/IDOCs © 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. 11/7/2018 Overview of ALE/IDOCs © 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 11/7/2018 Overview of ALE/IDOCs © 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. 11/7/2018 Overview of ALE/IDOCs © 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. 11/7/2018 Overview of ALE/IDOCs © 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. 11/7/2018 Overview of ALE/IDOCs © 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 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

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. 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Basic Configuration Elements
Define RFC Destinations Define Ports Maintain Customer Model Create Partner Profiles 11/7/2018 Overview of ALE/IDOCs

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 11/7/2018 Overview of ALE/IDOCs © 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. 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Partner Profiles TCODE: WE20 11/7/2018 Overview of ALE/IDOCs
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. 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Partner Profiles-Inbound

Partner Profiles-Outbound

ALE For Transactional data ---- Output Determination
NACE 11/7/2018 Overview of ALE/IDOCs

Output Determination -- Output Types

Output Types -- Details

Inbound Processing 11/7/2018 Overview of ALE/IDOCs

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 11/7/2018 Overview of ALE/IDOCs © 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 11/7/2018 Overview of ALE/IDOCs

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 11/7/2018 Overview of ALE/IDOCs

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 11/7/2018 Overview of ALE/IDOCs

FM Assignment to Message Type and IDoc type
TCODE: WE57 11/7/2018 Overview of ALE/IDOCs

Process Codes WE41 WE42 11/7/2018 Overview of ALE/IDOCs

FM For Inbound EDI TCODE: BD67 11/7/2018 Overview of ALE/IDOCs

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 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

Basic Scenario Direct Method Call Transaction Method 11/7/2018
Overview of ALE/IDOCs

Advanced Scenario Mass processing Serialization Advanced Workflow

Flow Of Program Read IDOC-Lock IDOC-Call Inbound Program-Write Status-Commit Work-Unlock IDOC 11/7/2018 Overview of ALE/IDOCs

Interface of Inbound FM
Importing Parameter -Input Method -Mass_processing EXPORT parameter . -Workflow_result -Application_variable -In_Update_task -Call_transaction_done Tables parameter : IDOC_Control IDOC_DATA IDOC_STATUS Return_variable 11/7/2018 Overview of ALE/IDOCs

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. 11/7/2018 Overview of ALE/IDOCs © Copyright IBM Corporation 2004

List Of All IDocs Created. (Default, Additional, EDI)-- WE02/ WE05

Selection Program For Issuing Output -- WE15

Test Tool For Idoc Processing (WE19)

Idoc Search For Business Contents (Database). WE09

Overview of ALE / EDI / IDOCs

Similar presentations

Presentation on theme: "Overview of ALE / EDI / IDOCs"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Overview of ALE / EDI / IDOCs

Similar presentations

Presentation on theme: "Overview of ALE / EDI / IDOCs"— Presentation transcript:

Similar presentations

About project

Feedback