The Sap R/3 Guide to Edi and Interfaces: Cut Your Implementation Cost With Idocs, Ale, and Sapscript

by Angeli, Axel; Streit, Ulrich; Gonfalonieri, Robi

• ISBN13: 9783528057299
• ISBN10: 3528057297
• Edition: 2nd
• Format: Hardcover
• Copyright: 2000-04-01
• Publisher: Morgan Kaufmann Pub

Summary

SAP R/3 made an old dream come true: enter your business data once in your computer and trigger all the following activities automatically, and send the data to another computer without typing them in again. This book is for whole R/3 teams to teach a common knowledge when it comes to interface design: project managers, steering committees, developers, and coaches.

Table of Contents

Where Has the Money Gone?	1	(6)
Communication	2	(1)
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)
Psychology of Communication	3	(1)
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)
Phantom SAP Standards and a Calculation	4	(1)
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)
Strategy	5	(1)
Do not loose your time in plans. Have prototypes developed and take them as a basis.	5	(1)
Who Is on Duty?	5	(1)
Writing interface programs is much like translating languages. The same rule apply.	5	(1)
Marcus T. Cicero	6	(1)
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	(1)
What Are SAP R/3 IDocs?	7	(4)
What are IDocs?	8	(1)
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	(1)
Exploring a Typical Scenario	9	(2)
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	(2)
Get a Feeling for IDocs	11	(7)
Get A Feeling For IDocs	12	(2)
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	(2)
The IDoc Control Record	14	(1)
The very first record of an IDoc package is always a control record. The structure of this control record is the DDic structureEDIDC and describes the contents of the data contained in the package.	14	(1)
The IDoc Data	15	(1)
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.	15	(1)
Interpreting An IDoc Segment Info	16	(1)
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	(1)
IDoc Base - Database Tables Used to Store IDocs	17	(1)
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	(1)
Exercise: Setting Up IDocs	18	(5)
Quickly Setting up an Example	19	(1)
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	(1)
Example: The IDoc Type MATMASO1	20	(1)
To sharpen your understanding, we will show you an example of an IDoc of type MATMASO1, which contains material master data.	20	(1)
Example: The IDoc Type ORDERSO1	21	(2)
To allow an interference, here is a sample of IDoc type ORDERSO1 which is used for purchase orders and sales orders.	21	(2)
Monitoring IDocs	23	(2)
Sample Processing Routines	25	(6)
Sample Processing Routines	26	(1)
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	(1)
Sample Outbound Routines	27	(2)
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	(2)
Sample Inbound Routines	29	(2)
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	(2)
IDocs Terminology	31	(6)
Basic Terms	32	(1)
There are a couple of expressions and methods that you need to know, when dealing with IDoc.	32	(1)
Terminology	33	(4)
Message Type - How to Know what the Data Means	33	(1)
Data exchanged by an IDoc via EDI is known as message. Messages of the same kind belong to the same message type.	33	(1)
Partner Profiles - How to Know the Format of the Partner	33	(1)
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	(1)
IDoc Type - The Structure of The IDoc File	34	(1)
The IDoc type is the name of the data structure used to describe the file format of a specific IDoc.	34	(1)
Processing Codes	34	(1)
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	(3)
IDocs Customizing	37	(14)
Basic Customizing Settings	38	(2)
Segments define the structure of the records in an IDoc. They are defined with transaction WE31.	38	(2)
Creating An IDoc Segment WE31	40	(3)
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	(3)
Defining The Message Type EDMSG	43	(1)
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	(1)
Define Valid Combination Of Message and IDoc Types	44	(1)
The valid combinations of message type and IDoc type are stored in table EDIMSG.	44	(1)
Assigning a processing function (Table EDIFCT)	45	(1)
The combination of message type and IDoc type determinite 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	(1)
Processing Codes	46	(2)
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	(2)
Inbound Processing Code	48	(3)
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	(3)
IDoc Outbound Triggers	51	(14)
Individual ABAP	52	(2)
The simplest way to create IDocs, is to write an ABAP which simply does it.	52	(2)
NAST Messages Based Outbound IDocs	54	(2)
You can use the R/3 message concept to trigger IDocs the same way as you trigger SapScript printing.	54	(2)
The RSNASTOO ABAP	56	(1)
The ABAP RSNASTOO is the standard ABAP, which is used to collect unprocessed NAST message and to execute the assigned action.	56	(1)
Sending IDocs Via RSNASTED	57	(1)
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	(1)
Sending IDocs Via RSNASTOO	58	(1)
Here is the principle flow how RSNASTOO processes messages for IDocs.	58	(1)
Workflow Based Outbound IDocs	59	(1)
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	(1)
Workflow Event From Change Document	60	(1)
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	(1)
ALE Change Pointers	61	(1)
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	(1)
Activation of change pointer update	62	(1)
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	(1)
Dispatching ALE IDocs for Change Pointers	63	(2)
Change pointers must be processed by an ABAP, e.g. RBDMIDOC.	63	(2)
IDoc Recipes	65	(8)
How the IDoc Engine Works	66	(1)
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	(1)
How SAP Standard Processes Inbound IDocs	67	(1)
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	(1)
How To Create the IDoc Data	68	(2)
R/3 provides a sophisticated IDoc processing framework. This framework determines a function module, which is responsible for creating or processing the IDoc.	68	(2)
Interface Structure of IDoc Processing Functions	70	(1)
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	(1)
Recipe To Develop An Outbound IDoc Function	71	(1)
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	(1)
Converting Data into IDoc Segment Format	72	(1)
The physical format of the IDocs records is always the same. Therefore the application data must be converted into a 1000 character string.	72	(1)
Partner Profiles and Ports	73	(6)
IDoc Type and Message Type	74	(1)
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	(1)
Partner Profiles	75	(1)
Partner profiles play an important role in EDI communications. They are parameter files which store the EDI partner dependent information.	75	(1)
Defining the partner profile WE20	76	(1)
The transaction WE20 is used to set up the partner profile.	76	(1)
Data Ports (WE21)	77	(2)
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	(2)
RFC Remote Function Call	79	(8)
What Is Remote Function Call RFC?	80	(1)
A Remote Function Call enables a computer to execute a program an another computer. The called program is execute locally on the remote computer using the remote computer's environment, CPU and data storage.	80	(1)
RFC in R/3	81	(1)
RFC provides interface shims for different operating systems and platforms, which provide the communication APIs for doing RFC from and to R/3.	81	(1)
Teleport Text Documents With RFC	82	(2)
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	(2)
Calling A Command Line Via RFC?	84	(3)
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	(3)
Calling R/3 Via OLE/JavaScript	87	(8)
R/3 RFC from MS Office Via Visual Basic	88	(1)
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	(1)
Call Transaction From Visual Basic for WORD 97	89	(2)
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	(2)
R/3 RFC from JavaScript	91	(2)
JavaScript is a fully objected oriented language. Therefore you can easily connected from JavaScript to R/3 via the CORBA compatible object library (in WINDOWS known also DLLs or ACTIVE-X (=OLE/2) components).	91	(2)
R/3 RFC/OLE Troubleshooting	93	(2)
Problems connecting via RFC can usually be solved by reinstalling the full SAPGUI and/or checking your network connection with R/3.	93	(2)
ALE - Application Link Enabling	95	(20)
A Distribution Scenario Based On IDocs	96	(1)
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	(1)
Example ALE Distribution Scenario	97	(1)
To better understand let us model a small example ALE scenario for distribution of master data between several offices.	97	(1)
ALE Distribution Scenario	98	(1)
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	(1)
Useful ALE Transaction Codes	99	(2)
ALE is customized via three main transaction. These are SALE, WEDI and BALE.	99	(2)
ALE Customizing SALE	101	(1)
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	(1)
Basic Settings SALE	102	(1)
Basic settings have do be adjusted before you can start working with ALE.	102	(1)
Define The Distribution Model (The ``Scenario'') BD64	103	(2)
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	(2)
Generating Partner Profiles WE20	105	(4)
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	(4)
Creating IDocs and ALE Interface From BAPI SDBG	109	(4)
There is a very powerful utility which allows to generate most IDoc and ALE interface objects directly from a BAPI's method interface.	109	(4)
Defining Filter Rules	113	(2)
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	(2)
Workflow Technology	115	(10)
Workflow in R/3 and Its Use For Development	116	(1)
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	(1)
Event Coupling (Event Linkage)	117	(1)
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	(1)
Workflow from Change Documents	118	(1)
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	(1)
Trigger a Workflow from Messaging	119	(1)
The third common way to trigger a workflow is doing it from messaging.	119	(1)
Example, How To Create A Sample Workflow Handler	120	(5)
Let us show you a function module which is suitable to serve as a function module and define the linkage.	120	(5)
Batch Input Recording	125	(12)
Recording a Transaction With SHDB	126	(3)
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	(3)
How to Use the Recorder Efficiently	129	(1)
This routine replaces BDCRECXX to allow executing the program generated by SHDB via a call transaction instead of generating a BTCI file.	129	(1)
Include ZZBDCRECXX to Replace BDCRECXX	130	(2)
This routine replaces BDCRECXX to allow executing the program generated by SHDB via a call transaction instead of generating a BTCI file.	130	(2)
ZZBRCRECXX_FB_GEN: Generate a Function from Recording	132	(5)
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	(5)
EDI and International Standards	137	(6)
EDI and International Standards	138	(1)
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	(1)
Characteristics of the Standards	139	(1)
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	(1)
XML	140	(2)
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	(2)
ANSI X.12	142	(1)
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	(1)
EDI Converter	143	(4)
Converter	144	(1)
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	(1)
A Converter from Germany	145	(2)
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	(2)
Appendix	147	(6)
19.1 Overview of Relevant Transactions	147	(1)
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	(1)
19.2 Useful Routines for IDoc Handling	148	(1)
These are some very useful routines, that can be used in IDoc processing.	148	(1)
19.3 ALE Master Data Distribution	149	(1)
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	(1)
19.4 WWW Links	150	(1)
These is a random listing of interesting web sites dealing with the EDI topic. They are accurate as of November 1999.	150	(1)
Questionnaire for Starting an IDoc Project	151	(2)
This is a sample questionnaire with important questions that need to be cleared before any development can be started.	151	(2)
Index	153