Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at email@example.com.
The SAP IDoc Technology
In this month’s blog I will begin a series on the SAP IDoc Technology, This technology is used in ALE, EDI, and 3rd Party Systems Integration scenarios.
For some of my readers this may be trip down memory lane, but for some, the New Developers, I hope to give you the tools you need to understand and demystify the IDoc concept. So.. for you old dogs, think of it as a remedial and chime in with comments and suggestions. let’s get started!
What are IDocs?
You have probably heard the term IDoc many times. This blog will help you understand exactly what an IDoc is and what it does.
Let’s look at some important facts about IDocs.
– 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 semantics of the data.
– An IDoc is created as a result of executing an Outbound ALE or EDI process whereas with an inbound ALE or EDI process, an IDoc serves as input to create an application object in SAP, like a Sales Order or PO.
– IDocs in the SAP system, are stored in database tables. We can use transactions to view, edit, and process them. When an IDoc is generated in the system, a unique number is assigned to it via a Number Range Object. This number is unique within a client.
– IDocs are independent of the direction of data exchange. An inbound and an outbound process can use an IDoc. For example, 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. Using this technique avoids creating redundant IDoc types.
The IDoc Interface
How are IDocs used? What is EDI? ALE? I might be giving my age away here…. but the IDoc interface has been around since release 2.2, when IDocs were initially used in the EDI process. So this is a PROVEN, Scalable technology that is used in a wide variety of interfacing requirements.
OK, let me define some of the concepts we will touch on…
EDI Integration (Electronic Data Interchange)
EDI is the electronic exchange of business documents between trading partners in a common industry−standard format, such as ANSI X12 or EDIFACT. 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, or PI with an EDI Plug-in. The EDI middleware translates the IDoc into an industry−standard format and then transfers it to a business partner over a network.
Advantages of EDI process
– Reduced data Entry Errors
– Reduced Processing cycle time
– Availability of data in electronic form
– Reduced Paper Work
– Reduced Cost
– Reduced Inventories and Better Planning
– Standard Means of Communicating
ALE Integration (Application Link Enabling)
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. SAP introduced ALE as its initiative to support a distributed yet integrated environment. ALE allows for efficient and reliable communication between distributed processes across physically separate SAP systems to achieve a distributed, yet integrated, logical SAP system. Because ALE architecture is independent of the participating systems, this enabled SAP to use this technique for SAP to non−SAP systems as well. This was huge in the early years of ALE and led to it being widely adopted as a “Best Practice” for communicating with SAP and Non-SAP systems.
– Distribution of applications between different releases of R/3 Systems
– Continued data exchange after a release upgrade without requiring special maintenance
– Customer-specific extensions.
– Communication interfaces that allow connections to non-SAP systems.
Let’s wrap this up by examining some of over-arching benefits of using the IDoc Technology…
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.
Exception Handling via Workflow
Handling exceptions is always very important and usually a second thought in most designs. If you have designed sophisticated applications in the past, you can, no doubt, relate to the agony of designing a consistent means of logging errors and exceptions across the board and then developing tools to display that information.
Well with IDocs, you get comprehensive information about the processing. Several standard tools are available to display the logged information. In particular, SAP uses the workflow technology to route an error intelligently to the right person so they can see what happened, why, and how to proceed. By using the IDoc interface, you automatically take advantage of this exception−handling process. This is both for standard and for your custom IDocs. No extra code required.
IDoc Modification and Enhancement
Using standard tools we will discuss in later blogs, (the IDoc editor and Segment editor), you can either enhance standard SAP IDocs or create new IDocs in the system to support custom interfaces. Your newly developed IDocs integrate seamlessly into the standard EDI interface because they are developed using standard tools provided by the system. IDocs developed in this manner become available in the standard list of SAP IDocs and can take advantage of all the tools designed for standard IDocs, such as IDoc monitoring, error handling, and archiving. We will talk at length about each one of these in turn in later blogs.
So in summary, IDocs act as containers for data exchanged between two applications. The IDoc interface is functionally rich and provides a robust environment for interfacing SAP with SAP, as well as with external applications. Using the IDoc interface for integrating external applications with the SAP system offers several benefits, such as a thoroughly documented interface, independence of the application product, numerous testing and troubleshooting tools, and a sophisticated means of error handling via workflow.
In the next part of this blog series we will dive into the technical makeup of IDocs.