none
SAP IDOC schema debatching in Biztalk RRS feed

  • Question

  • Hello,

    I have a scenario where to debatch an IDOC received from SAP into Biz talk. I have tried generating an instance of the idoc schema generated in Biztalk set the corresponding properties to be envelope schema and set this schema in xml dissemble stage in receive pipeline, however I'm getting the error as below. 

    Reason: Finding the document specification by message type "http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/3/DELVRY07/ZDELVRY07/740#EDI_DC40" failed. Verify the schema deployed properly.   

    Can you please let me know how to debatch an IDOC received from SAP into Biztalk? I need to debatch the same and map onto an different destination schema in biztalk. Any help/suggestions would be of great help and  is much appreciated. Thank you. 

    Regards,


      
    Thursday, September 8, 2016 10:03 AM

Answers

  • Seems that your debatching mechanism is stripping the batched message into message types of

    Namespace: http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/3/DELVRY07/ZDELVRY07/740

    RootName: EDI_DC40

    And you don't have a corresponding Schema for this message type.

    So you need to verify if that is the expected debatched message type, and if so you will need a Schema representation for this deployed.

    Go to BizTalk Admin Console --> Applications --> All Artifacts --> Schemas and check if the schema is deployed (also make sure there is only one entry for it)

    If yes then take a look at the suspended message, and make sure it has a root node and target namespace that matches a schema that is deployed.

    Also can you please confirm, if you have specified the Envelope property of envelope schema to "True" and Body XPath to the parent node of the repeating node.

    XMLReceive Pipeline handle everything else automatically.


    Rachit Sikroria (Microsoft Azure MVP)

    Thursday, September 8, 2016 10:25 AM
    Moderator

All replies

  • Seems that your debatching mechanism is stripping the batched message into message types of

    Namespace: http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/3/DELVRY07/ZDELVRY07/740

    RootName: EDI_DC40

    And you don't have a corresponding Schema for this message type.

    So you need to verify if that is the expected debatched message type, and if so you will need a Schema representation for this deployed.

    Go to BizTalk Admin Console --> Applications --> All Artifacts --> Schemas and check if the schema is deployed (also make sure there is only one entry for it)

    If yes then take a look at the suspended message, and make sure it has a root node and target namespace that matches a schema that is deployed.

    Also can you please confirm, if you have specified the Envelope property of envelope schema to "True" and Body XPath to the parent node of the repeating node.

    XMLReceive Pipeline handle everything else automatically.


    Rachit Sikroria (Microsoft Azure MVP)

    Thursday, September 8, 2016 10:25 AM
    Moderator
  • Hi Rachit,

    thanks for the reply.

    Yes, i checked the schema deployed in All artefacts and found the TNS for this particular node is different  from the one that actually shows in solution explorer in schema properties.

    All artefacts  - http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/Common/

    solution explorer -   http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/3/DELVRY07/ZDELVRY07/740 

    the first one is being referenced from the SharedTypes schema which is part of the schemas that we generate from Add adapter consumer service but i dont understand why is it referencing that TNS instaed of the one in Receive schema which is 2nd TNS. 

    I have generated the schemas using Add adapater consumer service and then set the ENVELOPE property to Yes for the Receive schema and body xpath to repeating node in receive schema which in my schema is E2EDL20004GRP. 

    Is it that i will need to create another schema in biztalk representing the one generated from SAP an dthen try rest of it? 

    Thursday, September 8, 2016 11:21 AM