ale_idocs session ppt
Post on 06-Feb-2016
236 Views
Preview:
DESCRIPTION
TRANSCRIPT
AN INTRODUCTION TO EDI, ALE AND IDOCS ObjectivesGet introduced to the basic concepts of EDI
Learn about ALE technology
Understand about IDOCs
Inbound processing
Outbound processing
Filtering and Conditions
Prepared by: Ajith Jesuwaram
The Basics of EDI
Electronic Data Interchange The exchange of business related documents between the systems
of business partners Also called as paperless exchange It is sent over a communication network It has a standard format
Benefits of using EDI Process
Reduction of errors in data entry Reduction in the Processing cycle time Data available in electronic form Reduction of paper work Less cost Lesser Inventories and a much better planning Communication by Standard Means Much better Business Processes
SAP EDI Architecture
SAPEDI sub-
systemIDOC
Status
EDImessag
e
IDOC
SAP EDI
EDI sub-system
Non-SAP ERP system
EDImessag
e
Application
messages
VAN
Outbound Process
Inbound Process
Basic Concepts of ALE
Basics of ALE ALE architecture Benefits of all ALE Process Difference between EDI & ALE
What is ALE? Application Linking and Enabling SAP’s own technology To support distributed yet integrated processes Based on application-to-application integration Has IDOCs as the data containers
ALE Architecture
Outbound process (from SAP to another SAP or non-SAP system)
Inbound process (from one SAP or non-SAP to a SAP system)
Outbound Process
Inbound Process
ALE versus EDI
ALE EDI
Data transfer between SAP systems.Data transfer between any two systems.
Used for internal communication Used for external communication
To distribute the master data. To exchange transaction data.
Data transfer using memory buffers. Data transfer using file ports.
Translator not required. Translator always required.
No sub-system. Sub-system present.
Used between SAP and systems within the company.
Used between SAP and the customers/vendors.
What is an IDOC?
Intermediate Document A Container used to exchange Data / Information between
two processes which are capable of understanding the syntax & semantics of the data.
It is of 2 types – Inbound IDOC & Outbound IDOC Created when we execute an outbound ALE or EDI Process In Inbound ALE or EDI process, an IDOC acts as input for creating
an Application Document. In SAP Systems, IDOCs are stored in the database. Every IDOC has an unique number (within a client). IDOCs are independent of the sending system & the receiving
system. Data is stored in the character format and not in binary format.
IDOC Structure
The IDOC structure consists of 3 parts
• Administration part - has the type of IDOC, message type, the current status, the sender, receiver etc. This is referred to as the Control record.
• Application data - contains the data. These are called the data records/segments.
• Status information - contains information about the various stages the IDOC has passed through.
IDOC Structure
Control record
Data record
Status record
Basic IDOC Type (WE30)
Basic IDOC Type
This defines the format and structure of the business document that is set to be exchanged.
IDOC Type has a specific name list of permitted segments hierarchy of segments mandatory/optional segments minimum/maximum range of each segment.
Basic IDOC Type (WE30)
Screenshot of WE30 transaction
IDOC Components (WE31)
Segments The segment defines the format & the structure of a data record.
Contains the fields which represent the data.
Can be reused across different IDOC types.
For each segment SAP creates Segment Type (version independent) Segment Definition (version dependent) Segment Documentation
The last 3 characters are the version of the segment
As per the version the definitions keep changing but the segment type remains the same
IDOC Segment - PIC
Screenshot of WE31 transaction
IDOC Run-Time Components
An IDOC is an instance of an IDOC Type (standard/ customized)
Events that occur at run time are as follows; A unique IDOC number is allocated by SAP One control record is attached to the IDOC Segments translate into data records Status records are attached Syntax rules are checked.
Each IDOC has 3 parts• The Control Record• The Data Record• The Status Record
We02 or We05 is used to display an IDOC.
IDOC Run-Time Components (contd.)
Screenshot of WE02/ WE05 transaction
IDOC Runtime components (Contd)
Control Record Contains the control information Has the same structure across IDOCs First record in any IDIC only 1 control record exists for any IDOC Stored in EDIDC table. We61 – documentation of the control record
Data Record This Contains application data. Stored in EDID4 tables. Actual data is stored in the form of a string in a field called SDATA
(1000 character length) Contains 2 sections
Administrative section Data section
Multiple data records can exist in an idoc
IDOC Runtime components (Contd)
Status Record • Displays the status of an IDOC• Gets attached to the IDOCs at every milestone / processing or
when it encounter errors.• Stored in EDIDS table.• Multiple status records can exist for any idoc• Statuses 1-49 for outbound, above 50 for inbound• We47 – list of status codes
Syntax Rules for an IDOC• Only valid segments as defined in the IDOC type are allowed• Mandatory segments must exist.• Data records have a limit defined for the number of repetitions• Must have the same physical sequence as in IDOC structure• Child segment cannot exist without parent.
Extending an Existing IDOC Type
Used when additional information is required in addition to what is supplied by the Standard IDOC Type.
The addition of custom segments.
Create the IDOC type as an Extension in transaction WE30.
Specify the basic type for which it will be an extension.
None of the SAP Standard segments can be deleted or changed.
Add custom segments as children to existing ones (transaction WE31).
Only new data fields have to be added to the custom segment.
WE30 Screenshot for an extended IDOC
THANK YOU
top related