Tuesday, January 04, 2005

SAP Adapter for Biztalk 2004 - Tips

After uninstalling the SAP .NET Connector v2.0 and installing version 1.0.3, I finally got the BizTalk SAP Adapter to work. Here are some tips for those who are using the Adapter but do not understand SAP:

There are two types of SAP server hosts that can be used in the Send Port: ASHOST or Application Sever Host and MSHOST or Message Server Host. For Send Port, there is a choice of ASHOST and MSHOST. To use the ASHOST fill in the Application Server data. This includes Client, Language, System, and System ID. To use the MSHOST, fill in the Message Server data only. This includes Group, Message Server, and R3Name. For both servers, the username and password must be included. You can tell which server you have implemented by the Adapter Namespace created after pressing "OK". You will see either sap://AS.. or sap://MS...

For the Receive Port, an SAP gateway host is used. I have not spent much time working with the Receive Ports, but from what I can tell the following must occur:

• The .NET program must register itself on the SAP gateway host (The Receive Function does this for the developer)
• The SAP system and the .NET program must implement the same method interface, for example, the function module name and parameters from the SAP system.
• The SAP system initiates the call to the .NET program using the CALL FUNCTION DESTINATION keyword (Important for the SAP Developer)
• The .NET program must return the appropriate parameters to the SAP system.

Virtual Biztalk Server Labs

This is from Scott Woodgate's blog.

Microsoft has set up a Virtual Lab that allows users to go over BizTalk 2004 with out installing BizTalk. This will be very handy for new users and for people like me who have knowledge of such items as the Business Rules, but have not implemented them. Before development, I can use this as a refresher course.

One last thing, the Firewall port must be open.

http://msdn.demoservers.com

BizTalk SAP Adapter and SAP .NET Connector v2.0

My previous post was incorrect. I was working on the SAP Adapter for BT2004 last week and kept thinking that my lack of knowledge with SAP was preventing me from being able to use the adapter. However, it turns out it was lack of compatibility with the SAP .NET Connector that was the problem.

I was starting to think that was the problem, but I needed proof for the client. So we asked Microsoft and the answer is that no the 2.0 connector does not work with the BizTalk SAP Adapter. The steps to install the correct version are as follows:

If you are running the 2.0 adapter you need to do the following:

1. Remove the SAP adapter from the Biztalk Admin console

2. Uninstall the SAP adapter for Biztalk 2004

3. Uninstall the 2.0 connector

4. Install the 1.0.3 connector from your SAP download location.

5. Install the SAP adapter again.

Next step for me, as I am having a hard time getting version 1.0.3, is to create a custom adapter using version 2.0 of the .NET connector.

SAP Adapater v2.0 for Biztalk Exception

After installing the SAP Adapter v2.0 on my local server, I tried to setup a receive location and a send port using the adapter. I created the receive location but started getting the following error:


The Messaging Engine failed to create the receive adapter "SAP". Reason: "Exception has been thrown by the target of an invocation."


I removed the receive location, but continued to get the error. After trying many different things, including changing the permissions on the Bin folder under the Program Files...SAP Adapater directory, I refreshed the host instance the adapter was running under. The error disappeared. The error does come back when I enable the receive function, though I do believe I have the incorrect information in the receive function, which causes the error.


File Receive Location

Recently I ran into a situation where a file receive location was intermittently becoming disabled with the error:

Event Type: Error
Event Source: BizTalk Server 2004
Event Category: BizTalk Server 2004
Event ID: 5649
User: N/A
Description:The receive location "[FilePath]InputInterfaceFiles\MM*" is shutting down. Details:"The FILE receive location [FilePath]InputInterfaceFiles\MM* exhausted the network retry attempts. ".

Currently there are several receive locations setup to point to the same directory. The directory is on a remote server, but the network between the servers is very reliable. And it seemed that since only one receive location was disabling, that the network was not the cause.

To solve this, I had developed an EnableReceiveLocation script that would run using the Scheduled Tasks. But, I wanted to know why the receive location was disabled. Microsoft provided me the answer. The File Receive Locations can poll the directory as well as use the folder change event. When both the change event and the polling action occurs at the same time, the receive location becomes disabled. The directory polling can be changed or disabled using the registry values found in File Adapter Configuration and Tuning Parameters.

SuspendedQListener Resumable Items

In order to ensure that both the suspended and suspended_resumable items events are raised through the SuspendedQListener the AddWatcher select statement must be changed to:


eventWatcher = new ManagementEventWatcher( new ManagementScope("root\\MicrosoftBizTalkServer"), new EventQuery("SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA 'MSBTS_ServiceInstance' AND (TargetInstance.ServiceStatus = '4' OR TargetInstance.ServiceStatus = '32')"));

The ServiceSuspendedEventHandler and the startListening select statements must be changed to:


"SELECT * FROM MSBTS_MessageInstance WHERE ServiceInstanceStatus =" + (uint)ServiceInstanceStatus.Suspended_Not_Resumable + " or ServiceInstanceStatus = " + (uint)ServiceInstanceStatus.Suspended_Resumable;

Most of the time items are suspended with out being able to be resumed, but items will become resumable if the receive location is enabled, but the send port has been stopped.


MSBTS_ServiceInstanceSuspendedEvent Issue

The MSBTS_ServiceInstanceSuspendedEvent does not fire when the data is suspended as resumable.


To ensure that the resumable suspended item is noticed, the following WMI select statement must be used in the SuspendedQListener:


SELECT * FROM MSBTS_MessageInstance WHERE ServiceInstanceStatus =" + (uint)ServiceInstanceStatus.Suspended_Not_Resumable + " or ServiceInstanceStatus = " + (uint)ServiceInstanceStatus.Suspended_Resumable;


The SuspenedQListener does not have the ServiceInstanceStatus.Suspended_Resumable value in the select.