Firstly, let me explain the common customer scenario using the old (mySAP 2.0) Adapter (NOTE - points in red and green below highlight the similarities/differences in configuration):

  • The user, at design time, uses a high privilege account (let's call it account A), to obtain the schemas for an IDoc. These schemas are deployed in a BizTalk project.
  • In the BizTalk project, the user adds the FlatFile Pipeline component (because the user wants the IDoc which SAP sends out as a strongly typed XML in his BizTalk orchestration).
  • At runtime, the adapter is deployed using a SAP account which has low privileges (account B).
  • At runtime, the adapter receives an IDoc from SAP as a flat file.
  • The adapter hands this flat file out to the FlatFile Pipeline component.
  • The FlatFile pipeline component, using the deployed schemas, converts this FlatFile to a XML document, and submits that to BizTalk.

Now, here's what the user would do when using the new WCF SAPBinding.

  • The user, at design time, uses a high privilege account (let's call it account A), to obtain the schemas for an IDoc. These schemas are deployed in a BizTalk project.
  • In the runtime configuration of the SAPBinding, the user sets the ReceiveIdocFormat property to Typed, since he wants the IDoc which SAP sends out as a strongly typed XML in his BizTalk orchestration).
  • At runtime, the adapter is deployed using a SAP account which has low privileges (account B).
  • At runtime, the adapter receives an IDoc from SAP as a flat file.
  • The adapter makes an outbound call to the RFC IDOCTYPE_READ_COMPLETE, in order to obtain the metadata for the IDOCTYP which was received (e.g., ORDERS05, MATMAS05, etc).
  • This call (to IDOCTYPE_READ_COMPLETE) fails, since the SAP account B does not have sufficient permission.
  • An exception is thrown.

Bummer!

As you can see, the SAPBinding requires a more privileged account, since it is doing something extra as compared to the older adapter.You can get it to work with a low privileged account, by making it do the same thing as the older adapter. Here's how:

  • The user, at design time, uses a high privilege account (account A), to obtain the schemas for an IDoc. These schemas are deployed in a BizTalk project.
  • In the runtime configuration of the SAPBinding, the user sets the ReceiveIdocFormat property to String, so that the adapter gives out the Idoc as a ReceiveIdoc operation (FlatFile format).
  • In the runtime configuration of the SAPBinding, the user follows the instructions in the post http://blogs.msdn.com/adapters/archive/2007/10/05/receiving-idocs-getting-the-raw-idoc-data.aspx (note - hyperlink opens a new browser window), so that the FlatFile data is pulled out of the loosely-typed ReceiveIdoc() xml.
  • In the BizTalk project, the user adds the FlatFile Pipeline component (because the user wants the IDoc which SAP sends out as a strongly typed XML in his BizTalk orchestration).
  • At runtime, the adapter is deployed using a SAP account which has low privileges (account B).
  • At runtime, the adapter receives an IDoc from SAP, and hands it out as a ReceiveIdoc XML. (NOTE - Adapter makes no attempt to retrieve IDoc metadata via a call to IDOCTYPE_READ_COMPLETE, since the ReceiveIdocFormat was set to String)
  • The WCF-Adapter, (assuming the instructions in the blog post mentioned above were correctly followed), extracts the IDoc data from within the ReceiveIdoc XML node, and hands the FlatFile data out to the FlatFile Pipeline component.
  • The FlatFile pipeline component, using the deployed schemas, converts this FlatFile to a XML document, and submits that to BizTalk.

Yay! Its working now!

However, note that in configurations where you set ReceiveIdocFormat to String and then use the FlatFile Pipeline component to convert the FlatFile IDoc to a strongly typed XML, such configurations won't work when you are receiving IDocs containing multi-byte characters, from non-Unicode systems. (Why? That's a different (and really long) blog post altogether. It has to do with limitations in the RFC SDK Unicode Library.)

Hence, we recommend, that as far as possible, you set ReceiveIdocFormat to Typed in your runtime configuration, which makes the Adapter hand out the IDoc as a strongly-typed XML, without requiring the FlatFile Pipeline Component.

As for the extra permissions required in order to call IDOCTYPE_READ_COMPLETE, the authorization object required is:

Authorisation object S_IDOCDEFT. Fields:
EDI_TCD, value 'WE30'
ACTVT, value - 03
EDI_DOC, value * (or the specific IDOCTYP)
EDI_CIM, value * (or the specific Extension)