BizTalk SAP Adapter and Extended SAP IDocs

I recently ran into an interesting scenario when generating the BizTalk schema for an IDoc. I have generated several schemas from SAP in the past but was having trouble "finding" this particular IDoc.


SAP Background:
I do not confess to being an SAP expert, but this is the way that I understand IDocs. Out of the box, SAP provides lots of IDocs that relate to particular modules within SAP. These modules include Finance, HR, Plant Maintenance among many others. You can also buy separate packages that relate specifically to your industry. For instance I am in the energy industry so my organization heavily uses that ISU module. Generally organizations like to limit the amount of customization that they do to their SAP system but it is usually impossible to have no customizations.

When you want to customize one of these "out of the box" IDocs you have a couple options:

• Creating an IDoc based upon a "copy" of an original IDoc. Kinda like a copy-paste, rename scenario. The naming convention for custom Idocs is to place a 'Z' in front of the IDoc that you just customized. For instance if you were to customize the 'CONF32' (Confirmation IDoc) you would name your IDoc ZConf32.


• Extending an IDoc. You can think of this more like inheritance. You start by inheriting the "base" Idoc and adding, or extending, any segments that satisfy your needs.

My experience in the past primarily involved generating schemas for custom IDocs. So when I input the IDoc that I am looking for in the BizTalk Adapter Meta Generation wizard I would type in ZConf32* and it would return a result. The problem that I ran into is that when I typed this name as the IDoc that I was looking for, no results were returned.

At one point it was suggested by someone on our SAP team that perhaps BizTalk could not download Extended IDocs. I was not too surprised that the suggestion was made since BizTalk often mis-understood. On the flip side, BizTalk resources generally do not have a lot of SAP knowledge so I couldn't initially confirm whether BizTalk could or couldn't. However, I wasn't quite ready to throw in the towel.

Microsoft has done a pretty good job of abstracting the "little" details away from us by providing wizards that allow us to generate schemas. This is definitely a value-add offering by Microsoft and a key driver in organizations using middleware like BizTalk. It allows integration projects to turn around solutions faster and cheaper.

So I started by querying with a "wider" search criteria via wild cards. What I found was that since this IDoc was extended, I needed to find the "Standard" SAP IDoc and then drill down from there to find the extension.

Error returned while searching for "Custom Name" ZConf32

When I changed my query to include the "Standard" SAP Conf32 IDoc and drilled down a level I was presented with both the SAP Idoc and the version that had been extended. Since I wanted the extended version, I selected the entry called Conf32-ZConf32. The naming convention follows that of Custom IDocs in that "Z" is used to indicate that the extension is custom and not something provided out of the box.

Success! IDoc is found with the "Standard" SAP version.

The two preceding examples used the BizTalk Server 2006 (R1) Adapter. I was curious to see if the behaviour was similar with the WCF based SAP adapter that can be used with BizTalk Server 2006 (R2).

When searching for my Extended IDoc called ZConf32 I was presented with an "IDoc not found" message. Not the same message as the R1 error, but in essence the same meaning.



The next step I did was provide a search that included the "Standard" SAP IDoc Conf32 to see if the extended IDoc was hanging out with the original. While the experience in the Wizard is a little different, the end result is the same. The Extended IDoc is available for download by the Adapter Meta Data Generation wizard


So hopefully this post will help someone out. I know myself and a SAP resource were scratching our heads for a bit but in the end we got the result that we were looking for.