Академический Документы
Профессиональный Документы
Культура Документы
ALE
ALE is a business solution to a very real need emerging in the SAP market. This is the need for businesses to move towards tighter integration between systems, yet, at the same time, provide independence to the various business units within the company. In the past the move was towards centralized systems Standardization of business processes accompanied by ever tighter integration within the central system no longer represents a practicable approach to this problem. The following are some of the most commonly encountered difficulties: technical bottlenecks upgrade problems the effect of time zones on international Corporations excessively long response times in large centralized systems
IDoc INTERFACE
Business data is exchanged with an external system using the IDoc Interface. The IDoc Interface consists of the definition of a data structure and a processing logic for this. The data structure is the IDoc. It is the exchange format that unites the communicating systems. Using IDocs you can define an exception handling within the R/3 System using SAP Business Workflow, without the need for the data to already be an SAP application document. You require the IDoc Interface in the following scenarios: Electronic Data Exchange (EDI) Application Link Enabling (ALE) Linking to any other business application systems (for example, PC applications, external workflow tools) using IDoc.
What is an IDoc ?
The term IDoc stands for Intermediate Document. Its not a process. An IDoc is simply a data container that is used to exchange information between any two processes that can understand the syntax and semantics of the data. An IDoc is created as a result of execution of an outbound ALE or EDI process. In an inbound ALE or EDI process, an IDoc serves as an input to create application document. IDocs are independent of sending and receiving system. They can be used for SAP to SAP and SAP to non-SAP process communications as long as the participating processes can understand the syntax and semantics of the data.
IDocs are independent of the direction of data exchange.An IDoc can be used by an inbound as well as an outbound process. For e.g the ORDERS01 IDoc is used by the purchasing module to send a purchase order and is also used by the sales and distribution module to accept a sales order. This avoids creating redundant IDoc types for the same information.
ID o c C o n c e p t
A s y n c h ro n o u s D o c u m e n t-r e la te d
S y s te m 1
SAP Docum ent
S y s te m 2 ID o c
D ocum ent T ra n s a c tio n M essage
R /3 S y s te m
EDI R /3 R /2 3 rd
s u b s y s te m S y s te m S y s te m p a rty s o ftw a re
S A P A G 1 9 9 9 I D o c E n jo y ( T h . B e c k e r ) / 5
The business data is saved in IDoc format in the IDoc interface and is forwarded as IDocs. If an error occurs, exception handling is triggered via workflow tasks. The agents who are responsible for these tasks and have the relevant authorizations are defined in the IDoc interface. The IDoc interface supports three types of data flow with the external system: Outbound Processing IDocs are transferred to a receiving system from your SAP System Inbound Processing IDocs are transferred to your SAP System from an upstream system. Status Processing The receiving system confirms the processing status of outbound Idocs to your SAP System.
Outbound
Application
Data
MM SD ...
Inbound
Application
Message Control
Workflow
IDoc
System 2
e.g. EDI subsy stem
System 2
e.g. EDI subsy stem
10
SAP Applicatio n
Document
11
SAP application
12
13
Following are the benefits of IDocs over Flat files. Independence from Applications The biggest advantage of using the IDoc interface is that its an open interface i.e independent of the internal structure used by SAP to store data and independent of sending and receiving applications. Communication with Back-Level IDocs The standard IDocs and the segments within the IDoc have a version associated with them.Each time a standard IDoc or a segment is enhanced, the system assigns it a newer version. Partner applications that were developed using a previous version of the IDocs are fully supported. SAP can generate and process back-level IDocs. This version management technology offers backward compatibility.
14
Custom IDocs are distinguished from SAP IDocs by their names, as they start with Z. Standard Monitoring Tools Several tools are available to monitor the state of the system. They range from simple IDoc display to IDoc statistics. IDoc type Documentation Each IDoc in the system is thoroughly documented .The usage is detailed down to the field level with possible values for each field and how it affects the process. The documentation of any IDoc can be obtained using transaction WE60. Archiving Tools Tools are available for miscellaneous tasks such as archiving , data cleanup and restoring information back into SAP.
15
USE OF IDocs
EDI integration EDI is electronic exchange of business documents between SAP and non-SAP systems. Several applications ( purchasing, sales or shipping ) in SAP are enabled for EDI. To use EDI first the application document viz.. purchase order is created. EDI interface layer converts the application document into an IDoc which is transferred to an EDI subsystem.The EDI subsystem translates the IDoc into an industry-standard format and then transfers it to a business partner over a network. ALE Integration ALE (Application Link Enabling) enables the exchange of data between two SAP systems.This system allows SAP businessprocesses and applications to be distributed across multiple SAP systems.ALE ensures integration in a distributed SAP environment.
16
OCR Application integration OCR( Optical Character Recognition ) is a technology that scans and interprets printed matter using pattern recognition. You can integrate an OCR application with SAP via IDocs. Documents in a standard format can be scanned to generate IDocs, which then can be transferred to the SAP system for processing. ICR Application integration Bar-code system is an example ICR ( Intelligent Character Recognition ) technology. Data encoded using bar-codes can be captured and stored as an IDoc, which then can be passed to SAP for further processing.
17
18
The best way to explain the IDoc architecture is to compare your legacy world to how SAP implements the same concept in IDoc.
Lname(10)
Fname(10)
SSN(11)
DOB(8)
Employee header occurs once mandatory Work des.(50) Weekly details multiple
Hrly rate(3)
Client site(20)
Summary once
Assume that you have an application that records an employees weekly hours . At the end of the month, a file containing the monthly report data for each is sent to external system. This application has been replaced by the SAP system , and a standard IDoc has been developed to support the process.
19
Following are some properties of the file: It has three types of records: employee header information, weekly details and monthly summaries. Each record type has certain properties ,such as whether its optional or mandatory, number of times it can be repeated, field names, data type for each field, and length of each field. The client site and work description in the weekly details is not always available.
20
Segments
Fname SS N Dob
We ek n o
Hrly Rate
Tot Hrs
Clsite
W or k de sc.
Tot hrs
Tot amount
21
Comparison
Smith 1 2 3 4
John 30 30 30 50
123-45-6789 102668 40 Houston Brewery 40 Network Computers 50 Network Computers 60 DSP Systems
140
6900
22
IDoc DEFINITION COMPONENTS Name: A basic IDoc type can be assigned up to a thirty-character name in release 4.0 onwards. To encompass all releases we have used an 8 character name ZMREPT01. Custom IDoc types always start with Z the last two character represents the version number.After a basic IDoc type is released and you move to a newer version of the SAP system, any changes to the structure of the basic IDoc type will create a new basic IDoc type i.e the version number is incremented by 1. Thus ZMREPT02 represents an enhanced version of this IDoc. Segments of a previous version are never deleted. This is necessary to maintain backward compatibility.
23
List of permitted segments: These segments make up the IDoc structure. The current example has four segments: Z1EMHDR, Z1WKDET , Z1CLDET and Z1SUMRY.
Arrangement of segments: Arrangement specifies the physical sequence and any parent-child relationship in the segments. A parent-child relationship signifies that the child segment cannot exist without the parent and is commonly used for text segments. It gives an IDoc type a hierarchical structure.
24
Mandatory versus Optional segments: When used in an IDoc type,each segment has an attribute that defines whether the segment is optional or mandatory. In the example given, Z1EMHDR is a mandatory segment because the monthly report will not make sense without the employees basic information. Minimum / Maximum range for each segment: Each segment has an attribute that defines the minimum and the maximum number of times a data record corresponding to a segment can exist in an IDoc. In the example given, data records corresponding to the Z1WKDET segment can occur multiple times.
25
SEGMENTS A segment defines the format and structure of a data record. Segments are reusable components, which means they can be used in more than one IDoc type. A segment consists of various fields that represent data in a data record. Segment Components A segment in the SAP system is technically implemented as three physically separate pieces. 1) Segment type This is version independent name of the segment. SAP provided segment types begin with E1, whereas custom-defined segment types begin with Z1. In the example Z1EMPHDR and Z1WKDET are segment types.
26
2) Segment definition This is version dependent definition of a segment where you specify the fields that belong to the segment. SAP segment definitions start with E2, whereas customer segment definitions start with Z2. The name of a segment definition is 10 characters long and is automatically assigned by the system from the name of the segment type. For e.g for the segment type E1EDKA1, the segment definition is E2EDKA1. The last three characters represent the version of the segment.The first segment definition has spaces in last three characters.The last three characters are incremented by 1 to reflect the new definition.
27
Z2TEST001
Z2TEST002
28
3) Segment Documentation This represents the data dictionary documentation for each field in the segment definition.Segment documentation of SAP-provided segments begins with E3, whereas the segment documentation of customer-defined segment types with Z3. There is only one segment documentation per segment.
29
IDoc RUN TIME COMPONENTS: Although there are several records in an IDoc,they are still classified as one of the three record type. Control Record Data Record Status Record At run time the following events occur:A unique IDoc number is allocated. One control record is attached to the IDoc. Segments translate into data records. Status records are attached. Syntax rules are checked.
30
31
Control Record
IDoc-ID Sender-ID Receiver-ID IDoc type and logical message External structure IDoc-ID Sequence/Hierarchy Segment Format definition for
header data item data
Data Record
Status Record
32
Control Record As the name suggests contains all of the control information about an IDoc, this basically includes IDoc number, sender and receiver information such as the message type it represents and the IDoc type. A control record can be compared to an envelope of a letter,by looking at the envelope,you can identify the sender and the recipient. It has following characteristics There is one and only one control record per IDoc. The structure of the control record is the same for all Idocs and is defined by SAP. It is stored in EDIDC table
34
35
Data Records In an IDoc, data records contain the application data.The employee header information,weekly details,client details and summary information reside in data records. A data record has two parts: an administrative section and a data section. Administrative section contains the segment name,segment number and hierarchy level. Data section is where the actual data resides.This is mapped to a segment type. Data records are stored in the EDIDD table. The complete documentation of the data record can be viewed by using transaction WE61.
36
Status Record These are attached to an IDoc throughout the process as the IDoc achieves different milestones. At every milestone a status code,date and time are assigned. The latest status code is also maintained in the control record. Status records have following characteristics:Multiple status records are usually attached to an IDoc. In outbound processes, after the IDoc is passed from SAP to the subsystem,the subsystem generates the status records and passes them to SAP. For inbound processes,SAP generates the status records. List of status code and there details can be seen by executing transaction WE47.
37
38
ID o c T y p e s
C o n tro l R e c o rd D a ta R e c o rd s
E1H D D O C M 1 E1H D A D R C 5 E 1 IT D O C M 1 E 1 IT S C H E1TLSUM C 1
T re e o f S e g m e n ts
S ta tu s R e c o rd s
99
S A P A G 1 9 9 9 ID o c E n jo y (T h . B e c k e r) / 7
39
Enhancing the performance by restricting the number of tables read Reducing the data volume in internal tables at run time
40
ALE Configuration :1. Setting Up Clients 2. Defining Logical System Names for Clients 3. Defining Communication Parameters 4. Modeling the Distribution 5. Generating Partner Profiles in the Sending System 6. Distributing the Distribution Model 7. Generating Partner Profiles in the Receiving System 8. Creating Vendor Master Data 9. Sending Vendor Master Data 10.Checking Processing Status
41
Setting Up Clients
Set up two clients to enable communication between logical systems. The two clients may be located in the same R/3 System or in separate systems. To set up a new client, from the SAP standard menu choose Tools -> Administration -> Administration -> Client administration -> Client maintenance.
42
SETTING UP CLIENTS
43
44
45
46
47
48
49
50
51
52
53
54
55
you have copied the distribution model to the receiving system, you can also generate the partner profiles here. To do this, log on to the receiving logical system (for example, LOGSY500 ). In the R/3 Implementation Guide under Basis Components, choose: Application Link Enabling (ALE) -> Modeling and Implementing Business Processes -> Partner Profiles and Processing Time -> Generate Partner Profiles Enter the name of your distribution model view, in this case, VENDMODEL. Without changing the parameters proposed by the system, execute the program. The required partner profiles will be generated in the receiving system.
56
57
58
You are now going to send the vendor you have just created to the receiving system. Choose TOOLS-> ALE -> MASTERDATADISTRIBUTION -> -> CROSS APPLICATION-> VENDOR -> SEND Enter the vendorl you have created (for example, Vendor001). Use CREMAS Message type: Enter LOGSY500, the logical receiving system Execute the program. You should now be able to display your vendor in the receiving system. If the material is not available here, either the transmission has not yet finished or an error has occurred. The next step shows you how to check the communication and detect any errors.
59
60
61
OUTBOUND IDocs Status 03, 12, 38 02, 04, 05, 25 ,26, 29 30 >=50 Other Description of Status IDoc successfully transferred Processing error Waiting status (still processing...) Inbound IDoc (not relevant in this context) Not relevant in this context
62
63
INBOUND IDocs Status 53 64 <50 51, 56, 60, 61, 63, 65 Other Not relevant in this context Description of Status IDoc successfully updated by application Waiting status (still processing...) Outbound IDoc (not relevant in this context) Inbound error
64
65
To display a list of IDocs with a particular status, double-click on a line. For detailed information on one of these IDocs, double-click on it. If an error occurs, you can display information about the cause of it by choosing Process -> Incorrect segments.
Error Handling
If an error has occurred, use the monitoring function to resolve it. The cause of the error is likely to be a value in your material that the receiving system does not know and therefore cannot process it. Try to eliminate the cause of the error and send your material again. If your IDoc in the sending system was successfully transferred (status 03) but does not appear in the receiving system, a technical communication error is the likely cause. You can use the status monitor in the sending system to check this. Choose Goto -> Transactional RFC -> Display calls. If an error occurs you should consult your system administrator.
66
Transaction codes for ALE and IDoc:SALE SM59 BD64 BD82 BD10 BD11 WE31 WE30 WE41 WE40 WE81 for defining and assign logical systems RFC destination Customer distribution model. Generating Partner Profile Sending Material Getting the material Segment creation Idoc Type creation Process code for Outbound Process code for Inbound Creating Message types
67
Thanks
68