BizTalk Adapter Pack 2.0 – Part 4 Sending XML IDocs to SAP

When I started this series, I was more focused on the challenges that are involved with receiving XML IDocs and the schema versions that are  tightly coupled to the version of SAP that you generated them on.  In Post 1 we discussed how the SAP Adapter will use the DOCREL version that is provided by SAP and line this up with your schema forcing you to be in sync with SAP Upgrades.  I wanted to better understand the implications on the Send side so you will find some of my notes below. The story is a little better on the Send side when sending XML IDocs.

 

• When generating your XML IDoc schemas ensure that the RecieveIdoc Format = Typed.

• Since BizTalk will be sending IDocs to SAP, you want to select “Client (Outbound operations)” and ensure that your schema has a name of “Send”.

• You still want to be aware of the version of SAP that you will be connecting to but it is not as important as when you are choosing to Receive an XML IDoc.  You are best off asking your BASIS admin what version you are on.

• My initial test scenario was generating a ZCONF32 – 700 version of my IDoc.  The version of SAP that I am connecting to is 700 so everything should work correctly.
• As expected when I wired up my Receive Port to my Send Port, I am able to submit an IDoc to SAP successfully.  Something that I was interested in knowing was the namespace that was included in the context properties.

Something also to note is that when you import the Binding file, that was generated when you created your IDoc Schemas,  is the SOAP Action header configured in your send port.  You will notice that the Action includes the namespace for the Schema that was generated.

<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Operation Name="Send" Action="http://Microsoft.LobServices.Sap/2007/03/Idoc/3/CONF32/ZCONF32/700/Send" />
</BtsActionMapping>

• My next scenario included downloading schemas for version 710 of the IDoc(knowing that I am connecting to an SAP version that is set to version 700).  I updated my map to include this version of the schema. All of the “connection lines” in the mapper updated successfully which makes me think that there are no structural differences between these two versions – at least not with the data elements that I was trying to map. I redeployed the application and left the existing send port in tact.  I was prompted with a warning/error in the event viewer:

Event Type:    Warning
Event Source:    BizTalk Server 2009
Event Category:    (1)
Event ID:    5743
Date:        4/18/2010
Time:        8:50:45 AM
User:        N/A
Computer:    BizTalkServer
Description:
The adapter failed to transmit message going to send port "SendSAPIDoc" with URL "sap://CLIENT=XXX;LANG=EN;@a/SAPSERVER/XX?RfcSdkTrace=False&AbapDebug=False". It will be retransmitted after the retry interval specified for this Send Port. Details:"System.Xml.XmlException: Start element 'Send' from namespace 'http://Microsoft.LobServices.Sap/2007/03/Idoc/3/CONF32/ZCONF32/700/Send' expected. Found element 'ns0:Send' from namespace 'http://Microsoft.LobServices.Sap/2007/03/Idoc/3/CONF32/ZCONF32/710/Send'.

Server stack trace:
   at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)
   at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)".

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

• This error leads me to believe that the “magic” when sending XML IDocs is in the SOAP Action Header in the Send Port.  Upon updating the SOAP Action Header to reference the 710 version of the IDoc, I had success.

<BtsActionMapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Operation Name="Send" Action="http://Microsoft.LobServices.Sap/2007/03/Idoc/3/CONF32/ZCONF32/710/Send" />
</BtsActionMapping>

 

• I checked the WE02 SAP Transaction and found that my IDoc was processed successfully as indicated by the green light.

 

Conclusion

What I am able to conclude from this exercise is that you are not bound by the version of DOCREL like you are when Receiving IDocs but rather by the structure of the IDoc itself.  I am pretty confident that you can update your SAP version without having to regenerate your schemas as long as the structure of the IDoc itself does not change.  This puts you in a similar risk category as using flat file schemas which I will discuss in the next post of this series.  Something that became evident is that the SOAP action header must match the version of the schema that you have generated.

BizTalk Adapter Pack 2.0 – Part 3 Receiving multiple Flat File IDocs using SAP Adapter

In Part 2 of this series we discussed how you can receive IDocs from SAP in flat file format in order to avoid tight coupling with the version of SAP you are running as discussed in Post 1.

As I alluded to in the end of the Part 2 post, there is an issue when you include more than 1 IDoc schema in a Receive Pipeline that will be use the same Program ID and Receive location.

The behavior that I experienced when working through this scenario is the first message in my pipeline would be processed successfully but the second type(Vacations) would not.

 

 

 

When I tried to process my 2nd type of IDoc (Employee Vacations) I would get the following error:

 

Event Type:    Error
Event Source:    BizTalk Server 2009
Event Category:    (1)
Event ID:    5719
Date:        4/11/2010
Time:        10:10:49 AM
User:        N/A
Computer:    *BizTalk Server*

Description:
There was a failure executing the receive pipeline: "SAPVersions.ReceiveSAPIDocs, SAPVersions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=147585b889447deb" Source: "Flat file disassembler" Receive Port: "ReceiveIDocsFromSAP" URI: "sap://CLIENT=XX;LANG=EN;@a/SAPSERVER/XX?ListenerGwServ=sapgwXX&ListenerGwHost=SAPSERVERci&ListenerProgramId=*ProgramID*&RfcSdkTrace=False&AbapDebug=False" Reason: Unexpected data found while looking for:
'Z2HR_WS_SEG000'
The current definition being parsed is idocData. The stream offset where the error occured is 520. The line number where the error occurred is 2. The column where the error occured is 0.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 

In the rest of the post I will discuss how you can fix this problem manually and then discuss the Hot Fix from Microsoft that addresses this situation.  I recommend proceeding with the Hot Fix route as it is a more sustainable solution.  The manual steps include modifying a schema that was generated by the Consume Adapter Service Wizard.  The risk is you can manually modify one of these schemas only to have a colleague regenerate the schema and overwrite your manual change.  If you do proceed with the Hot Fix route you will want to ensure any other developers that will be generating IDoc schemas are also using this Hot Fix.  I also want to highlight that this Hot Fix should be applied to developer’s workstations as this fix addresses a design time issue.

 

Fixing issue manually

• Open up your schema that contains the “meat” of your IDoc information in an XML Editor view.  Whenever you generate  SAP IDoc schemas you are bound to have multiple XSD schemas created.  You can expect 1 IDoc that includes the various complex types, another that acts as the “Request” container IDoc, a Response xsd and the “meat” xsd which will include most of the “core” details of the schema.
• Scroll down until you find a section that includes tag_name=”EDI_DC40” tag_offset="0" and replace it with tag_name="ZHR_VAC" tag_offset="39" where “ZHR_WS” is the name of your IDoc type.

 

 

• What you will find as you open your schemas is that all of them will have this tag_name="EDI_DC40" tag_offset="0" string included in the IDoc which prevents BizTalk from distinguishing one IDoc from another.
• Once you have modified all IDocs in this fashion, redeploy and you should find that both(in my case) IDocs were processed successfully.

Fixing issue with HotFix

• In KB977528 Microsoft describes the issue as “This problem occurs because the first Flat file disassembler pipeline component in the custom pipeline tries to disassemble all the IDOCs that are received. However, the IDOCs should be processed by different Flat file disassembler components that have different schemas”.

• When using the HotFix, you download schemas the same way as you previously did

• Note when you open up the schema, you will now notice that the same change that we applied manually has now been incorporated into the schema definition automatically.

• If you have changed the name of you XSD files, make sure you update your receive pipeline, deploy and restart your host instance(s).  You should now be able to receive both types of flat file IDocs without issue

 

Note:

My developer workstation is a 64 bit machine so when I navigated to the Hot Fix Web site it detected that my system was a 64 bit system and provided me with a 64 bit patch.  The problem is that Visual Studio runs in 32 bit mode and since this fix is a design time issue my issue was not resolved until I downloaded the 32 bit version of this KB.  I logged onto a 32 bit machine and navigate to the same site in order to get the 32 bit fix.

 

 

Thus far we have been  focusing on receiving IDocs.  A reader has asked if I can demonstrate how to sent a flat file schema to SAP using the BizTalk Adapter Pack so that will be the next post in this series.