BizTalk 2013: WCF-SAP Adapter using Messaging Servers

 

SAP supports a few different architectures when it comes to scaling out.  In some environments, mainly smaller environments, the components that facilitate sending and receiving messages (such as IDOCs, BAPIs or RFCs) may be co-hosted on an Application Server.  In some larger environments a dedicated Messaging Server(s) may be provided. We can also use a named destination that we define in our saprfc.ini file.

Up until this point all of my experience integrating with SAP has occurred through an Application Server.  This is the default Connection Type that is populated in the Send Port configuration of a WCF-SAP send port.

Recently I ran into a situation where the SAP environment was not using Application Servers.  Instead a Messaging Server was being used.  The end result was that I received the following error

 

A message sent to adapter "WCF-SAP" on send port "SendGetSAPEquipment" with URI "sap://CLIENT=010;LANG=EN;@b/*SAPSERVER*/*ENV*?RfcSdkTrace=False&AbapDebug=False" is suspended.
Error details: Microsoft.ServiceModel.Channels.Common.ConnectionException: Details: ErrorCode=RFC_OK. ErrorGroup=RFC_ERROR_COMMUNICATION. SapErrorMessage=Connect to message server failed
Connect_PM  MSHOST=*MSHOSTValue*, R3NAME=*ENV*, GROUP=PUBLIC

LOCATION    CPIC (TCP/IP) on local host with Unicode
ERROR       service *SAPSERVER* unknown
TIME        Tue Apr 23 09:38:18 201
RELEASE     700
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      nixxhsl.cpp
LINE        776
DETAIL      NiHsLGetServNo: service name cached as unknown
COUNTER     1.  AdapterErrorMessage=. ---> Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_OK. ErrorGroup=RFC_ERROR_COMMUNICATION. SapErrorMessage=Connect to message server failed
Connect_PM  MSHOST=*MSHOSTValue*, R3NAME=*ENV*, GROUP=PUBLIC

Microsoft.ServiceModel.Channels.Common.ConnectionException: Details:
ErrorCode=RFC_OK. ErrorGroup=RFC_ERROR_COMMUNICATION.
SapErrorMessage=Connect to message server
ailed
Connect_PM  MSHOST=*MSHOSTValue*, R3NAME=*ENV*, GROUP=*MyOrganization*

Since the SAP environment was actually using Messaging Server(s), In order to successfully make a connection to SAP, here is the correct configuration that I needed to provide:

• Application Server Group Name
• Message Server Host
• R/3 System Name
• Connection Type B

These properties will be specific to your environment and therefore I have blacked them out.  You will need to get this information from your BASIS admin.

 

However, this is not enough and this is where I got hung up.  You also need to specify TCP port where SAP will be looking for these connections.  This property is not exposed through the BizTalk GUI.  In order to specify this TCP port you need to modify the following file:

C:\Windows\System32\drivers\etc\services

Within this file you will want to add an entry like:

MSHOST            1234/tcp   # SAP ENV System Message Server Port

Once again these values will be specific to your environment.  I have added fictitious values here.  You may see something like SAPMS<ENV> but once again your mileage may vary.  In all likelihood your TCP Port will not be 1234 (that I made up).  It will likely be 4 digits though.

The most important thing to recognize is that the value in this file (that I have called MSHOST) must match the value that we see in the error message below.  This value will not match any values within your Send Port.

 

It isn’t only BizTalk that will use these values.  Your SAPGUI will also use these same values when connecting to SAP systems.  So if you are stuck, my recommendation is to find a machine that is running the SAPGUI and then copy over those values to the file that exists on your BizTalk Server(s).  I have no idea how this MSHOST value is looked up as the BizTalk Send Port has no knowledge of it. My guess is that at runtime the R3Name in combination of the Message Server Host is somehow used to lookup this MSHOST from this file.

 

Conclusion

Hopefully this blog post will save you some time.  I know that I had a tough time finding information that clearly painted the picture for me...especially in the area of the port# that is found in our services file.