WCF-SAP Adapter: Finding the document specification by message type [IDOC Message Type] failed. Verify the schema deployed properly.

In the sequence of my last post, and following the result obtained while trying to solve the problems that had been originated by the SAP system migration to a newer version, I end up receiving another error. This time the connectivity problem with SAP was overcome, however, without any reason I started to receive an error saying that the schema was not known

I got the following error:

“There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “XML disassembler” Receive Port: “IN_IDOC_PORT” URI: “sap://CLIENT=[SAPClientID];LANG=[LANG];@A/[SAPServer]/[SystemID]?ListenerGwServ=[GWServer]&ListenerGwHost=[GwHost]&ListenerProgramId=[ProgID]&RfcSdkTrace=True&AbapDebug=False” Reason: Finding the document specification by message type “http://Microsoft.LobServices.Sap/2007/03/Idoc/3/IDOC_NAME//740/Receive#Receive” failed. Verify the schema deployed properly.”

It was strange to receive this kind of error because the process was in the testing stage for about a month and working properly.

Cause

After the SAP System migration to a newer version, the process started also to use the newest IDOC Schemas versions. I really don’t know if the SAP team change anything on the SAP side or it had to do with the migration itself, however, when I checked the source code I noticed that we were using the 711 version of the schema:

  • http://Microsoft.LobServices.Sap/2007/03/Idoc/3/IDOC_NAME//711/Receive#Receive

And now the SAP system process was using and sending the 740 version of the schema:

  • http://Microsoft.LobServices.Sap/2007/03/Idoc/3/IDOC_NAME//740/Receive#Receive

Solution

The solution is very simple, you just need to generate and import the newest version of IDOC Schema (740) to your BizTalk Solution, make all the necessary changes and redeploy all the required artifacts (schemas, orchestrations, maps, and so on)

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

  • Ron Schneider

    You can also set the segment release to 700 (or other) when generating your schema. And to make sure that SAP is sending this segment release set this in your outbound parameter (WE20 -> LS -> -> outbound parameters -> -> Outbound options -> segment release). But be aware that some IDOCs (e.g. MATMAS) have different application releases. You can see that in WE31 choosing the segment you want to check.

One Platform Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

One Platform - Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

One Platform - Operations, Monitoring and Analytics Software
ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

Back to Top