2. Overview of ALE/IDOCs 204/27/16
EDI
What is EDI?
Type of EDI process
• Outbound EDI Process
• Inbound EDI Process
3. Overview of ALE/IDOCs 304/27/16
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.
7. Overview of ALE/IDOCs 704/27/16
EDI Configuration
How to Set Up an RFC Destination in SAP
The Port Definitions
Configure Partner Profile
Configure Message Control
9. Overview of ALE/IDOCs 904/27/16
ALEALE
What is ALE?
Components of ALE.
Anatomy of an IDoc.
ALE Processing
Transactions For Monitoring and Processing IDocs.
Questions
10. Overview of ALE/IDOCs 1004/27/16
ALE TerminologyALE Terminology
•ALE - Application Linking & Enabling
•IDoc - Intermediate Document
•EDI - Electronic Data Interchange
12. Overview of ALE/IDOCs 1204/27/16
ALE!! What is it ??
It is a set ofIt 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..
13. Overview of ALE/IDOCs 1304/27/16
Features –ALE / IDocsFeatures –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
14. Overview of ALE/IDOCs 1404/27/16
ALE ScenarioALE Scenario
Document
SAP System R/3 SAP System R/3
IDoc
EDI SubsystemEDI Subsystem
IDocIDoc
15. Overview of ALE/IDOCs 1504/27/16
What is ALE ?
Components of ALE.
Anatomy of an IDoc.
ALE Processing
Transactions For Monitoring and Processing IDocs.
Trouble Shooting
Questions
Topics to coverTopics to cover
16. Overview of ALE/IDOCs 1604/27/16
Components of ALEComponents of ALE
Services:Services:
Application ServicesApplication Services
Distribution ServicesDistribution Services
Communication ServicesCommunication Services
17. Overview of ALE/IDOCs 1704/27/16
Application ServicesApplication Services
Services:Services:
Application ServicesApplication Services
Distribution ServicesDistribution Services
Communication ServicesCommunication Services
This is where the SAP
applications ( SD, FI,
MM etc. ) generate
their data and
documents
18. Overview of ALE/IDOCs 1804/27/16
Distribution ServicesDistribution Services
Services:Services:
Application ServicesApplication Services
Distribution ServicesDistribution Services
Communication ServicesCommunication Services
Recipients
Formats and
Filters the data
Creates IDocs
( Intermediate
Documents
19. Overview of ALE/IDOCs 1904/27/16
Communication ServicesCommunication Services
Services:Services:
Application ServicesApplication Services
Distribution ServicesDistribution Services
Communication ServicesCommunication Services •TCP/IP
•RFC
•tRFC
• etc
20. Overview of ALE/IDOCs 2004/27/16
Application
Data
Master
IDOC Determine
Receipients
Determine
Receipients
Filter/Convert
Data, Create IDOC
Filter/Convert
Data, Create IDOC
Comm.
IDOC
Application
Functions
Application
Functions
Filter/Convert
Data
Filter/Convert
Data
Comm.
IDOC
CarrierCarrier
Application
Layer
Distribution/ ALE
Layer
Communication
Layer
ApplicationApplication
In a Nut ShellIn a Nut Shell
21. Overview of ALE/IDOCs 2104/27/16
Topics to coverTopics to cover
What is ALE ?
Components of ALE.
Anatomy of an IDoc.
ALE Processing
Transactions For Monitoring and Processing IDocs.
Trouble Shooting
Questions
22. Overview of ALE/IDOCs 2204/27/16
IDoc ConceptIDoc Concept
R/3 System
System 1
SAP
Document
EDI subsystem
R/3 System
R/2 System
3rd party software
System 2
IDoc
23. Overview of ALE/IDOCs 2304/27/16
IDoc StructureIDoc Structure
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
24. Overview of ALE/IDOCs 2404/27/16
Control record
Data Record
Status Record
IDOC
“Intermediate
Document”
25. Overview of ALE/IDOCs 2504/27/16
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
Control RecordControl Record
26. Overview of ALE/IDOCs 2604/27/16
Message TypeMessage 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
27. Overview of ALE/IDOCs 2704/27/16
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 RecordData Record
28. Overview of ALE/IDOCs 2804/27/16
Status RecordStatus Record Information about the IDoc status like:
IDoc identification number
Status number - table verified
IDoc type
Direction
Data and time stamp; Structure:
EDIDS
29. Overview of ALE/IDOCs 2904/27/16
Status of IDOCStatus 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'.
34. Overview of ALE/IDOCs 3404/27/16
IDOC Type/ Message Type/ Processing FunctionIDOC Type/ Message Type/ Processing Function
ModuleModule
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.
35. Overview of ALE/IDOCs 3504/27/16
Topics to coverTopics 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
37. Overview of ALE/IDOCs 3704/27/16
Outbound processing: directOutbound processing: direct
Application
posting
Need to
create IDOC?
Create master
IDOC
Customer
Distribution Model
Receiver determination
Segment filter
Field value conversion
Version change
ALE layer
Dispatch
control
Database
M
Application document
posted simultaneously
with IDOCs
Comm. layer
asynch. RFC
or
EDI
System call FM
( INBOUND_
IDOC_
PROCESS )
On destination
CLinks
C
Comm. layer
38. Overview of ALE/IDOCs 3804/27/16
Dispatch controlDispatch control
Application
posting
Need to
create IDOC?
Create master
IDOC
Customer
Distribution Model
Receiver determination
Segment filter
Field value conversion
Version change
ALE layer
Dispatch
control
Database
M
Application document
posted simultaneously
with IDocs
C
asynch. RFC
or
EDI
Links
C
asynch. RFC
or
EDI
C
Comm. layer
- Technical comms parameters areTechnical comms parameters are
defineddefined
- EDI or aRFC (asynch. remoteEDI or aRFC (asynch. remote
function call)function call)
- Send immediately or cumulateSend immediately or cumulate
and send via batch joband send via batch job
If batch, packet size isIf batch, packet size is
determineddetermined
39. Overview of ALE/IDOCs 3904/27/16
Scenario analysisScenario analysis
• How does the IDOC look like ?
• How is data being sent ?
• How is the data being received ?
40. Overview of ALE/IDOCs 4004/27/16
Outbound program development
• Program logic
– “How is the IDOC being created ?”
• Triggering
– “How is the IDOC creation kicked off ?”
41. Overview of ALE/IDOCs 4104/27/16
Program logicProgram 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 Control
IDOC program
ALE layer
MASTER_IDOC_DISTRIBUTE
42. Overview of ALE/IDOCs 4204/27/16
MASTER_IDOC_DISTRIBUTEMASTER_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
43. Overview of ALE/IDOCs 4304/27/16
Filling an EDIDD structureFilling 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
44. Overview of ALE/IDOCs 4404/27/16
General Programming rulesGeneral 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
45. Overview of ALE/IDOCs 4504/27/16
Left-justified FillingLeft-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
46. Overview of ALE/IDOCs 4604/27/16
Code ConversionsCode 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’
47. Overview of ALE/IDOCs 4704/27/16
Basic Configuration ElementsBasic Configuration Elements
Define RFC Destinations
Define Ports
Maintain Customer Model
Create Partner Profiles
49. Overview of ALE/IDOCs 4904/27/16
Displaying and Maintaining PortsDisplaying and Maintaining Ports
A port is a logical representation of aA port is a logical representation of a
communication channel in SAP withcommunication channel in SAP with
the data communicated being IDocsthe data communicated being IDocs.
TCODE:
WE21
57. Overview of ALE/IDOCs 5704/27/16
Inbound Processing.Inbound Processing.
Application
posting
Field value conversion
ALE layer
Input
control
Database
A
Simultaneously update
IDOC's status
Comm. layer
asynch. RFC
or
EDI
Version change
Segment filter
C
A
Post application
document
Process IDOCSerialization
58. Overview of ALE/IDOCs 5804/27/16
Input ControlInput Control
Application
posting
Field value conversion
ALE layer
Input
control
Database
A
Simultaneously update
IDOC's status
Comm. layer
asynch. RFC
or
EDI
Version change
Segment filter
C
A
Post application
document
Process IDOCSerialization
- For each message type and senderFor each message type and sender
one can defineone can define
when to processwhen to process
(immediate/batch)(immediate/batch)
whether to call applicationwhether to call application
directly or start customerdirectly or start customer
workflowworkflow
who should get work items inwho should get work items in
case of errorcase of error
- Incoming IDOC packets are passed toIncoming IDOC packets are passed to
applicationapplication
59. Overview of ALE/IDOCs 5904/27/16
Application InputApplication Input
Application
posting
Field value conversion
ALE layer
Input
control
Database
A
Simultaneously update
IDOC's status
Comm. layer
asynch. RFC
or
EDI
Version change
Segment filter
C
A
Post application
document
Process IDOCSerialization
- Inbound IDOCs are passed toInbound IDOCs are passed to
the application via athe application via a
standardized functionstandardized function
interfaceinterface
60. Overview of ALE/IDOCs 6004/27/16
SerializationSerialization
Application
posting
Field value conversion
ALE layer
Input
control
Database
A
Simultaneously update
IDOC's status
Comm. layer
asynch. RFC
or
EDI
Version change
Segment filter
C
A
Post application
document
Process IDOCSerialization
- When processing theWhen processing the
inbound IDOC, theinbound IDOC, the
application can call an ALEapplication can call an ALE
API (function module) toAPI (function module) to
check that the IDOC has notcheck that the IDOC has not
been overtakenbeen overtaken
If change No. 1 arrivesIf change No. 1 arrives
after change No. 2, theafter change No. 2, the
IDOC containing it hasIDOC containing it has
been overtaken (by thebeen overtaken (by the
IDOC containing theIDOC containing the
later change)later change)
61. Overview of ALE/IDOCs 6104/27/16
FM Assignment to Message Type andFM Assignment to Message Type and
IDoc typeIDoc type
TCODE:
WE57
65. Overview of ALE/IDOCs 6504/27/16
Inbound Program DevelopmentInbound Program Development
INBOUND_IDOC_PROCESS
IDOC
ALE layer
IDOC_INPUT_<MSGTYPE>
• Read IDOC data
• Post Application data
• Send Success info back to ALE layer
ALE configuration
• Partner Profiles
• Process Code
• Function module attribute
• Function module registry
Workflow Task
Call function
Return Variables
If ERROR, trigger
• Version change
• Segment filter
• Field conversion
66. Overview of ALE/IDOCs 6604/27/16
Basic Scenario
Direct Method
Call Transaction Method
67. Overview of ALE/IDOCs 6704/27/16
Advanced Scenario
Mass processing
Serialization
Advanced Workflow
68. Overview of ALE/IDOCs 6804/27/16
Flow Of Program
Read IDOC-Lock IDOC-Call Inbound Program-
Write Status-Commit Work-Unlock IDOC
69. Overview of ALE/IDOCs 6904/27/16
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
70. Overview of ALE/IDOCs 7004/27/16
Topics to coverTopics to cover
What is ALE ?
Components of ALE.
Anatomy of an IDoc.
ALE Processing
Transactions For Monitoring and Processing IDocs.
Questions
71. Overview of ALE/IDOCs 7104/27/16
Monitoring IDocsMonitoring 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.
72. Overview of ALE/IDOCs 7204/27/16
List Of All IDocs Created. (Default, Additional, EDI)--List Of All IDocs Created. (Default, Additional, EDI)--
WE02/ WE05WE02/ WE05
73. Overview of ALE/IDOCs 7304/27/16
Selection Program For Issuing Output --Selection Program For Issuing Output --
WE15WE15
74. Overview of ALE/IDOCs 7404/27/16
Test Tool For Idoc Processing (WE19)Test Tool For Idoc Processing (WE19)
75. Overview of ALE/IDOCs 7504/27/16
Idoc Search For Business ContentsIdoc Search For Business Contents
(Database). WE09(Database). WE09
Application Link Enabling –SAP data interfacing
ALE is SAP proprietary technology that enables data communications between two or more SAP systems and or R/3 and external systems.
ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time.
ALE is SAP’s solution to support distributed applications.
An IDOC Type:
is an SAP Data Dictionary defined structure
provides the highest level definition for a file
has a predefined structure
represents a series of related business documents
An IDOC (formally ‘Message’):
is the occurrence of a message type
is the actual representation of a business transaction
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like
IDOC type (“what data is in the IDOC”)
Message type (“how is the IDOC being processed”)
Sender information (“who is the sender of that IDOC”)
Receiver information (“who is the receiver of that IDOC”)
Latest status of EDI processing.
EDI standard and version.
The only two mandatory fields that must be filled are the
Message type (MESTYP) and
IDOC type (IDOCTP)
Note that you have to use uppercase literals when you fill the two fields
The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”)
The receiver information is optional:
If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created.
If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like
IDOC type (“what data is in the IDOC”)
Message type (“how is the IDOC being processed”)
Sender information (“who is the sender of that IDOC”)
Receiver information (“who is the receiver of that IDOC”)
Latest status of EDI processing.
EDI standard and version.
The only two mandatory fields that must be filled are the
Message type (MESTYP) and
IDOC type (IDOCTP)
Note that you have to use uppercase literals when you fill the two fields
The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”)
The receiver information is optional:
If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created.
If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
The IDOC data records contain the data of the message. The data records are passed in an internal table and they have to match the structure of the IDOC (sequence of segments, min/max, hierarchy etc.)
EDIDD is a generic structure used for all IDOC segments
SEGNAM field identifies the segment type
SDATA contains the actual data of the segment
Status Record- table EDIDS –Information we get from Status record:
Status number
Message
IDoc type
Direction
Data and time stamp
Detailed description of status by code and text
Location of exception in Intermediate Document
Detector of exception by program and user.
The statuses for outbound IDocs are between &apos;01&apos; and &apos;49&apos;, while the statuses for inbound IDocs begin from &apos;50&apos;.
When an IDoc is created, the IDoc Interface sets the status in the function module EDI_DOCUMENT_CLOSE_CREATE. All additional
status records are written explicitly by the function module EDI_DOCUMENT_STATUS_SET.
It is possible to have Custom Statuses also.
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like
IDOC type (“what data is in the IDOC”)
Message type (“how is the IDOC being processed”)
Sender information (“who is the sender of that IDOC”)
Receiver information (“who is the receiver of that IDOC”)
Latest status of EDI processing.
EDI standard and version.
The only two mandatory fields that must be filled are the
Message type (MESTYP) and
IDOC type (IDOCTP)
Note that you have to use uppercase literals when you fill the two fields
The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”)
The receiver information is optional:
If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created.
If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
The first step in creating a new IDOC is to create all the segments that go into that IDOC. There are some rules that have to be followed while creating the segments:
The name of that segment type must start with ‘Z1’
For each field in the segment you have to define a field name, a data element for the segment structure and a data element for the segment documentation.
The data element for the segment structure has to be of data type ‘CHAR’
The IDOC tools create overall three structures:
Z1nnnnn - field names
Z2nnnnn - data elements for structure definition
Z3nnnnn - data elements for documentation
IDoc type
IDoc structure type
Receiver port/partner type/partner number
Sender port/sender type/sender number
The next step is to create the IDOC type by “assembling” all the necessary segments. Part of our scenario analysis was to define the layout of the IDOC. We should have addressed the following questions:
Which segments should be used ?
What is the hierarchy of the segments ?
Which segments are mandatory and which are optional ?
How often may a segment be repeated ?
SAP recommends to create the structures as flat as possible. Usually each level of segment hierarchy results in a looping structure in the corresponding program. Therefore it’s easier to deal with flat structures.
Conceptually the IDOC type describes the technical structure of the message
Here is how to create a new IDOC type by assembling previously defined segments:
Go to the maintenance of IDOC types
In the ALE-IMG: Extensions-&gt;IDOC types -&gt; Maintain IDOC type
Select creation of new basic IDOC type
Put segments into the IDOC
Segment -&gt; Create
Enter segment name
Enter attributes (Mandatory/Minimum/Maximum number)
Once the IDOC type is defined a message type has to be created. A message type determines how the data in the IDOC is being processed. This allows to use the same IDOC in different scenarios but process the data differently through different message types. A Message Type is the equivalent of a business document type. It characterizes the data being sent across systems, e.g. MATMAS is a message type for Material Master.
Here is how to define a new message type :
Go to the maintenance of IDOC types
In the ALE-IMG: Extensions-&gt;IDOC types -&gt; Maintain IDOC type
Go to message type maintenance:
Environment -&gt; Message types
Table view -&gt; Display -&gt; Change
New entries
Customer message types should be in the customer name range (starting with Z)
Last step of the IDOC creation process is to link the new IDOC type with the new message type. Later in the process the message type will be linked to the outbound and inbound programs. With these configurations it is determined how the IDOC is being processed.
The relationship between IDOC type and message type is a 1-to-many relationship. That means an IDOC can be associated with multiple message types thus allowing the IDOC to be processed differently, but a message type refers to exactly one IDOC type.
Here is how to link the message type with the IDOC type :
Go to the maintenance of IDOC types
In the ALE-IMG: Extensions-&gt;IDOC types -&gt; Maintain message type for Intermediate structure
Choose function “EDI: Message types and assignment to IDOC types”
Link your message type with your IDOC type
Table view -&gt; Display -&gt; Change
New entries
Message type : Z……
Basic IDOC type: Z…..
The IDOC control record is a kind of “envelope” record that contains information about the IDOC like
IDOC type (“what data is in the IDOC”)
Message type (“how is the IDOC being processed”)
Sender information (“who is the sender of that IDOC”)
Receiver information (“who is the receiver of that IDOC”)
Latest status of EDI processing.
EDI standard and version.
The only two mandatory fields that must be filled are the
Message type (MESTYP) and
IDOC type (IDOCTP)
Note that you have to use uppercase literals when you fill the two fields
The sender information - along with additional information - is automatically filled in by the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”)
The receiver information is optional:
If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it is, an IDOC is created; otherwise no IDOC will be created.
If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are maintained in the distribution model for that message type and create an IDOC for each receiver !
The application drives distribution: ALE does not read application tables to build messages, instead the applications have ALE-calls built in.
Data consistency is ensured by the database: the application document and the ALE-document (IDOC) are posted in the same LUW (logical unit of work). Hence if one fails to post, both fail.
The following slides give more details on output processing.
Dispatch control is where technical parameters are maintained:
whether to pass the IDocs to the file interface for EDI-subsystems, or to other systems via asynchronous remote function calls.
whether IDocs should be sent immediately or cumulated and sent periodically by a batch job; in the latter case the packet size (see later) is determined here.
First step in creating our own ALE scenario is to do a scenario analysis. We have to understand what the data looks like that is going to be exchanged, how we it is being extracted and how it is being processed.
We have to consider the following questions:
How is the Data Container (IDOC) being structured ?
Which data fields have to be transferred ?
How many logical groups of data (header vs. line item) do we have ?
Do we have hierarchical structures ?
Are there any optional or mandatory groups ?
How long are the data fields ?
When should which data be sent ?
How does the triggering work ?
Where is the data being extracted from ?
What should the receiver to with the data ?
Once we have done our analysis we should have a clear understanding about the IDOC structure. Assuming we have designed the layout of our IDOC it is fairly simple and straightforward to define that IDOC in SAP with the so called IDOC definition tools.
There are 4 main steps involved in creating the IDOC:
Create segments
Create IDOC type
Create message type
Link message type with IDOC type
In implementing an outbound program we have two deals with mainly two issues:
Designing the program logic
Defining a trigger mechanism for the program
The program logic defines how the data gets extracted from the application tables and how the IDOC is being created.
The trigger mechanism defines how the interface (and an ALE scenario is nothing else than a SAP-to-SAP interface) gets kicked off.
In the following, we will first focus on program logic and than explore different options to trigger the outbound IDOC creation.
The fundamental logic of an outbound IDOC program is fairly simple. It can be subdivided into 3 steps:
Select the data from the application tables
Fill the data into the IDOC
Pass the IDOC to the ALE layer
Compared to a traditional interface program the main difference is that the data is selected into the IDOC format and send to the ALE layer as opposed to writing the data out to a flat file. The selection logic itself is the pretty much the same.
The entry point into the ALE layer is the function module “MASTER_IDOC_DISTRIBUTE”. All ALE functionality that was introduced earlier (Receiver determination, Segment filtering, Version Control, Dispatch Control) is buried in that function module. That functionality is totally transparent to a programmer - all he is concerned with is to call MASTER_IDOC_DISTRIBUTE with the appropriate parameters.
Let’s have a closer look at the function module “MASTER_IDOC_DISTRIBUTE”
Conceptually “MASTER_IDOC_DISTRIBUTE” accepts as a parameter exactly one IDOC. That IDOC is passed in the two structures “master_IDoc_control” and “master_IDoc_data”.
“master_IDoc_control” is a one-dimensional data structure (field string) that holds the IDOC control record. We will see shortly the minimal information that needs to go into the IDOC control record.
“master_IDoc_data” is a two-dimensional data structure (table), that holds all the data records of the IDOC to be sent out. We will shortly see what information needs to put into the data records of an IDOC.
“communication_IDoc_control” is a data structure that returns back additional control record information of the IDOC that was created. The most important information passed back is the IDOC number. This data structure doesn’t have to be filled before “MASTER_IDOC_DISTRIBUTE” is called.
Since the EDIDD structure is used for all different type of IDOCs containing all sorts of Segments, filling the EDIDD structure is a little bit tricky.
First you have to fill the 55-byte header with the Segment name.
Second the 1000-byte SDATA field needs to be filled. This is a two-step process (similar to a COBOL - redefine construct):
First, fill the data into a field string that has the structure of the segment type you want to fill
Secondly, move the whole field string into the SDATA field
Note: The receiver of the IDOC needs to execute the reverse logic. The SEGNAM information helps to parse out the SDATA field by moving it into a field string that matches the layout of the segment type specified in the SEGNAM field.
There are a couple of general rules that have to be followed when constructing the IDOC program:
All fields must be left-justified
Currency Amounts must be converted
All SAP codes must be converted into ISO codes
SAP codes that have to be converted include Currency keys, country Keys, Unit of measure and Shipping instructions.
All fields in the IDOC are defined with a data type of ‘CHAR’. SAP choose that approach to ensure independency of any internal binary representations. All fields have to left-justified.
ABAP automatically converts different data types into each other. However, this automatic conversion doesn’t produce the desired left-justification for all data types. SAP requires to convert the all data types with the exception of ‘char’, ‘cuky’, ‘clnt’, ‘accp’, ‘numc’, ‘dats’, ‘tims’ or ‘unit’.
The easiest way to left-justify the fields is with the ‘Condense’ statement
SAP decided not to use any SAP specific codes in the IDOC. Instead they recommend to use ISO codes.
Note: This decision a relict from the EDI world. In an SAP-to-SAP scenario it doesn&apos;t make sense, because the receiver program has to do the conversion back into the SAP code ! As long as the sender and receiver have the same assumptions about the codes, there is no technically reason to do code conversions.
SAP delivers a set of function modules to do these conversion:
Currency keys: ‘currency_code_sap_to_iso’
Country keys: ‘country_code_sap_to_iso’
Units of measure: ‘unit_of_measure_sap_to_iso”
Shipping instructions: ‘sap_to_iso_package_type_code’
The Currency Amounts has also be converted with the function module ‘currency_amount_sap_to_idoc’
Note: There is a similar set of function modules to do the conversion in the opposite directions (from ISO to SAP). These function modules have to be used on the receiving side.
The Remote Function Call is controlled via the parameters of the RFC destination.
The RFC destinations must be maintained in order to create an RFC port.
The name of the RFC destination should correspond to the name of the logical system in question.
The following types of RFC destinations are maintainable:
· R/2 links
· R/3 links
· internal links
· logical destinations
· CMC link
· SNA/CPI-C connections
· TCP/IP links
· links of the ABAP/4 drivers
You specify the technical characteristics of the link between the SAP System and the other system in the port definition.
The following port types are supported:
Asynchronous RFC
R/2 System
File interface
The ALE interface generates ports automatically. The EDI interface assigns numbers internally for these ports. Hence the ports can be identified explicitly.
The system can only generate the numbers if a number range is entered for the number range object EDIPORT in number range 01.
Tells the ALE Layer how to send Msg. Between systems.
The Partner No. is the logical system name of the other system.
The Partner type is ‘LS’ ( logical system) for ALE.
The Partner Class is a free text field that classifies Partners.
The first part of input processing mirrors output processing, with version change, segment filter and field value conversion.
The IDOC is first written to the database, with a link to the IDOC in the sending system, and then input control takes over:
the type of input is determined (function module, workflow, workitem)
the input timing is determined (immediate or cumulated and processed in batch)
who should be informed in case of error
If serialization is necessary, the application posting function can call an ALE-API (function module) to determine whether the IDOC has been overtaken (explained later).
IDOC processing is complete when an application document is created or changed; to signal this, a success status record is added to the IDOC in the same LUW (logical unit of work) as that in which the application document is processed.
The only exception to the above is the with ORDERS and ORDCHG, where a call transaction is first called and then the status is updated.
On the inbound side there are 3 major elements that need to be developed to finalize a custom ALE scenario:
Inbound function module: The function module is responsible for processing the IDOC and creating an application document from the IDOC data. The function module is called by the ALE layer and has to return back information about the success of the document posting.
ALE configuration: The ALE layer has to have knowledge which function module to call for a certain message type / IDOC type. These assignments are made through ALE configuration
Workflow task: ALE error handling is done via workflow. A workflow task has to be defined that can be executed for the case that the application document posting in the function module was not successful. The ALE layer gets the information about the success of the posting passed from the inbound function module. The workflow takes is started by the ALE layer.
Here is a more detailed look at these 3 components and how they interact.
INBOUND_IDOC_PROCESS is the generic entry point for all inbound IDOC processing. This function module is called by the sending SAP systems and gets one or more IDocs passed as parameter. All the ALE layer functionality that we learned about previously (Version change, segment filtering, field conversions) are handled in that function module.
INBOUND_IDOC_PROCESS takes information out of the control record of the IDOC to access the partner profile. Part of the partner profile is a process code that is tied to an inbound IDOC function module. This function module is then being called.
The SAP naming convention for an inbound function module is IDOC_INPUT_&lt;MSGTYPE&gt;. Since we have to stay within the customer name space, a custom inbound module typically is called Z_IDOC_INPUT_&lt;MSGTYPE&gt;.
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.
