Day 13_Introduction_to_EDI_ALE_and_IDOCs_Story_board.ppt

An Introduction to EDI, ALE and IDOCsGet introduced to the basic concepts of EDILearn about ALE technologyUnderstand what are IDOCsHow to go about with the configurations related to IDOCs

Course Objectives

*

What is EDI ?Electronic Data Interchange

The exchange of business related documents between the systems of business partners

It has a standard format

It is sent over a communication network

Also called as paperless exchange

And it uses ANSI , ASC X12 and EDIFACT standards.Unit I : The Basics of EDI

*

Components of EDI process

Application Programs These are responsible for generating and processing the data present in the business documents.

Translators Used to map Application data to the EDI standard format & vice versa.

VAN Network that provides a means for transmitting the EDI transactions.

Fig: Components of the EDI system

*

Overview of SAP EDI Architecture - PICSAP only provides the application logic, the application data & the format for the data contents. Most of the other systems are provided by 3rd party Vendors.Fig: SAP EDI boundaries

*

Outbound ProcessFor outbound processes, a separate selection program reads the application data and creates an IDOC. This comprises of 6 steps.

The IDOC is generated.

The IDOC is transferred from SAP to the Operating system layer

The IDOC is converted to the EDI standardsThe EDI document is transmitted to the business partner

The EDI subsystem reports status to SAP.

The application document is created

*

Inbound Process

The EDI transmission is received.

The EDI document is converted into an IDOC.

The IDOC is transferred to the SAP layer.

The application document is created.

The application document can be viewed.

For inbound processes, a posting program reads the IDOC data and creates the application document. This comprises of 5 steps.

*

Benefits un using EDI Process

Reduction of errors in data entryReduction in the Processing cycle timeData available in electronic formReduction of paper workLess costLesser Inventories and a much better planningCommunication by Standard MeansMuch better Business Processes

*

Unit ObjectivesAfter this session you would be able to understand the following;Basics of ALEALE architectureBenefits of all ALE ProcessDifference between EDI & ALEUnit 2 : Basic Concepts of ALEWhat is ALE?Application Linking and EnablingSAPs own technologyTo support distributed yet integrated processesBased on application-to-application integrationHas IDOCs as the data containers

*

Has three processes

Outbound process (from SAP to another SAP or non-SAP system)

Inbound process (from one SAP or non-SAP to a SAP system)

Exception handling processALE Architecture

*

Outbound Process

*

Inbound Process

*

Can be network problems or data problemsHandled using workflowsCan determine at run-time the person who has to be informedErrors are fixed outside the workflowProcess can be started again from the point of failureBenefits of ALEEfficient and reliable communicationSupports distributed yet integrated systemsIntegration with non-SAP systemsBackward compatibility of messagesException-handling Process

*

ALE versus EDI

ALEEDIData transfer between SAP systems.Data transfer between any two systems.Used for internal communicationUsed for external communicationTo 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.

*

Unit ObjectivesAfter this session you must be able to understand the following;

Basic concept of IDOCsThe structure of an IDOCConcept of segmentsComponents of an IDOCExtending an IDOCThe applications of IDOCsAdvantages of using IDOCs

Unit 3 : What is an IDOC?

*

What is an IDOC?Intermediate DocumentA 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 IDOCCreated when we execute an outbound ALE or EDI ProcessIn 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. Based on the EDI standards, they are ANSI ASC X12 and EDIFACT. Independent of the direction of data exchange Can be viewed in a text editorData is stored in the character format and not in binary format.

*

IDOC Structure PICControl recordData recordStatus 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 namelist of permitted segmentshierarchy of segmentsmandatory/optional segmentsminimum/maximum range of each segment.

*

Basic IDOC Type (WE30) - PICParent segmentChild segment Screenshot of WE30 transactionSource: Screen Shot from SAP ECC 5.0.

*

IDOC Components (WE31)SegmentsThe 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 - PICSegment nameSegment DefinitionVersion of the segmentData fields Screenshot of WE31 transactionSource: Screen Shot from SAP ECC 5.0.

*

IDOC Run-Time ComponentsAn 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 SAPOne control record is attached to the IDOCSegments translate into data recordsStatus records are attachedSyntax rules are checked.

Each IDOC has 3 partsThe Control RecordThe Data RecordThe Status Record

We02 or We05 is used to display an IDOC.

*

IDOC Run-Time Components (contd.)Idoc numberControl recordLast status of IdocDirection 1 indicates outbound IDOC, 2 indicates inbound IDOC

Data recordsStatus records Screenshot of WE02/ WE05 transactionSource: Screen Shot from SAP ECC 5.0.

*

IDOC Runtime components (Contd)Control RecordContains the control informationHas the same structure across IDOCsFirst record in any IDIC only 1 control record exists for any IDOCStored in EDIDC table.We61 documentation of the control recordData RecordThis 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 sectionsAdministrative sectionData sectionMultiple data records can exist in an idoc

*

IDOC Runtime components (Contd)Status Record Displays the status of an IDOCGets attached to the IDOCs at every milestone / processing or when it encounter errors.Stored in EDIDS table.Multiple status records can exist for any idocStatuses 1-42 for outbound, 50-75 for inboundWe47 list of status codes

Syntax Rules for an IDOCOnly valid segments as defined in the IDOC type are allowedMandatory segments must exist.Data records have a limit defined for the number of repetitionsMust have the same physical sequence as in IDOC structureChild segment cannot exist without parent.

*

Extending an Existing IDOC TypeUsed 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.

*

An Extended IDOCExtension to the Basic idoc typeBasic segmentsExtended segments Screenshot of WE30 transactionSource: Screen Shot from SAP ECC 5.0.

*

IDOC Applications

EDI IntegrationALE IntegrationLegacy System IntegrationThird-party product IntegrationWorkflow IntegrationInternet and XML IntegrationOCR Application IntegrationICR Application IntegrationBenefits of an IDOC InterfaceIndependence from applicationsCommunication using older-version IDOCsException handling using WorkflowsCan be enhancedBetter monitoring tools availableImproved ease of useGreater robustness

*

Block Diagram for steps in the Outbound ProcessCreate Segments(WE31)Create message Type (WE81)Associate Function Module to outbound process code (WE41)Create Function ModuleAssociate message type with Idoc type(WE82)Create partner profile (WE20)Create Idoc Type(WE30)Create port(WE21)Trigger an IdocCheck Idoc status (WE02/WE05/WE09)Unit 4 : How to configure an IDOC interface?

*

Message Types (WE81) - PICA message represents a specific type of document that is transmitted between two partners.Examples are Orders, orders responses, invoices etcAn idoc type can be associated with many message types A message type can be associated with different idoc types

*

Message Types Screenshot of NACE transactionSource: Screen Shot from SAP ECC 5.0.

*

Creating function module/program to create an idocIf message control is usedmake a copy of the standard function modules that are named as IDOC_OUTPUT* where * is _If message control is not used Populate the control and data recordsCall the function module MASTER_IDOC_DISTRIBUTE.

*

Creating Outbound Process Code (WE41) Process of assigning a function module to a Partner in Partner Profile.Function Module is assigned to the Process Code Go to Transaction WE41.Switch to Change Mode and click New Entries.Enter the Process Code Name & assign the Function Module created.In the view VEDI_TMSG1 associate the process code and the message type to get F4 help in the partner profile

*

Creating Outbound Process Code (WE41) PIC Screenshot of WE41 transactionList of possible process codesSource: Screen Shot from SAP ECC 5.0.

*

Port (WE21)Defines the technical characteristics of the established connectionDefines the medium of data transfer between two systemsIt serves to determine Name of the EDI sub-system program (if installed)Directory path where the idoc file will be createdIDOC file namesRFC destinationTransaction WE21Client-independent

*

Port (WE21)Available portsPort descriptionPort name Screenshot of WE21 transactionSource: Screen Shot from SAP ECC 5.0.

*

Partner Profiles (WE20)Defined for every business partnersUsed to maintain the parameters that are necessary for exchanging dataIt specifies the following Characteristics of the data to be exchangedMode of operationPerson/ organization responsible for error handling for that partnerTransaction used is WE20.

*

Partner Profile (General Parameters View) Screenshot of WE20 transactionClick on the particular Logical systemClick on the message controlClick on the particular Logical systemSource: Screen Shot from SAP ECC 5.0.

*

Creating Partner Profile (WE20)Steps to create Partner ProfileGoto Transaction WE20. Click on Create Button. Enter the Partner Number & the Partner Type. Save the Data. For Outbound Partner Profile, we will have to create the Outbound Parameters. Press the add entry button under outbound parameters. Specify Partner Function, Message type created, Port, Basic Type and Output mode If using message control, goto Message Control Tab and link the Message Type and Process Code created.Save.

*

Triggering the Idoc

Through message controlIn the transaction to create/change the application data (SO, PO, etc), go to Messages, add the new Message Type to the list & save the documentPrograms are usually FMs linked to the application data.An IDOC will be created and will be sent to the portThrough stand alone programs Triggered using the function module MASTER_IDOC_DISTRIBUTEUsing change pointersIf changes are made to any fields maintained in BDCP and BDCPS tablesA job for program RBDMIDOC is scheduled

*

Check the status of IDOC (WE02/ WE05/ WE09)Status can be seen in the status record of the IDOC

If the status is 03 then it means that the IDOC is passed to the Port successfully.

*

IDOC Status (WE02/ WE05/ WE09) Screenshot of WE02 transactionSource: Screen Shot from SAP ECC 5.0.

*

Block Diagram for Steps in Inbound ProcessCreate Segments(WE31)Create message Type (WE81)Define function module characteristics(BD51)Create Function Module (SE37)Associate message type with Idoc type(WE82)Create Idoc Type(WE30) Allocate inbound Function Module to message type (WE57)Define process code(WE42)Create partner profile (WE20)

*

Create an Inbound process codeCreate message Type (WE81)Define function module characteristics(BD51)Create Function Module (SE37)Associate message type with Idoc type(WE82)Create Idoc Type(WE30) Allocate inbound Function Module to message type (WE57)Define process code(WE42) Initial steps are done in the same way as for Outbound IDOCs.Create Segments(WE31)Create partner profile (WE20)

*

Function moduleTo post the application document into its respective format from the idocWritten like any function module but has to follow standard interface parameters (i.e. Import, Export, Changing & Tables parameters)Should be RFC enabled.Copy the existing FM that starts with IDOC_INPUT_

*

Function module attributes (BD51)Enter name of function moduleInput type 1Tells how idocs are packaged1 -> individually input0->Mass Processing

*

Function module attributes (BD51) Screenshot of BD51 transactionIndicates whether the IDOC can be posted in a dialog mode after and error.If this option is turned on, the user can watch each screen during input processingInput type tells how IDOCs are packaged.1 stands for individually input and0 stands for Mass ProcessingSource: Screen Shot from SAP ECC 5.0.

*

Assign Idoc type Message type (WE57) - PICModule name function module developedBasic idoc typeMessage type Object type

*

Assign Idoc type Message type (WE57)Enhancement Message typeBasic idoc typeFunction module Screenshot of WE57 transactionSource: Screen Shot from SAP ECC 5.0.

*

Defining the process code WE42 - PICEnter the process code any meaningful nameIdentification is the name of the function moduleProcessing type is processing by function module

*

Defining the process code WE42Function module Screenshot of WE42 transactionSource: Screen Shot from SAP ECC 5.0.

*

Creating a partner profile (WE20) -PICMessage type Entry to be created under Inbound parametersProcess codeNote that no other details are needed unlike partner profile for outbound processEnter partner function (optional)

*

Creating a partner profile (WE20) Screenshot of WE20 transactionDouble-click on the message typeDouble-click on the process codeSource: Screen Shot from SAP ECC 5.0.

*

Inbound v/s Outbound processing - Similarities

The basic Idoc type

Partner profile

Message type

Idoc type Message type association

Process code

Creation of a function module/program

*

Testing the IDOC (WE19)This transaction helps toTo create an idoc starting from a blank template using the basic type or the message type or any existing idoc

To change values of the data fields if required

To post the idoc created through transaction WE19For inbound idocsUse Inbound function moduleTo debug, click on Call in debugging mode Or Standard inbound

For outbound idocs Use Standard outbound processing

*

Testing the IDOC (WE19)Child segmentParent segmentDouble-click on the segment Screenshot of WE19 transactionData editableSource: Screen Shot from SAP ECC 5.0.

*

Testing the IDOC (WE19)Child segmentParent segmentClick on the standard outbound processing Screenshot of WE19 transactionSource: Screen Shot from SAP ECC 5.0.

*

Testing the IDOC (WE19)Click on the standard inboundClick on the inbound function module Screenshot of WE19 transactionSource: Screen Shot from SAP ECC 5.0.

**What is EDI?EDI (Electronic Data Interchange) is the electronic exchange of business documents between the computer systems of business partners, using a standard format over a communication network.

Business document: is a legal document that defines the transaction conducted between trading partners. For example, Purchase Order (PO), invoices, RFQ (Request for Quotation) etc.

A typical business scenario (e.g. purchase order) includes exchange of various documents between several business partners at different times. A business process is a series of actions or functions that bring about a business result, and so there are some inherent problems with this scenario, like: It is highly inefficient and laborious.Has a very long lead time.Includes redundant data entry at various points.

To solve these problems, business partners started exchanging data electronically via floppy disks and other storage devices, which needed the standard formats to be followed. An ANSI committee was formed to define the standards. Ultimately, the electronic exchange of business documents in a standard format gave birth to what is known as EDI.

*Audio NotesLet us look into the components of EDI Process.Components of EDI Process are:Trading Partners: are the parties involved in a business transaction. For example, customers and vendors.

Application Programs: are responsible for generating and processing data in business documents. It is a part of the application suite called ERP (Enterprise Resource Planning).

Translators: are used to map the application data to EDI standard format and vice versa, so that the application software focuses on the business logic.

VAN: is basically the common network to provide a means of transmission for EDI transactions between trading partners. The VAN provides a mailbox on the network for each trading partner and this mailbox is periodically polled for messages.

EDI message: governs the rules, formats, and content of data in a transaction. A one-to-one correspondence exists between the components of a paper-based document and an EDI message.

Animation and GraphicsText to appear as per voice.

Camera angle: Normal

*Audio NotesThe Slide depicts SAP EDI Boundaries and gives an overview of SAP EDI Architecture.SAP only provides the application logic, the application data & the format for the data contents. The business documents are converted into something known as IDOCs (Intermediate Documents) to the EDI sub-system. The other systems in the architecture are provided by the third-party vendors.

The EDI subsystem: converts the IDOC types into EDI message types and vice versa. This component of the EDI architecture is not supplied by SAP.



*Audio NotesNow that you are aware about the 2 processes that EDI-enabled application comprises of .Let us throw some more light on them. For outbound process, a separate selection program reads the application data and creates an IDOC. This comprises of 6 steps. The application document is created. The IDOC is generated. The IDOC is transferred from SAP to the operating system layer. The IDOC is converted to the EDI standards. The EDI document is transmitted to the business partner. The EDI subsystem reports status to SAP.

Animation and GraphicsText to appear as per voice. Blocks to appear one by one followed by the Arrows.

Camera angle: Normal*Audio notesFor inbound process, a posting program reads the IDOC data and creates theapplication document. This comprises of 5 steps.The EDI transmission is received.The EDI document is converted into an IDOC.The IDOC is transferred to the SAP Layer.The application document is created.The application document can be viewed.

Animation and GraphicsText to appear as per voice. Blocks to appear one by one followed by the Arrows.


*Audio NotesWe discusses about the processes of EDI-enabled applications, Let us check out the benefits of EDI Process.Reduced data entry errors: EDI does not involve data entry at multiple points. In the EDI process, the data directly goes from one computer to another without involving the human element.

Reduced processing cycle time: The data entered into the system can be processed in seconds on the receiving side.

Availability of the data in electronic form:Data from EDI is in electronic form which makes it easier to share across the organization.

Reduced Paperwork: The entire EDI process can be handled without using a single piece of paper. The electronic form of paper was recognized as a valid legal document.

Reduced cost: The initial cost of an EDI is certainly higher as compared to the paper process, but over a long period it is very cost-effective.

Reduced inventories and better planning: Companies do not have to keep a safety stock for the time taken with order processing. Changes to the planning schedules can be communicated instantaneously.

Standard means of communication: EDI enforces standards on the contents of data, uniform naming standards and field sizes have emerged. Such consistency leads to clearer communication and less ambiguity.

Better business processes: EDI is comparatively a better way to communicate with the trading partners. Companies are willing to share information and participate in inter-organizational issues.

**Audio NotesLet us try to understand on what ALE is all about .ALE stands for Application Linking and Enabling.ALE is SAPs own technology to support distributed yet integrated processes across several SAP systems.

What exactly does this mean ?Distributed process is a process in which a part of the business process is carried out in one system and a part on the other. Lets consider a real-life scenario to understand it better.Consider the sales and distribution process in SAP. The sales process that performs all the sales related activities such as storing a sales order, calculating delivery dates, checking for availability, performing credit checks, and calculating price could be carried out on one SAP system. The shipping process that performs shipping related activities such as determining the shipping point, creating deliveries, picking goods, calculating the shortest route, determining the cheapest mode of transportation, and performing goods issue could be carried out on another SAP system. These systems have to be kept synchronized too.

The two systems would exchange data with each other at appropriate points to stay synchronized. SAP provides several tools to keep the systems synchronized at the technical level. In addition, business procedures are often required to keep the systems synchronized.The Example should have given you the basic idea about ALE.Lets move on and discuss about the other points which are :

First, let us examine the process flow used to exchange data between distributed systems in ALE architecture. It consists of an outbound process, an inbound process, and an exception handling process.

ALE forms the basis of distributing the processes in SAP.

ALE technology supports all the technical aspects of distributed processes, from the generation of IDocs in the sending system to the posting of IDocs in the destination system.

*Audio NotesInorder to understand Outbound Process let us first concentrate on concept of master idoc and communication idoc.What is a Master Idoc ? Master idoc - The application document or the master data to be sent is read from the database and is formatted into an idoc format. This idoc is known as the master idoc.What is Communication Idoc ?Communication idoc The ALE service layer generates a separate idoc from the master idoc for each recipient who is interested in the data. These are the communication idocs and they are stored in the database.

Steps to remember inorder to execute a successful Outbound process.Step 1 : Identify the need for sending an IDoc. This step can occur immediately upon creating an application document, can relate to a change to a master data object, can be user initiated, or can simply be a point in a process that necessitates the exchange of data. The outbound ALE process for the IDoc data is started. For example, when a material master is created, it consults the ALE layer to determine whether any system is interested in the data. If so, the ALE layer starts the process to send material master data to the interested party.

Step 2 : Generate the master IDoc. At this point, think of IDoc as yet another format in which a document can be represented. You know how a date can be stored in different formats, so imagine the date as a document with three components: day, month, and year. You can represent the date as MM/DD/YYYY, the standard American way. To make the information meaningful to a German business partner, though, you have to represent the date as DD.MM.YY. IDocs are based on a similar concept of representing one set of data in various ways. The data in the application document format is suitable for application modules, screens, and internal programs. The same data in an IDoc format is suitable for exchange with external systems.

Step 3 : Generate the communication IDoc. The ALE service layer generates a separate IDoc from the master IDoc for each recipient who is interested in the data. Separate IDocs are generated because each recipient might demand a different version or a subset of the master IDoc. These recipientspecific IDocs are called communication IDocs and are stored in the database. The recipients are determined from a customer distribution model that maintains a list of messages exchanged between two systems and their direction of flow.

*Audio NotesWe walked through the steps involved in an outbound process .Lets understand the concepts of Inbound process by looking at the Flowchart.The inbound process receives an IDoc and creates a document in the system. At a very high level, the inbound process can be seen as a sequence of the following steps:Storing the idoc in the database.Invoking the posting module.Creation of the application document.Lets Elaborate the points inorder to understand it better.Step 1 : Store the IDoc in the database. First, an IDoc is received in the system and stored in the database. Then, the IDoc goes through a basic integrity check and syntax check. (This will be covered later in this presentation). If everything is fine, the next step is performed.

Step 2 : Invoke the posting module. The control information in the IDoc and configuration tables are read to determine the posting program. The IDoc is then transferred to its posting program.

Step 3 : Create the document. The posting program reads the IDoc data and then creates a document in the system. The results are logged in the IDoc.

Animation and GraphicsText to appear as per the voice.


*Audio NotesThe preceding steps that we discussed earlier describes a success path. However, exceptions can occur at any point in the outbound or the inbound process. Depending on where they occur, these exceptions can be of different types, such asNetwork problems or data problems. For example, the data format that is followed in the sending system (SAP or non-SAP) may not match with the format that is used by the receiving system (SAP or non-SAP) and this can lead to erroneous results. The type of error determines who is responsible for handling it.Workflow provides the flexibility to determine the correct person(s) at run time and to inform them in a timely manner. Each person responsible receives a work item that can be executed to display the error and diagnose the problem. Errors are fixed outside workflow, and then the process can be restarted from the point of failure.

The previous slides gave us an overall picture on what ALE is,lets find out the benefits of ALE.

Few Notable benefits of ALE are :The system can concentrate on the business logic.If there are network problems, the messages are buffered and once the network is restored, the buffered messages are delivered.Hence the system guarantees that a message will never be sent twice.Backward compatibility exists for the messages exchanged between systems.Integration with NonSAP SystemsReliable DistributionRelease UpgradeAutonomy

Lets Discuss about these in detail.

Integration with NonSAP SystemsALE architecture is independent of the participating systems, allowing SAP to use the techniques used for SAPtoSAP communication to communicate with nonSAP systems. This breakthrough is a major advantage for ALE. In fact, you will find more thirdparty applications integrated with SAP using ALE than distributed SAP systems.

*Audio NotesWe got to know the benefits of ALE. Lets find out the difference between ALE and EDI.(Please read the points in the slide one-by-one.)

Animation and GraphicsText to appear row wise as per the voice.

Camera : Normal*Audio NotesAfter this session you must be able to understandThe basic concept of IDOCsThe structure of an IDOCConcept of segmentsComponents of an IDOCExtending an IDOCThe applications of IDOCsAdvantages of using IDOCs



*Audio NotesWhat is an IDOC ?An IDoc is not a process. The term IDoc stands for intermediate document. It is simply a data container 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 executing an outbound ALE or EDI process. In an inbound ALE or EDI process, an IDoc serves as input to create an application document.

What are the types of IDOCs ?There are two types of IDOCs inbound IDOCs ( from a SAP/ non-SAP system to a SAP system) and outbound IDOCs (from A SAP to another SAP/ non-SAP system).

IDocs are stored in the database. In the SAP system, they are stored in database tables. Several utilities are available to display the information contained in an IDoc and present it in different ways.

Every IDoc has a unique number. When an IDoc is generated in the system, a unique number is assigned to it. This number is unique within a client.

IDocs are independent of the sending and receiving systems. They can be used for SAPtoSAP and SAP to nonSAP process communication as long as the participating processes can understand the syntax and semantics of the data.

*Audio NotesPlease have a look at the slide inorder to understand the structure of an idoc.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.



*Audio NotesBasic IDOC Type can be created using Transaction WE30.It defines the structure and format of the business document that is to be exchanged.

Lets discuss about some facts of a Basic Idoc type.A basic idoc type can be assigned upto a 30-character name. for example, ORERS01,ORDERS02 are some of the standard idocs.The list of permitted segments refer to the segments which make up the idoc structureThe hierarchy of segments specifies the physical sequence and any parent-child relationship in the segments. A child segment cannot exist without the parent segment.Each segment has an attribute which defines whether it is mandatory or optional.Each segment in an idoc type has an attribute which defines the minimum and maximum number of times a data record corresponding to a segment can exist in an idoc.



*Audio NotesWe spoke about IDOC type in the previous slide ,Lets see how they actually look like in the real-life scenarioon your SAP screen. Go to transaction WE30. Type your basic idoc type name (e.g.OILSHL01).Click on the radio button basic type.Click on Display or Press F7.A screen is displayed where :OILSHL01 is the basic Idoc typeE1OILSH is the parent segmentE1OILSA, E1OILSV, E1OILSI are the child segments.



*Audio NotesWe learnt about the structure of idoc now lets find out the components of IDOCs.At first lets discuss about a Segment.What is a Segment ? A Segment basically defines the format and structure of a data record. It contains the fields which represent the data and can be reused across different IDOC types.We can create a segment using Tcode : WE31.A segment in SAP system is technically implemented as three physically separate pieces.Segment type the version-independent name of the segment. Standard SAP names begin with E1.Segment definition contains the fields which represent the data. Its maximum size is 1000 bytes. Standard SAP definitions start with E2 with the last 3 characters implying the version of the segment.Segment documentation represents the data dictionary documentation for each field in the segment definition. It begins with E3 for SAP provided segments

Note : By default, the segment type points to the latest segment definition.When a new version is to be added do not delete any fields, only add the new fields. The version should be released for it to take effect.


Camera angle: Normal*Audio NotesJust have a quick look at how a segment is created on SAP screen.Go to transaction WE31.Type your segment type name (e.g. ZZIFS_E1OILSI).Click on Display or press F7.You will get the segment description, segment definition, version of that segment and the list of data fields for that segment.For e.g. Here ZZIFS_E1OILSI 000 is the segment definition and the last three digits(000) is the version of the segment.



*Audio NotesOnce the segment is created , to check the run-time components of the IDOC we can go to Tcode : WE02 / WE05.(Transaction WE09 can also be used to view an idoc).An IDOC is an instance of an IDOC Type (standard/ customized).At run time the following events occurA unique IDOC number is allocated by SAPOne control record is attached to the IDOCSegments translate into data recordsStatus records are attachedSyntax rules are checked.

Each IDOC has 3 partsControl RecordData RecordStatus Record

The idoc number binds together the control, data and status records.



*Audio NotesLets glance at the Screen shot as shown to understand the Run-time components of an IDOC.Inorder to get to the screen as shown in the slide you need to :Go to transaction WE02/WE05.Click on Execute or press F8.A screen with many Idoc numbers is displayed. Double-click on an idoc number. For example 0000000000677913.The next screen shows the idoc number, control records, data records, the status records and other details of an Idoc like the direction and the last idoc status.Expand the status and the data records to see different data segments and statuses.



*Audio NotesLets get into the details of the components of an IDOC, starting with Control RecordIt is the first record in an idoc and contains the control information like- IDOC number- Sender and receiver information- Port details- Message type- Stored in EDIDC table. The key to this table is the IDOC Number- There is one and only one control record per IDoc.

A Perfect example for this would be to consider Control record as the envelope of a letter. By looking at the envelope, you can identify the sender and the recipient.

Data RecordContains application data like employee header info, weekly details, client details etcIs stored in EDID4 tables and EDIDD is a structure where you can see its components.Data record contains 2 sections, The Administrative section & Data section.The administrative section contains- idoc number- name and number of the segment in t he idoc- hierarchy information*Audio NotesIn continuation to the previous slide,lets discuss about the facts about Status record.Status Record In general, statuses 1-49 are reserved for outbound and 50 and above are reserved for inbound.Multiple status records can exist for any idoc.For outbound processes, the idoc is sent by SAP to the sub-system and it is the sub-system that generates the status records and passes it back to the SAP systemFor inbound processes, it is SAP that generates the status records.


Camera angle: Normal*Audio NotesThe concept of extending means to add one or more custom segments to one or more existing SAP segments of a basic IDOC type.When a basic idoc type meets most of the requirements, but not completely, they can be extended so as to meet the requirements completely.

Points to remember when extending an IDOC typeCreate the IDOC type as an Extension in transaction WE30.Specify the basic type for which it is 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 (fields which are not present in the parent segment) have to be added to the custom segment for extending it.



*Audio Notes Have a look at the screen shot to understand the concepts of Extended IDOCsInorder to get to the screen displayed in the slide you need to :Go to transaction WE30.Give the name of your extended Idoc.Click on the radio button extensionClick on Display or Press F7.A screen is displayed where:ZZIFS_OILSHL01 is the extended IdocE1OILSH is the parent segmentE1OILSA, E1OILSV, E1OILSI are the child segmentsZZIFS_OIK37, ZZIFS_E1ADRM1 are the extended segments.



*Audio NotesHaving an Overview of IDOC and Extended IDOC, Lets move on to the Applications of IDOC.Lets discuss about the points mentioned in the slide one-by-one.

EDI Integration - Several applications (purchasing, sales, or shipping) in SAP are enabled for EDI. To use EDI, an application first creates an application document, such as a purchase order. Then the EDI interface layer converts the application document (the purchase order) into an IDoc, which is transferred to an EDI subsystem. The EDI subsystem translates the IDoc into an industrystandard format and then transfers it to a business partner over a network.

ALE Integration - ALE enables the exchange of data between two SAP systems. This allows SAP business processes and applications to be distributed across multiple SAP systems. ALE ensures integration in a distributed SAP environment. The IDoc acts as the data container.

Legacy System Integration - For example, if a legacy application needs to send data to SAP, the application first exports the desired data in an IDoc format or a proprietary format. Using a thirdparty translator tool, you can convert data exported in a proprietary format into an IDoc format. Using the standard ALE/EDI interface layer, the IDoc data can be passed to the SAP system.

Third part product integration - A standard IDoc interface has been defined for numerous applications, such as a warehouse management system, etc. This interface describes various IDocs and the sequence in which these IDocs must be communicated to and from the SAP system.

Audio NotesWe got to know about the applications of an IDOC, Now Lets see the Benefits of an IDOC Interface.Lets discuss the points mentioned in the slide one-by-one.

Independence from applications - The biggest advantage of using the IDoc interface is that it's an open interface. It's independent of the internal structure used by SAP to store data and independent of the sending and receiving applications. Any application that can understand the syntax and semantics of the data can use the IDoc interface.

Communication using older-version IDOCs - The standard idocs and their segments have versions associate with them. Each time a standard IDoc or segment is enhanced, the system assigns it a newer version. This technology ensures backward-compatibility.

Using Workflow technology, an error can be routed to the concerned person for action/ notification.

IDoc Enhancement and Creation - Idocs can be enhanced or new idocs can be created in the system to support custom interfaces. This feature has been the basis for exchanging data with legacy systems using ALE and IDoc technology.

Better Monitoring Tools - Monitoring tools are available to monitor the state of the system. They range from simple IDoc display to IDoc statistics.Improved ease of use and Greater robustness.

*Audio NotesWith reference to the Sales cycle example the shipment is to be sent as an Outbound idoc.The basic steps to be followed while setting up an outbound idoc has been represented as a block diagram.

Animation and GraphicsBlocks to appear one-by-one along with the arrows.Text to appear as per voice.

Camera angle: Normal. Zoom in on the speaker again.

*Audio NotesWe learnt that a message type should be created after creation of an IDOC type,Lets find out how what a message type is.A message represents a specific type of document that is transmitted between two partners.Examples are Orders, orders responses, invoices etcAn idoc type can be associated with many message types A message type can be associated with different idoc typesThe message type or output type defines the characteristics and the attributes of the output itself.The basic concept behind Message control is to generate and manage outputs from an application and control their timing and medium of exchange. The outputs can require certain business conditions to be met before they are processed. For instance, the requirement is to send out the EDI message only when the customer number is 3000009. Otherwise, send a printed output. Print the output in German if it is for a customer in Germany; for customers anywhere else, print the output in English.The Message control encapsulates such ifthen business rules without having to write ABAP/4 programs. The Message control technique has proven to be quite useful and provides a consistent way of generating outputs from several applications. Most SD and MM applications are enabled to use the Message control componentMessage types can be created using Tcode WE81.



*Audio notesWe learnt about the message types,But where can we find the possible output types associated with a message type.To view the output types,Go to NACE transaction and select an application.Click on the Output types tab.Choose the output type and double-click on it. The details of the output type can be viewed here.(Refer Screen Shot for the same )



*Audio NotesIn sync with the previous slide a Function module is created after a message type is associated with an idoc type.Refer to the Highlighted block in the Block diagram.Selection programs, which are typically implemented as function modules, are designed to extract application data and create an IDoc. A selection program exists for each message type. The programs are generally named with the following naming convention:IDOC_OUTPUT_ Caution: The naming convention mentioned here is not a rule, but it is a common practice for naming the outbound programs.

If message control is not used, the control and data records are to be populated first and then the function module MASTER_IDOC_DISTRIBUTE is called.



*Audio NotesOnce we are through with creation of Function Module ,we need to associate it to an outbound process code using transaction WE41.The process of filling the IDOC with the application data is done by the Function Module. But, the function module is not assigned to a Partner. It is encapsulated by a Process Code and this Process Code is assigned to a Partner in Partner Profile.These function modules have a standard interface for input and output parameters. A process code is assigned to each selection program that executes under Message control. Because process codes are flexible, you can assign any processing option to a process code. A process code can point to a function module or a workflow.



*Audio NotesWe spoke about Associating the Function Module to an outbound process code, Lets see how this happens on SAP screen.Inorder to get to the screen as shown in the slide, You need to :Go to the transaction we41 which will list out the possible outbound process codes.



*Audio NotesOnce we associate the Functional Module to an outbound process code, we move on to create a Port using transaction code WE41.The Highlighted block shows the stage in which a port is created in the Block diagram.(Refer Slide ).The port defines the technical characteristics of the connection between SAP and the sub-system.It defines the medium in which data is exchanged between the two involved systems.It serves to determine - Name of the EDI sub-system program (if installed)- Directory path where the idoc file will be created- IDOC file names- RFC destination

Note : The name of a port should be meaningful so as to uniquely identify it



*Audio NotesThe preceding slide gave us theoretical concepts about creation of a port. Lets see how it looks like in SAP screen.To get to the screen shot as shown in the slide, You need to :Go to transaction WE21.Expand the transactional RFC, it will give you a list of all the available ports.Select a port from the available ports e.g. (A000000027).It displays the name of the port, description and the RFC destination



*Audio NotesAfter creation of a port using transaction WE21, We move on to Create a partner profile using Transaction code WE20. The Highlighted block shows the stage in which a partner profile is created in the Block diagram.(Refer Slide ).Lets check out some facts about partner profile.A partner profile is defined for every business partner with whom you exchange business documents. In EDI, the partner can be a bank, a customer or a vendor. IN ALE, the partner is a remote SAP system or legacy system.A partner profile specifies the various characteristics of data that you exchange with a business partner, the mode of operation, and an organization or person responsible for handling errors for that business partner.

There are basically 3 views for the partner profile General Parameters view. Values are stored in table EDPP1.Outbound Parameters view. Values are stored in table EDP13, except for the Message control parameters, which are stored in table EDP12.Inbound Parameters view. Values are stored in table EDP21.



*Audio NotesNow lets move on and find out how to create a Partner profile on SAP screen.Go to transaction WE20Expand the Partner type LS (Logical system)Select the logical system say IDVCLNT001, it will display the outbound parameters and the inbound parameters for this partner number.Choose the corresponding outbound parameters as we are learning to configure an outbound idoc now.This is the general view of the partner profile.

The outbound parameters define the characteristics of an outbound message to your business partner and how SAP transfers the IDocs to the subsystem. A record is created for every outbound message to a business partner.

Double click on the outbound parameter OILSHL in the previous screen (or the general view) to arrive at the Outbound Parameters view.This view gives you a snapshot of the following Partner detailsMessage typePort detailsBasic typeExtensionWhether to continue with processing after a syntax error is found in the idocOutput mode

In the Output Mode, we can specify whether we want to send idocs immediately as soon as they are generated or whether they should be collected and then sent to the external system at a later stage.

*Audio notesWe saw the screen shots to create a partner profile, lets rephrase the steps quickly.Steps to create Partner Profile Go to Transaction WE20. Click on Create Button. Enter the Partner Number and partner type. Save the Data. For Outbound Partner Profile we have to create Outbound Parameters. Press the add entry button under outbound parameters. Specify Partner Function, Message type created, Port, Basic Type and Output mode If using message control, goto Message Control Tab and link the Message Type and Process Code created.Save.



*Audio NotesAfter creating a partner profile, we move on to Trigger an idoc, Please refer to the Highlighted block in the Block diagram to get an idea about the stage in which an Idoc is triggered.

Depending upon the triggering mechanism (how and when the outbound program will be started) different techniques and interface is used for outbound program.

Through message control - This technique is mainly used for creating IDocs for transactional data. EDIenabled applications use it to generate IDocs for business documents, such as purchase orders and sales orders. This technique is also used in some ALE scenarios to distribute transactional data between different SAP systems. In the Message control, the RSNASTED program is used to process outbound ALE and EDI messages. The RSNASTED program calls the appropriate IDoc generation program (implemented as a function module) for a message. The key of the application document to be extracted is passed in the NAST entry, which is one of the function module's parameters. The function module builds the IDoc control record and the data records. The results are passed back to the RSNASTED program, which creates a physical IDoc in the SAP system. The function modules are generally named IDOC_OUTPUT_.

*Audio notesOnce we trigger the idoc using the appropriate technique and interface, we move on to the final step in the Block diagram which would be To check the status of the IDOC.

The status of an idoc can be viewed by the transaction codes we02, we05 and we09 also. An idoc can have multiple status records attached with it as a status record is tagged on to it as it goes through various milestones. For an outbound idoc, the status record is created by the EDI sub-system and is sent back to the SAP system, whereas for an inbound idoc, it is the SAP system that creates the status record for the idoc received by it.



*Audio NotesLets glance at the screen shot in SAP screen to check the status of the IDOC (Refer Slide).Inorder to get to the screen as shown in the slide you need to go to :Transaction WE02/WE05.Click on Execute or press F8. (You can also narrow down your search list by specifying the basic idoc type, message type, etc. in the selection screen parameters of the we02/ we05 transaction code).A screen with many Idoc numbers is displayed. Here you can see the status of the Idocs. Idocs marked as green are successful idocs and those marked with red are Idocs with an error.Double-click on one of the Idocs say 0000000000677913.The details of the Idoc like basic type, message type and extension is displayed.Expand the status records, you will see the different statuses of that idocAll the data records are also seen hereThe control record, as mentioned earlier, is the first record in an idoc.



*Audio NotesWith reference to the Sales scenario mentioned in the previous slide, Lets discuss about an Inbound idoc.The basic steps to be followed while setting up an inbound idoc has been represented as a block diagram.

Animation and GraphicsBlocks to appear one-by-one along with the arrows.Text to appear as per voice.

Camera angle: Normal. Zoom in on the speaker again.

*Audio NotesThe initial steps which are Creation of the segments, the basic Idoc type and the message types are done in the same way as for outbound idocs.


Camera angle: Normal.

*Audio NotesAssuming that you are through with the first 4 steps displayed in the Block Diagram which are creation of Segments, IDOC type,Message type and Associating the message type with Idoc type . Lets move on to the next step which is creation of a Function Module.The functionality is to To post the application document into its respective format from the idoc.Read control record and data recordsCreate the application document (use BAPIs, BDC, CALL Transaction etc)Change status record

The Functional Module is written like any function module but has to follow standard interface (i.e. Import, Export, Changing & Tables) parameters and it should be RFC-Enabled.Copy the existing FM that starts with IDOC_INPUT_.

The function module will contain the control record and data recordsLoop at the data records and move SDATA to a structure with the definition as LIKE the respective segment name to use the dataAdd status records. 51 when there is an error, 53 when it is posted successfully



*Audio NotesLets now define the Characteristics of the Function Module that we created in the preceding slide using transaction code BD51.Please refer to the Highlighted block in the Block diagram to get an idea about the stage in which an The characteristics of a FM is defined.Goto transaction code BD51.Enter name of function moduleInput type 1Input type tells how IDOCs are packaged1 stands for individually input and 0 stands for Mass Processing

Lets discuss about the input types in details.In the Input Type field, the possible values are:-

Mass processing (0). This option is for function modules that use a direct input method to create an application document. The ALE layer can pass multiple IDocs to the function module at the same time.

Individual input (1). This option is for function modules that use the call transaction method to post an application document.

Individual input with IDoc lock in call transaction (2). This option is for function modules that use ALEenabled transactions to post an application document.

*Audio NotesIn continuation to the previous slide, to check the characteristics of inbound function modules goto Tcode BD51. This configuration step tells the ALE system how your function module has been implemented. The ALE layer uses these settings to invoke the function module with correct parameters.The inbound function module that has been used here is Z_SDS_IDOC_INPUT_ORDERS and the input type specified here is 2. This option is for function modules that use ALEenabled transactions to post an application document.



*Audio NotesOnce we define the characteristics of a Function Module, we need to allocate it to a message type. This can be done by using Transaction Code WE57.We can find the parameters likeModule name function module developedBasic idoc typeMessage type Object typeThis configuration establishes a link between the function module, message variant (message type, message function, message code), IDoc type, and business object created by the function module. The Business Object field is optional.



*Audio NotesThe slide describes the relationship between different parameters like Function Module, Message type, Enhancement used and Basic IDOC type.Note: In the case of outbound messages, this link is established in the partner profile. For inbound messages, there is no entry for an IDoc type in the partner profile, so this entry is used to establish a valid Idoc type, message, and business object for a function module.



*Audio NotesWe discussed about allocating the inbound function module to a message type, The next step is to define a process code.This step defines a process code that points to the function module developed for the inbound process. Process codes provide an indirect means of determining the process (in this case, the function module). Using process codes enables you to change the process without affecting other configurations.The process code must start with a Z. This step creates a link between the process code defined in the preceding step and the function module. Also, this screen contains additional parameters that the workflow component uses for error handling, as well as for advanced workflow programming.



*Audio NotesThe screen shot in the slide displays the Inbound process code and the Function module.Inorder to get to the screen as shown in the slide you need to goto Tcode : WE42.Assign a short description, and then save your entry as shown in the screenshot.The system prompts you with the following message: Please maintain codes added in ALE entry methods.Accept the message by pressing Enter, and you are taken to a screen that shows the existing links between process codes and function modules.



*Audio NotesAfter defining a process code, the next step involves creation of partner profile.The concept of partner profile for inbound idocs is very similar to that of outbound idocs.Specify the parameters like,Message type Entry to be created under Inbound parametersProcess codeNote that no other details are needed unlike partner profile for outbound processEnter partner function (optional)



*Audio NotesLets have a look at the SAP screen shot to create partner profile. Inorder to get to the screen as shown in the slide You need to :Go to transaction WE20Expand the Partner type LS (Logical system)Select the logical system say IDVCLNT001, it will display the outbound parameters and the inbound parameters for this partner number.Double-click on the selected inbound parameter say ZZIFS_ORDERS, will give you the process code and the message type for that partnerHere, we can see the partner details and the message type associated with it. The process code which is linked to the message type is also viewed here.There is also a provision to specify how the function module has to be processed whether it has to be triggered by a background program or whether it has to be triggered immediately.Double click on the process codeThis is where we can see the function module linked to a particular process code. Options are available here as to whether the processing has to take place with the ALE service or without the ALE service. The option to choose the type of processing is also available here.



*Audio NotesWe learnt about Inbound and Outbound IDOCs lets find out some of the similarities they have,

The basic Idoc type Partner profileMessage typeIdoc type Message type associationProcess code Creation of a function module/program



*Audio NotesOnce the IDOCs are created we need to test the IDOCs right.Tcode WE19 takes care of this. Lets go through the points mentioned in the slide to get an overview of it.Suppose you want to test an idoc manually or you want to manipulate the data for a particular field, you can use go to the transaction WE19. This transaction permits you to create an idoc from scratch given any basic type or message type or any existing idoc. You can add segments, change the data in the segments, delete segments, etc as long as it confirms to the syntax check of the idoc.

This idoc, which has been created for test purposes, has to be posted. Outbound idocs can be posted by clicking on the tab Standard outbound processing. Inbound idocs can be posted by either clicking onto the tab Inbound function module or Standard inbound.

On clicking the Inbound function module tab, there are options to call it in debugging mode and different options for the processing of the CALL TRANSACTION statement.

On clicking on the Standard inbound tab, we get the details as regards the partner, message type, process code, function module name,etc.



*Audio NotesLets move on to SAP screen to implement the points that we discussed in the preceding screen.To get to the screen as shown in the slide, You need to : Go to transaction WE19Give the existing Idoc number say 0000000000655989 or the basic idoc type, also select the appropriate radio button.Click on Execute or Press F8It will give you the parent segments and the child segments.Double-click on any segment, it allows you to edit the fields of that particular segment.



*Audio NotesIn continuation to the previous slide lets discuss some more parameters.Click on the Standard Outbound Processing to process an outbound idoc.Here you can give the number of idocs to be generated you can either have one single idoc generated for this or you can even have multiple idocs posted for this single idocThe receiver port and the destination details of the idoc is visible for verification before you post the idoc.On clicking the green icon, it gives you a success message saying that the idoc has been posted and also the new IDOC number.



*Audio NotesClick on the Inbound Function ModuleHere you can give the name of the FM to be executed in the background, foreground or in the foreground after error.You can also click on to the Standard Inbound tab too. This gives you the details regarding the message type, process code, function module used, etc.

