ALE IDOC

*Overview of ALE/IDOCs*Overview of ALE / EDI / IDOCs

Overview of ALE/IDOCs

Overview of ALE/IDOCs**EDI What is EDI?Type of EDI process Outbound EDI Process Inbound EDI Process


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.


Overview of ALE/IDOCs**Typical EDI/IDOC Scenario


Overview of ALE/IDOCs**Outbound ProcessWith Message ControlDirectly -With out Message Control


Overview of ALE/IDOCs**Inbound ProcessWith Function Module


Overview of ALE/IDOCs**EDI ConfigurationHow to Set Up an RFC Destination in SAPThe Port DefinitionsConfigure Partner ProfileConfigure Message Control


Overview of ALE/IDOCs**Complete EDI/ ALE scenario


Overview of ALE/IDOCs**ALE What is ALE? Components of ALE. Anatomy of an IDoc. ALE Processing Transactions For Monitoring and Processing IDocs. Questions


Overview of ALE/IDOCs**ALE TerminologyALE - Application Linking & Enabling

IDoc - Intermediate Document

EDI - Electronic Data Interchange


Overview of ALE/IDOCs**ALE Objective


Overview of ALE/IDOCs** 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.


Overview of ALE/IDOCs**

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


Overview of ALE/IDOCs**ALE Scenario


Overview of ALE/IDOCs** What is ALE ? Components of ALE. Anatomy of an IDoc. ALE Processing Transactions For Monitoring and Processing IDocs. Trouble Shooting Questions

Topics to cover


Overview of ALE/IDOCs**Components of ALE Services: Application Services Distribution Services Communication Services


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


Overview of ALE/IDOCs**Distribution ServicesServices: Application Services Distribution Services Communication Services

Recipients Formats and Filters the data Creates IDocs ( Intermediate Documents


Overview of ALE/IDOCs**Communication Services

Services: Application Services Distribution Services Communication Services

TCP/IPRFCtRFC etc


Overview of ALE/IDOCs**DetermineReceipientsFilter/ConvertData, Create IDOCApplication FunctionsFilter/ConvertDataCarrierApplication LayerDistribution/ ALE LayerCommunication LayerApplicationIn a Nut Shell


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


Overview of ALE/IDOCs**IDoc Concept


Overview of ALE/IDOCs**IDoc Structure


Overview of ALE/IDOCs**Control recordData RecordStatus RecordIDOC Intermediate Document


Overview of ALE/IDOCs** The very first record of an IDoc package is always a control record. Thestructure 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

Control Record


Overview of ALE/IDOCs**Message Type

Message Type indicates How to Know what the data MeansData Exchanged by IDOC and EDI is known as MessagesMessage of same kind belong to the same message type.Message types are stored in table EDMSG


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.Data Record


Overview of ALE/IDOCs**Status Record

Information about the IDoc status like:IDoc identification numberStatus number - table verifiedIDoc typeDirectionData and time stamp; Structure: EDIDS


Overview of ALE/IDOCs**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'.


Overview of ALE/IDOCs**Idoc SegmentsTCODE:WE31


Overview of ALE/IDOCs**Idoc TypesTCODE:WE30


Overview of ALE/IDOCs**How to Attach Segments


Overview of ALE/IDOCs**Message TypesWE81WE82


Overview of ALE/IDOCs**IDOC Type/ Message Type/ Processing Function Module

Valid combination of Message type and IDOC type are stored in table EDIMSGCombination of message type and IDOC type determine the processing algorithm. This is usually a function module and is set up in table EDIFCT.


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


Overview of ALE/IDOCs**Outbound Processing


Overview of ALE/IDOCs**Outbound processing: directApplication postingALE layerDatabaseApplication document posted simultaneously with IDOCsComm. layerasynch. RFCorEDISystem call FM( INBOUND_IDOC_PROCESS )On destinationComm. layer


Overview of ALE/IDOCs**Dispatch control

Application postingALE layerDatabaseApplication document posted simultaneously with IDocsasynch. RFCorEDIasynch. RFCorEDIComm. layerTechnical comms parameters are definedEDI or aRFC (asynch. remote function call)Send immediately or cumulate and send via batch jobIf batch, packet size is determined


Overview of ALE/IDOCs**Scenario analysis

How does the IDOC look like ?How is data being sent ?How is the data being received ?


Overview of ALE/IDOCs**Outbound program developmentProgram logicHow is the IDOC being created ?

TriggeringHow is the IDOC creation kicked off ?


Overview of ALE/IDOCs**Program logic Select data from application tables Fill data into IDOC Pass IDOC to ALE layer (Call function MASTER_IDOC_DISTRIBUTE) Commit Work Receiver determination Segment filtering Version Control Dispatch ControlIDOC programALE layerMASTER_IDOC_DISTRIBUTE


Overview of ALE/IDOCs**MASTER_IDOC_DISTRIBUTE

Call function MASTER_IDOC_DISTRIBUTEExportingmaster_idoc_control: IDOC control recordTablescommunication_idoc_control: returned information about the distributionmaster_idoc_data: IDOC data segments


Overview of ALE/IDOCs**Filling an EDIDD structure

MOVE Z1SEG to EDIDD-SEGNAMMOVE 10 to Z1SEG-FIELD1MOVE ABC to Z1SEG-FIELD2MOVE Z1SEG to EDIDD-SDATA


Overview of ALE/IDOCs**General Programming rulesDesign Guidelines for creating IDOC data records:

Left-justified filing of IDOC Fields

Replacing SAP codes with ISO codescurrency keyscountry keysunit of measureshipping instructionsConverting Currency Amounts


Overview of ALE/IDOCs**Left-justified Filling

All fields must be left-justifiedCharacter fields: automatic

Non-character fields:Condense statement must be usedCheck IDOC documentation to find out which fields require a condenseAll types unequal to char, cuky, clnt, accp, numc, dats, tims or unit require a condense


Overview of ALE/IDOCs**Code Conversions

Replacing SAP codes with ISO codesCurrency keys: currency_code_sap_to_isoCountry keys: country_code_sap_to_isoUnits of measure: unit_of_measure_sap_to_isoShipping instructions: sap_iso_package_type_codeConversion of currency amountscurrency_amount_sap_to_iso


Overview of ALE/IDOCs**Basic Configuration ElementsDefine RFC DestinationsDefine PortsMaintain Customer ModelCreate Partner Profiles


Overview of ALE/IDOCs**Maintaining RFC DestinationsTCODE:SM59


Overview of ALE/IDOCs**Displaying and Maintaining Ports A port is a logical representation of a communication channel in SAP with the data communicated being IDocs.

TCODE:WE21


Overview of ALE/IDOCs**Partner ProfilesTCODE:WE20


Overview of ALE/IDOCs**Partner Profiles-Inbound


Overview of ALE/IDOCs**Partner Profiles-Outbound


Overview of ALE/IDOCs**ALE For Transactional data ---- Output DeterminationNACE


Overview of ALE/IDOCs**Output Determination -- Output Types


Overview of ALE/IDOCs**Output Types -- Details


Overview of ALE/IDOCs**Inbound Processing


Overview of ALE/IDOCs**Inbound Processing.Application postingALE layerInput controlDatabaseSimultaneously update IDOC's status


Overview of ALE/IDOCs**Input ControlApplication postingALE layerInput controlDatabaseSimultaneously update IDOC's statusFor each message type and sender one can definewhen to process (immediate/batch)whether to call application directly or start customer workflowwho should get work items in case of errorIncoming IDOC packets are passed to application


Overview of ALE/IDOCs**Application InputApplication postingALE layerInput controlDatabaseSimultaneously update IDOC's statusInbound IDOCs are passed to the application via a standardized function interface


Overview of ALE/IDOCs**SerializationApplication postingALE layerInput controlDatabaseSimultaneously update IDOC's statusWhen processing the inbound IDOC, the application can call an ALE API (function module) to check that the IDOC has not been overtakenIf change No. 1 arrives after change No. 2, the IDOC containing it has been overtaken (by the IDOC containing the later change)


Overview of ALE/IDOCs**FM Assignment to Message Type and IDoc typeTCODE:WE57


Overview of ALE/IDOCs** Process CodesWE41WE42


Overview of ALE/IDOCs**Process Codes in Inbound and OutboundTCODE:WE64


Overview of ALE/IDOCs** FM For Inbound EDI TCODE:BD67


Overview of ALE/IDOCs**Inbound Program DevelopmentINBOUND_IDOC_PROCESSALE layerIDOC_INPUT_

Read IDOC data Post Application data Send Success info back to ALE layerALE configuration Partner Profiles Process Code Function module attribute Function module registryCall functionReturn VariablesIf ERROR, trigger Version change Segment filter Field conversion


Overview of ALE/IDOCs**Basic ScenarioDirect MethodCall Transaction Method


Overview of ALE/IDOCs**Advanced ScenarioMass processing SerializationAdvanced Workflow


Overview of ALE/IDOCs**Flow Of ProgramRead IDOC-Lock IDOC-Call Inbound Program-Write Status-Commit Work-Unlock IDOC


Overview of ALE/IDOCs**Interface of Inbound FMImporting Parameter -Input Method -Mass_processingEXPORT parameter .-Workflow_result-Application_variable-In_Update_task-Call_transaction_done

Tables parameter : IDOC_ControlIDOC_DATAIDOC_STATUSReturn_variable


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. Questions


Overview of ALE/IDOCs**Monitoring IDocs The IDoc interface offers 2 different approaches for tracking of data load and data flow:Reports for monitoringWorkflow 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.


Overview of ALE/IDOCs**List Of All IDocs Created. (Default, Additional, EDI)-- WE02/ WE05


Overview of ALE/IDOCs**Selection Program For Issuing Output -- WE15


Overview of ALE/IDOCs**Test Tool For Idoc Processing (WE19)


Overview of ALE/IDOCs**Idoc Search For Business Contents (Database). WE09


Overview of ALE/IDOCs**Questions


Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 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 SAPs solution to support distributed applications.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 An IDOC Type:is an SAP Data Dictionary defined structureprovides the highest level definition for a filehas a predefined structurerepresents a series of related business documents An IDOC (formally Message):is the occurrence of a message typeis the actual representation of a business transaction Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The IDOC control record is a kind of envelope record that contains information about the IDOC likeIDOC 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) andIDOC type (IDOCTP)Note that you have to use uppercase literals when you fill the two fieldsThe 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 ! Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The IDOC control record is a kind of envelope record that contains information about the IDOC likeIDOC 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) andIDOC type (IDOCTP)Note that you have to use uppercase literals when you fill the two fieldsThe 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 ! Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The 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 typeSDATA contains the actual data of the segment Copyright IBM Corporation 2004 Copyright IBM Corporation 2004Status Record- table EDIDS Information we get from Status record:Status number MessageIDoc typeDirectionData and time stampDetailed description of status by code and textLocation of exception in Intermediate DocumentDetector 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The IDOC control record is a kind of envelope record that contains information about the IDOC likeIDOC 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) andIDOC type (IDOCTP)Note that you have to use uppercase literals when you fill the two fieldsThe 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 ! Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The 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 documentationIDoc typeIDoc structure typeReceiver port/partner type/partner numberSender port/sender type/sender number

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The 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 its easier to deal with flat structures.Conceptually the IDOC type describes the technical structure of the message Copyright IBM Corporation 2004 Copyright IBM Corporation 2004Here is how to create a new IDOC type by assembling previously defined segments:Go to the maintenance of IDOC typesIn the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type

Select creation of new basic IDOC typePut segments into the IDOCSegment -> CreateEnter segment nameEnter attributes (Mandatory/Minimum/Maximum number)

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004Once 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 typesIn the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type

Go to message type maintenance:Environment -> Message typesTable view -> Display -> ChangeNew entriesCustomer message types should be in the customer name range (starting with Z)

Last step of the IDOC creation process is to link the new IDOC type with the new message type. Later in the process the message type will be linked to the outbound and inbound programs. With these configurations it is determined how the IDOC is being processed. The relationship between IDOC type and message type is a 1-to-many relationship. That means an IDOC can be associated with multiple message types thus allowing the IDOC to be processed differently, but a message type refers to exactly one IDOC type. Here is how to link the message type with the IDOC type :Go to the maintenance of IDOC typesIn the ALE-IMG: Extensions->IDOC types -> Maintain message type for Intermediate structure

Choose function EDI: Message types and assignment to IDOC typesLink your message type with your IDOC typeTable view -> Display -> ChangeNew entriesMessage type : ZBasic IDOC type: Z..

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The IDOC control record is a kind of envelope record that contains information about the IDOC likeIDOC 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) andIDOC type (IDOCTP)Note that you have to use uppercase literals when you fill the two fieldsThe 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 ! Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004Dispatch 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004First 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 segmentsCreate IDOC typeCreate message typeLink message type with IDOC type

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004In implementing an outbound program we have two deals with mainly two issues: Designing the program logic Defining a trigger mechanism for the programThe 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The fundamental logic of an outbound IDOC program is fairly simple. It can be subdivided into 3 steps:Select the data from the application tablesFill the data into the IDOC Pass the IDOC to the ALE layerCompared 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004Lets have a closer look at the function module MASTER_IDOC_DISTRIBUTEConceptually 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 doesnt have to be filled before MASTER_IDOC_DISTRIBUTE is called.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004Since 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 fillSecondly, move the whole field string into the SDATA fieldNote: 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004There are a couple of general rules that have to be followed when constructing the IDOC program:

All fields must be left-justifiedCurrency Amounts must be convertedAll 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004All 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 doesnt 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

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004SAP 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_isoCountry keys: country_code_sap_to_isoUnits of measure: unit_of_measure_sap_to_isoShipping instructions: sap_to_iso_package_type_codeThe Currency Amounts has also be converted with the function module currency_amount_sap_to_idocNote: 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The 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

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004You 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 RFCR/2 SystemFile interfaceThe 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004Tells 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004The 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 errorIf 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004On 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_. Since we have to stay within the customer name space, a custom inbound module typically is called Z_IDOC_INPUT_. 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.

Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004 Copyright IBM Corporation 2004