The SAP R/3 Guide to EDI, IDocs and Interfaces

The SAP R/3 Guide to EDI, IDocs and Interfaces

Where Has the Money Gone? 1

1.1 Communication ...............................................................................................2
More than 80% of the time of an EDI project is lost in waiting for answers,
trying to understand proposals and retrieving data nobody actually needs. 2

1.2 Psychology of Communication ......................................................................3
Bringing developers together accelerates every project. Especially when
both parties are so much dependent on each other as in an EDI project, the
partners need to communicate without pause. 3

1.3 Phantom SAP Standards and a Calculation ..................................................4
It is reported that SAP R/3 delivers standard EDI programs and that they
should not be manipulated under no circumstances. Because this is not true,
much project is lost in chasing the phantom. 4

1.4 Strategy.............................................................................................................5
Do not loose your time in plans. Have prototypes developed and take them
as a basis. 5

1.5 Who Is on Duty?................................................................................................5
Writing interface programs is much like translating languages. The same rule
apply. 5

1.6 Marcus T. Cicero ..............................................................................................6
Some may have learned it in school: the basic rules of rhetoric according to
Cicero. You will know the answers, when your program is at its end. Why
don't you ask the questions in the beginning? Ask the right question, then
you will know. 6

What Are SAP R/3 IDocs? 7

2.1 What are IDocs?...............................................................................................8
IDocs are structured ASCII files (or a virtual equivalent). They are the file
format used by SAP R/3 to exchange data with foreign systems. 8

2.2 Exploring a Typical Scenario...........................................................................9
The IDoc process is a straight forward communication scenario. A
communication is requested, then data is retrieved, wrapped and sent to
the destination in a predefined format and envelope. 9

Get a Feeling for IDocs 11

3.1 Get A Feeling For IDocs.................................................................................12
For the beginning we want to give you a feeling of what IDocs are and how
they may look like, when you receive it as a plain text file. 12

3.2 The IDoc Control Record ...............................................................................14
The very first record of an IDoc package is always a control record. The
structure of this control record is the DDic structure EDIDC and describes the
contents of the data contained in the package. 14

3.3 The IDoc Data.................................................................................................15
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 characters in length, filling the rest of the line.

3.4 Interpreting An IDoc Segment Info............................................................... 16
All IDoc data records are exchanged in a fixed format, regardless of the
segment type. The segment's true structure is stored in R/3's repository as a
DDic structure of the same name. 16

3.5 IDoc Base - Database Tables Used to Store IDocs...................................... 17
When R/3 processes an IDoc via the standard inbound or outbound
mechanism, the IDoc is stored in the tables. The control record goes to table
EDIDC and the data goes to table EDID4. 17

Exercise: Setting Up IDocs 18

4.1 Quickly Setting up an Example.................................................................... 19
If you have a naked system, you cannot send IDocs immediately. This
chapter will guide you through the minimum steps to see how the IDoc
engine works. 19

4.2 Example: The IDoc Type MATMAS01 ............................................................. 20
To sharpen your understanding, we will show you an example of an IDoc of
type MATMAS01, which contains material master data. 20

4.3 Example: The IDoc Type ORDERS01 ............................................................. 21
To allow an interference, here is a sample of IDoc type ORDERS01 which is
used for purchase orders and sales orders. 21

Monitoring IDocs 23
Sample Processing Routines 25

6.1 Sample Processing Routines......................................................................... 26
Creating and processing IDocs are a widely mechanical task, as it is true for
all interface programming. We will show a short example that packs SAP R/3
SAPscript standard text elements into IDocs and stores them back. 26

6.2 Sample Outbound Routines......................................................................... 27
The most difficult work when creating outbound IDocs is the retrieval of the
application data which needs sending. Once the data is well retrieved, the
data needs to be converted to IDoc format, only. 27

6.3 Sample Inbound Routines............................................................................. 29
Inbound processing is widely the reverse process of an outbound.. The
received IDoc has to be unpacked, interpreted and transferred to an
application for further processing. 29

IDocs Terminology 31

7.1 Basic Terms..................................................................................................... 32
There are a couple of expressions and methods that you need to know,
when dealing with IDoc. 32

7.2 Terminology ................................................................................................... 33
7.2.1 Message Type – How to Know What the Data Means 33
Data exchanged by an IDoc via EDI is known as message. Messages of the
same kind belong to the same message type. 33
7.2.2 Partner Profiles – How to Know the Format of the Partner 33
Different partners may speak different languages. While the information
remains the same, different receivers may require completely different file
formats and communication protocols. This information is stored in a partner
profile. 33
7.2.3 IDoc Type – The Structure of The IDoc File 34
The IDoc type is the name of the data structure used to describe the file
format of a specific IDoc. 34
7.2.4 Processing Codes 34
The processing code is a pointer to an algorithm to process an IDoc. It is
used to allow more flexibility in assigning the processing function to an IDoc
message. 34

IDocs Customizing 37

8.1 Basic Customizing Settings............................................................................38
Segments define the structure of the records in an IDoc. They are defined
with transaction WE31. 38

8.2 Creating An IDoc Segment WE31..............................................................40
The segment defines the structure of the records in an IDoc. They are
defined with transaction WE31. We will define a structure to send a text
from the text database. 40

8.3 Defining The Message Type (EDMSG)............................................................43
The message type defines the context under which an IDoc is transferred to
its destination. It allows to use the same IDoc file format to use for several
different applications. 43

8.4 Define Valid Combination Of Message and IDoc Types ............................44
The valid combinations of message type and IDoc type are stored in table
EDIMSG. 44

8.5 Assigning a processing function (Table EDIFCT )....................................45
The combination of message type and IDoc type determine the processing
algorithm. This is usually a function module with a well defined interface or a
SAP business object and is set up in table EDIFCT. 45

8.6 Processing Codes ..........................................................................................46
R/3 uses the method of logical process codes to detach the IDoc processing
and the processing function module. They assign a logical name to function
instead of specifying the physical function name. 46

8.7 Inbound Processing Code.............................................................................48
The inbound processing code is assigned analogously. The processing code
is a pointer to a function module which can handle the inbound request for
the specified IDoc and message type. 48

IDoc Outbound Triggers 51

9.1 Individual ABAP..............................................................................................52
The simplest way to create IDocs, is to write an ABAP which simply does it. 52

9.2 NAST Messages Based Outbound IDocs......................................................54
You can use the R/3 message concept to trigger IDocs the same way as you
trigger SapScript printing. 54

9.3 The RSNAST00 ABAP .......................................................................................56
The ABAP RSNAST00 is the standard ABAP, which is used to collect
unprocessed NAST message and to execute the assigned action. 56

9.4 Sending IDocs Via RSNASTED........................................................................57
Standard R/3 provides you with powerful routines, to trigger, prepare and
send out IDocs in a controlled way. There are only a few rare cases, where
you do not want to send IDocs the standard way. 57

9.5 Sending IDocs Via RSNAST00 ........................................................................58
Here is the principle flow how RSNAST00 processes messages for IDocs. 58

9.6 Workflow Based Outbound IDocs................................................................. 59
Unfortunately, there are application that do not create messages. This is
especially true for master data applications. However, most applications fire
a workflow event during update, which can easily be used to trigger the
IDoc distribution. 59

9.7 Workflow Event From Change Document ................................................... 60
Instead of waiting for a polling job to create IDocs, they can also be created
immediately after a transaction finishes. This can be done by assigning an
action to an workflow event. 60

9.8 ALE Change Pointers ..................................................................................... 61
Applications which write change documents will also try to write change
pointers for ALE operations. These are log entries to remember all modified
data records relevant for ALE. 61

9.9 Activation of change pointer update.......................................................... 62
Change pointers are log entries to table BDCP which are written every time
a transaction modifies certain fields. The change pointers are designed for
ALE distribution and written by the function CHANGE_DOCUMENT_CLOSE. 62

9.10 Dispatching ALE IDocs for Change Pointers ................................................ 63
Change pointers must be processed by an ABAP, e.g. RBDMIDOC. 63

IDoc Recipes 65

10.1 How the IDoc Engine Works.......................................................................... 66
IDocs are usually created in a four step process. These steps are: retrieving
the data, converting them to IDoc format, add a control record and
delivering the IDoc to a port. 66

10.2 How SAP Standard Processes Inbound IDocs.............................................. 67
When you receive an IDoc the standard way, the data is stored in the IDoc
base and a function module is called, which decides how to process the
received information. 67

10.3 How To Create the IDoc Data....................................................................... 68
R/3 provides a sophisticated IDoc processing framework. This framework
determines a function module, which is responsible for creating or
processing the IDoc. 68

10.4 Interface Structure of IDoc Processing Functions........................................ 70
To use the standard IDoc processing mechanism the processing function
module must have certain interface parameters, because the function is
called dynamically from a standard routine. 70

10.5 Recipe To Develop An Outbound IDoc Function........................................ 71
This is an individual coding part where you need to retrieve the information
from the database and prepare it in the form the recipient of the IDoc will
expect the data 71

10.6 Converting Data Into IDoc Segment Format ............................................... 72
The physical format of the IDocs records is always the same. Therefore the
application data must be converted into a 1000 character string. 72

Partner Profiles and Ports 73

11.1 IDoc Type and Message Type...................................................................... 74
An IDoc file requires a minimum of accompanying information to give sense
to it. These are the message type and the IDoc type. While the IDoc type
tells you about the fields and segments of the IDoc file, the message type
flags the context under which the IDoc was sent. 74

11.2 Partner Profiles................................................................................................75
Partner profiles play an important role in EDI communications. They are
parameter files which store the EDI partner dependent information. 75

11.3 Defining the partner profile ( WE20 ) .........................................................76
The transaction WE20 is used to set up the partner profile. 76

11.4 Data Ports ( WE21 )......................................................................................77
IDoc data can be sent and received through a multitude of different media.
In order to decouple the definition of the media characteristics from the
application using it, the media is accessed via ports. 77

RFC Remote Function Call 79

12.1 What Is Remote Function Call RFC?..............................................................80
A Remote Function Call enables a computer to execute a program an
another computer. The called program is executed locally on the remote
computer using the remote computer's environment, CPU and data storage. 80

12.2 RFC in R/3........................................................................................................81
RFC provides interface shims for different operating systems and platforms,
which provide the communication APIs for doing RFC from and to R/3. 81

12.3 Teleport Text Documents With RFC ...............................................................82
This example demonstrates the use of RFC functions to send data from one
SAP system to a remote destination. The example is a simple demonstration,
how to efficiently and quickly use RFC in your installation. 82

12.4 Calling A Command Line Via RFC ?.............................................................84
R/3 RFC is not limited to communication between R/3 systems. Every
computer providing supporting the RFC protocol can be called from R/3 via
RFC. SAP provides necessary API libraries for all operating systems which
support R/3 and many major programming languages e.g. C++, Visual Basic
or Delphi. 84

Calling R/3 Via OLE/JavaScript 87

13.1 R/3 RFC from MS Office Via Visual Basic......................................................88
The Microsoft Office suite incorporates with Visual Basic for Applications
(VBA) a fully object oriented language. JavaScript and JAVA are naturally
object oriented. Therefore you can easily connect from JavaScript, JAVA,
WORD, EXCEL and all the other VBA compliant software to R/3 via the
CORBA compatible object library (in WINDOWS known also DLLs or ACTIVE-X
(=OLE/2) components). 88

13.2 Call Transaction From Visual Basic for WORD 97.........................................89
This is a little WORD 97 macro, that demonstrates how R/3 can be called with
a mouse click directly from within WORD 97. 89

13.3 R/3 RFC from JavaScript ................................................................................91
JavaScript is a fully object oriented language. Therefore you can easily
connect from JavaScript to R/3 via the CORBA compatible object library (in
WINDOWS known also DLLs or ACTIVE-X (=OLE/2) components). 91

13.4 R/3 RFC/OLE Troubleshooting........................................................................93
Problems connecting via RFC can usually be solved by reinstalling the full
SAPGUI and/or checking your network connection with R/3. 93

ALE - Application Link Enabling 95

14.1 A Distribution Scenario Based On IDocs ...................................................... 96
ALE has become very famous in business circles. While it sounds mysterious
and like a genial solution, it is simply a mean to automate data exchange
between SAP systems. It is mainly meant to distribute data from one SAP
system to the next. ALE is a mere enhancement of SAP-EDI and SAP-RFC
technology. 96

14.2 Example ALE Distribution Scenario............................................................... 97
To better understand let us model a small example ALE scenario for
distribution of master data between several offices. 97

14.3 ALE Distribution Scenario............................................................................... 98
ALE is a simple add-on application propped upon the IDoc concept of SAP
R/3. It consists on a couple of predefined ABAPs which rely on the
customisable distribution scenario. These scenarios simple define the IDoc
types and the pairs of partners which exchange data. 98

14.4 Useful ALE Transaction Codes....................................................................... 99
ALE is customized via three main transaction. These are SALE, WEDI and
BALE. 99

14.5 ALE Customizing SALE .............................................................................. 101
ALE customizing is relatively staright forward. The only mandatory task is the
definition of the ALE distribution scenario. The other elements did not prove
as being very helpful in practical applications. 101

14.6 Basic Settings SALE ................................................................................... 102
Basic settings have do be adjusted before you can start working with ALE. 102

14.7 Define The Distribution Model (The "Scenario") BD64............................ 103
The distribution model (also referred to as ALE-Scenario) is a more or less
graphical approach to define the relationship between the participating
senders and receivers. 103

14.8 Generating Partner Profiles WE20........................................................... 105
A very useful utility is the automatic generation of partner profiles out of the
ALE scenario. Even if you do not use ALE in your installation, it could be only
helpful to define the EDI partners as ALE scenario partners and generate the
partner profiles. 105

14.9 Creating IDocs and ALE Interface From BAPI SDBG............................... 109
There is a very powerful utility which allows to generate most IDoc and ALE
interface objects directly from a BAPI's method interface. 109

14.10 Defining Filter Rules...................................................................................... 113
ALE allows to define simple filter and transformation rules. These are table
entries, which are processed every time the IDoc is handed over to the port.
Depending on the assigned path this happens either on inbound or
outbound. 113

Workflow Technology 115

15.1 Workflow in R/3 and Its Use For Development........................................... 116
SAP R/3 provides a mechanism, called Workflow, that allows conditional and
unconditional triggering of subsequent transactions from another
transaction. This allows to build up automatic processing sequences without
having the need to modify the SAP standard transactions. 116

15.2 Event Coupling (Event Linkage)..................................................................117
Contrary to what you mostly hear about R/3 workflow, it is relatively easy and
mechanical to define a function module as a consecutive action after
another routine raised a workflow event. This can e.g. be used to call the
execution of a transaction after another one has finished. 117

15.3 Workflow from Change Documents ...........................................................118
Every time a change document is written a workflow event for the change
document object is triggered. This can be used to chain unconditionally an
action from a transaction. 118

15.4 Trigger a Workflow from Messaging ...........................................................119
The third common way to trigger a workflow is doing it from messaging. 119
15.5 Example, How To Create A Sample Workflow Handler.............................120
Let us show you a function module which is suitable to serve as a function
module and define the linkage. 120

Batch Input Recording 125

16.1 Recording a Transaction With SHDB ........................................................126
The BTCI recorder lets you record the screen sequences and values entered
during a transaction. It is one of the most precious tools in R/3 since release
3.1. It allows a fruitful cooperation between programmer and application
consultant. 126

16.2 How to Use the Recorder Efficiently............................................................129
This routine replaces BDCRECXX to allow executing the program generated
by SHDB via a call transaction instead of generating a BTCI file. 129

16.3 Include ZZBDCRECXX to Replace BDCRECXX ...........................................130
This routine replaces BDCRECXX to allow executing the program generated
by SHDB via a call transaction instead of generating a BTCI file. 130

16.4 ZZBRCRECXX_FB_GEN: Generate a Function from Recording..................132
The shown routine ZZBDCRECXX_FB_GEN replaces BDCRECXX in a recorded
ABAP. Upon executing, it will generate a function module from the recording
with all variables as parameters. 132

EDI and International Standards 137

17.1 EDI and International Standards .................................................................138
Electronic Data Interchange (EDI) as a tool for paperless inter-company
communication and basic instrument for e-commerce is heavily regulated
by several international standards. 138

17.2 Characteristics of the Standards.................................................................139
The well-known standards EDIFACT, X.12 and XML have similar characteristics
and are designed like a document description language. Other standards
and R/3 IDocs are based on segmented files. 139

17.3 XML................................................................................................................140
This is an excerpt of an XML EDI message. The difference to all other EDI
standards is, that the message information is tagged in a way, that it can be
displayed in human readable form by a browser. 140

17.4 ANSI X.12 ......................................................................................................142
This is an example of how an ANSI X.12 EDI message for a sales order looks
like. The examples do not show the control record (the "envelope"). EDIFACT
looks very much the same. 142

EDI Converter 143

18.1 Converter ..................................................................................................... 144
SAP R/3 has foregone to implement routines to convert IDocs into
international EDI standard formats and forwards those requests to the
numerous third party companies who specialize in commercial EDI and ecommerce
solutions.. 144

18.2 A Converter from Germany........................................................................ 145
In the forest of EDI converters there is only a very limited number of
companies who have actual experience with R/3. We have chosen one very
popular product for demonstration here. 145

Appendix 147

19.1 Overview of Relevant Transactions ............................................................ 147
There is a couple of transactions which you should know when working with
IDocs in any form. I suggest to call each transaction at least once to see,
what is really behind. 147

19.2 Useful Routines for IDoc Handling .............................................................. 148
These are some very useful routines, that can be used in IDoc processing. 148

19.3 ALE Master Data Distribution....................................................................... 149
The ALE functionality comes with a set of transaction which allow the
distribution of important master data between systems. The busiest argument
for installing ALE might be the distribution of the classification from
development to production and back. 149

19.4 WWW Links.................................................................................................... 150
These is a random listing of interesting web sites dealing with the EDI topic.
They are accurate as of November 1999. 150

19.5 Questionnaire for Starting an IDoc Project ................................................ 151
This is a sample questionnaire with important questions that need to be
cleared before any development can be started. 151

Index 153

Illustration 1: A typical EDI scenario from the viewpoint of R/3........................... 9
Illustration 2: Simplified Example of an IDoc control record for sales orders ..............12
Illustration 3: Simplified Example of an IDoc data record for sales orders ...... 12
Illustration 4: Schematic example of an IDoc control record............................ 14
Illustration 5: Example of an IDoc with one segment per line, an info tag to the left of each segment and the IDoc data to the right ..... 15
Illustration 6: Tables used to store the IDoc within R/3......................................... 17
Illustration 7: Step to customize outbound IDoc processing.............................. 38
Illustration 8: Elements that influence IDoc processing....................................... 39
Illustration 9: General Process logic of IDoc outbound....................................... 53
Illustration 10: Communicating with message via table NAST............................. 54
Illustration 11: Process logic of RSNAST00 ABAP ...................................................... 58
Illustration 12: Tables involved in change pointers processing............................ 64
Illustration 13: Sample content of view V_TBD62 .................................................... 64
Illustration 14: Schematic of an IDoc Outbound Process ..................................... 69
Illustration 15: R/3 port types by release................................................................... 77
Illustration 16: WORD 97 text with MACROBUTTON field inserted........................ 89
Illustration 17: Visual Basic code with macros to call R/3 from WORD 97 ......... 90
Illustration 18: ALE distribution scenario..................................................................... 97
Illustration 19: Scenario in tabular form..................................................................... 97
Illustration 20: Seeburger™ graphical EDI converter editor with R/3 linkage.................146

Directory of Programs

Program 1: Sample IDoc outbound function module...................................... 27
Program 2: Sample IDoc outbound function module...................................... 30
Program 3: Interface structure of an NAST compatible function module ............. 70
Program 4: Interface structure of an IDoc inbound function ......................... 70
Program 5: Routine to move the translate to IDoc data................................. 72
Program 6: Fill the essential information of an IDoc control record............... 72
Program 7: Z_READ_TEXT, a copy of function READ_TEXT with RFC enabled....... 82
Program 8: Program to copy text modules into a remote system via RFC ........... 83
Program 9: JavaScript example to call an R/3 function module via OLE/RFC............ 92
Program 10: This is the call of the type coupled event in release 40B........... 117
Program 11: This is the call of the change doc event in release 40B ............ 118
Program 12: This is the call of the type coupled event in release 40B........... 118
Program 13: A workflow handler that sends an Sap Office mail.................... 120
Program 14: Send a SAPoffice mail triggered by a workflow event (full example)........... 123
Program 15: Program ZZBDCRECXX (find at http://www.idocs.de)............... 131
Program 16: Program ZZBDCRECXX_FBGEN found on http://www.idocs.de......... 136
Program 17: XML Sales Order data....................................................................... 140

You must be Loged in to download file