Tuesday, August 21, 2007

Learn to Love Your SAP IDoc

Over a year ago, I had a post in which I discussed how difficult it is for a custom application development person like myself to get adjusted to projects based on a packaged application like SAP. It had the somewhat humorous title How to Talk to an SAP Consultant (If You Must).

If you keep reading this post, you will see that I am now starting to understand some of the SAP terminology which once seemed so incomprehensible. I hope you will find this post helps accelerate your own understanding of SAP if you are thrust into it like I was.

I now have become all too familiar with the SAP interfaces for external system known by the name "IDoc".

SearchSAP.com provides the following definition:

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program.
Being relatively new to the SAP world, these complex documents reminded me of database schemas generated by the old Computer-Aided Software Engineering (CASE) tools with many cryptic table names and field names that only an automated tool could keep track of.

For example, suppose you want to create an order from an external system in the Customer Relationship Management (CRM) module of SAP. What would you expect the interface to be called? How about something like "Create Order"? Wrong! My client's CRM team first instructed us to use a standard IDoc going by the rather unintuitive name of "CRMXIF_ORDER_SAVE_M02". Shortly later, they decided that this standard IDoc would not meet all their business requirements and they created a new IDoc from the standard one and gave it a name they prefixed with a "Z" and added a different ending. I will stick with the standard create order IDoc for this post, however.

Ok, suppose you get past that detail, get into the right IDoc and start looking for the data representing the order header. Do you find it under something like "Order Header" or "Order"? No! Try looking for something SAP calls a "segment" and whose name is "E101CRMXIF_BUSTRANS".

help.sap.com has this to say about segments:

Segments form the basic building blocks of an IDoc type and are used to store the actual data.

A segment type is the name of a segment and is independent of the SAP release.

The segment definition is the release-specific name of a segment. By combining the segment type and the release, the required segment definition can be determined: This way, you can assign segment definitions from previous releases to an IDoc type in the current release. This may be necessary if, for example, the partner is using an older release which supports your current IDoc type but not your current segment definitions. You then have to "reset" these in the Structure link Partner profiles .


This segment type name is not completely random but is based on the phrase "business transaction" instead of order. I believe the addition of "E101CRMXIF_" to the beginning makes the segment type release-specific and specifies the segment definition.

Each segment can in turn have multiple fields. Some of these fields can contain data defined by another segment. These can be optional or mandatory. One segment can have a 1:1 or 1:n relationship with another segment. For example, the standard E101CRMXIF_BUSTRANS segment looks like this when I look at it in the XML editor of Rational Software Architect v7 (though truncated to what would display on my screen and still be readable):


Note that the order segment has many individual elements (mostly strings) followed my many references to other segments. The graphical representation looks a lot like an object model or database design.

An entire SAP IDoc can be huge! The entire IDoc for orders includes well over 200 IDoc segments. After I used my XML editor to format the XML schema of CRMXIF_ORDER_SAVE_M02 so that it was neatly indented and had line feeds before each level of nesting, the resulting XML schema file was a mere 38257 lines long.

If your next project takes you down to the implementation level of SAP, I hope you're a detail-oriented person.

(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.

Copyright © 2007 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Perils of Over-Customizing SAP-Broken Reports

I've been around clients for some great discussion on the perils of over-customizing SAP lately. I hope to collect some of the lessons learned here for your reading enjoyment and career enrichment.

Here's a comment made by a country sales manager at a meeting I attended in May 2007.
"They told us that the new SAP system would have over 160 reports out-of-the-box that we could use to run our business and we didn't plan on having to create a lot of custom reports. Now they tell us that's not true. Almost all the out-of-the-box reports are broken. Almost every report we need must be a custom development."
It seems this company made some customizations to their base SAP system (ECC) when they were only operating in a only single country and were focused only on a transactional, commodity type business model. They then moved into multiple countries and began to look closely at big, relational customers and value-added services. To support this, they planned to create a new CRM system running on top of their existing ECC. They were not happy to find out that their legacy of prior ECC customizations "broke" a lot of the standard SAP reports.

I'd love to hear from other people who might have an SAP over-customization lesson to share.

(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.


The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.