European Trip Recap

 

I recently returned back from Europe where I had a chance to participate in two extraordinary events: Bouvet BizTalk Innovation Day (s) in Stavanger, Norway and the 40th running of the Berlin Marathon.

Bouvet BizTalk Innovation Day–Norway Recap

This was a two day event hosted by Bouvet. For those of you who are not familiar with Bouvet, Bouvet provides services in the fields of information technology, digital communication and enterprise management. Bouvet has about 900 employees divided between 14 offices in Norway and Sweden. - See more at: http://www.bouvet.no/en/About-Bouvet/

On day one each of the speakers had the opportunity to present their topic to a crowd of around 70 BizTalk professionals from all over Scandinavia.  The topics ranged from newer technologies like Windows Azure BizTalk Services, Windows Azure Mobile Services, Windows Azure Service Bus and some more universal topics like being proactive when monitoring the health of BizTalk solutions, BizTalk Mapping Patterns, identifying and rescuing a BizTalk Hostage Project and seeing a preview of the next version of BizTalk360.  There was also a special keynote by Paolo Salvatori who works for Microsoft Italy and is recognized world wide for his abilities. All presentations were very well received as indicated by the attendee surveys.

My presentation focused on Enterprise Mobility.  This is a topic that I have been dealing with at my day job so I had an opportunity to demonstrate some of the areas of enterprise mobility that I have been thinking about lately.  It was also an opportunity to demonstrate a ‘reference’ application that I have been collaborating on with Mikael Hakansson.

Some of the core principles that I have taken into consideration when dealing with Enterprise Mobility include:

• Active Directory Federation: When a person leaves the company and their AD account has been disabled, this “tap” should be turned off for other mobile/cloud based services.
• Leverage a Mobility platform to reduce the diversity required in supporting multiple platforms.  Windows Azure Mobile Services helps us address this by providing APIs for the popular platforms that allow us to centralize activities like Data access, Authentication, Identity Providers, Custom APIs and Scheduled tasks.
• Most, if not all, Enterprise Mobile apps need to consume Line of Business (LOB) System data.  Windows Azure BizTalk Services (and the BizTalk Adapter Service) allow us a secure way in and out of our enterprise without poking holes in firewalls.  I should note that these capabilities are also available with BizTalk Server 2013.
• Accessing On-Premise LOB systems isn’t possible (in my scenarios) without the underpinnings of the Windows Azure Service Bus.  Using this technology to span network layers never gets old. The BizTalk Adapter Service has a strong dependency on these services.
• Data Storage:  Even though I am leveraging SAP master data in this scenario, I do need to maintain the state of the business process.  In this case I am using SQL Azure to host our data.  We can leverage Windows Azure Mobile Services’ APIs that make getting data in and out of the database a breeze.
• Finally, we can’t forget about Toast Notifications.  We want the ability to send notifications out to users (in this case approvers) and Windows Azure Mobile Services helps us deal with sending Toast Notifications to a variety of platforms. 

Here is one of the scenarios from my demo that illustrates many of the principles that were previously mentioned.

     

A few screenshots of the application running in the Windows Phone Emulator:

This was one of the more challenging demos that I have ever been involved in.  I had a lot of fun working on this reference app with Mikael and learned a lot in the process.  My complete slide deck can be found here.

Conclusion

Many people work on bringing events alive, but two people who I would like to recognize are Tord Glad Nordahl and Anders Stensland.  They, in addition to the support Bouvet provided, pulled off a fantastic event.  I have had the opportunity to present in Sweden in 2010 and 2011 and I continue to be amazed by the amount of BizTalk interest in Scandinavia.  If you do have the opportunity to attend the Bouvet BizTalk Innovation conference in the future, I highly recommend it.  They did an amazing job.

40th Berlin Marathon

One of my hobbies is running.  I am a pretty average runner but I enjoy the challenges of running and also try to reap the health benefits of staying active.  I have run over 12 half marathons over the past 6 years and finished my first marathon last year in Chicago.  Whenever I have gone to Europe to speak in the past I have always tried to make a side trip within Europe to experience another culture.  In speaking with one of the other presenters (Steef-Jan Wiggers) we had decided that we would head to Berlin after the conference in Norway.  He recommended going to Berlin to experience its rich history.  Having never been to Germany, myself and my wife made plans to join him in Berlin.

I knew that the Berlin Marathon was held in late September.  The Berlin Marathon is one of the 6 major Marathons in the world.  The others include New York, Boston, Chicago, London and Tokyo.  So when I found out that I would be in Berlin on the same day of this historic event, I couldn’t resist the temptation of participating in this event.

The registration deadline had passed but I was able to find a travel agent from Boston who would sell us packages.  With this information, I presented the opportunity to Steef-Jan and he obliged.  He has recently gotten back into running and this would provide a great opportunity to run his first marathon.

The event itself was rather amazing.  Over 42 000 runners participated in the event with an estimated 1 million spectators.  It was an awesome experience and one that I will never forget.  I finished the marathon in 4 hours 34 minutes and 56 seconds which was 4 minutes faster than my Chicago time.

 

A few pictures:

The prize

 

Before the race.  The garbage bags helped keep us warm while we waited for our turn.

Steef-Jan before the race

 

After the run

 

Celebrating – German style

 

After the race the Adidas store would engrave your time into a running band that was provided as part of your registration.

 

 

One of the best parts of the MVP program is the people you meet and the friendships that you develop.  Without being in the MVP program, this trip would have never happened.  Being part of the program is truly an honor.

Thanks Tord for your hospitality in Norway.  It was a great opportunity to experience my Norwegian heritage and I thoroughly enjoyed your beautiful country. 

Thanks Steef for being an amazing tour guide while in Germany.  Your German came in handy many times and I learned a lot about German history while I was there.  Running the marathon with you was also a great experience.  Next time we won’t do as much sightseeing the day before the race .

I also would like to thank the other MVPs (Sandro, Nino, Saravana) and Paolo for a great experience as well.  Talking shop whenever we get together is a lot of fun and always interesting. 

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.

WCF-SAP User account not in validity date

Recently, I have been working with a new organization and have been been building some interfaces that communicate with SAP. Over the Christmas break I continued to work on some of these interfaces.  On December 31 my interfaces were working just fine.  But, on January 1st, I made a few changes and then ran my BizUnit regression tests just to make sure everything was ok.  To my surprise, my tests were failing and the issue was related to the following error.

It just seemed like too much of a co-incidence that the errors started occurring on the first day of the new year. My gut told me that my account must have expired. At my previous organization the SAP-BizTalk system accounts never expired but they do at this one(which is probably not a bad thing).  The resolution in this case was for the SAP Basis team to update the validity date for the account.  Once this attribute was updated I could re-connect to SAP through my interfaces.  I have no idea why the SAP error message doesn’t just say “your account has expired”.

Exposing common service(s) to SAP and WCF clients

I have a scenario I am dealing with at work that involves exposing some common data to two different systems: SAP and a Custom ASP.Net Web App.  Both of these applications will request BizTalk to fetch some data from a variety of database views, aggregate it and package it up nicely for these calling systems.  Both Systems will be requesting this information on demand – i.e. Synchronously.  SAP will be calling an RFC hosted in BizTalk,via the SAP Adapter, using the method that I identified in a previous post.  The Custom Web Application will be consuming a WCF Service hosted in IIS.

Conceptually, my solution looks like this:

Whenever you have multiple systems trying to consume the same data, you generally  try to utilize a Canonical schema approach.  Canonical schemas allow you to take the different external data formats and transform them into a common internal format before handing them off for processing like in an Orchestration. 

You then perform all of your processing using this internal format to reduce the amount of code/configuration that you require to solve the problem.  Additionally, when you need to make a change, you do so in one place as opposed to two(or multiple) locations.

In order to keep things simple for this POC, I decided to reuse my RFC Add solution where you can have a client pass two numbers to BizTalk, BizTalk will then sum them and provide the answer back to the calling application.

For the Web Client, I will simply expose custom “Web” Schemas as WCF Services using the BizTalk wizard provided within Visual Studio.  Note that I did not want to expose my SAP schemas to my Web Application.  I could have done that but it is not a good practice as any changes to the SAP schemas would impose a change on my Web Application whether it was required or not.  Also, SAP schemas tend to be complex and we don’t want to unnecessarily propagate that complexities onto other applications if we don’t have to.

Initially I thought my solution would be pretty straight forward:

• Generate my SAP Schemas
• Create my Schemas that will be used for the Web Application and expose them via Wizard
• Create my Canonical Schemas
• Create related maps

I then created my logical port and set the Request and Response message types to my Canonical schemas. I deployed my application and configured my Physical Port within the BizTalk Admin Console.  I decided that I was going to re-use the port that was created as part of the BizTalk WCF Publishing Wizard.  I would simply add a Receive Location for SAP and set the appropriate inbound and outbound port mappings. 

Using inbound port mapping is very simple, I can specify multiple maps and BizTalk will detect which Map to use based upon the message type that is being passed.   So if we receive a request from SAP, BizTalk will detect this and use the SAP_to_Canonical.btm map.

 

It then hit me…how will BizTalk determine which Map to use on the Outbound (Response) message? The message being passed to the port will always be the same as it will be my canonical format.  I soon found out.  As you can see in the screenshot below, my SAP response was sent down to my Web Client(which in this case was the WCFTest tool).  Not the desired result that I was looking for.

While chatting with a colleague he mentioned why don’t you try a Direct Bound port.  I have used Direct Bound ports in the past but only in asynchronous scenarios.

So to fix this, I changed:

• My logical Request-Response port to be a Direct bound port and to be Self Correlating.

• Created an additional Receive Port.  I now have a Receive Port for my Web App and for SAP.

• Made the appropriate Inbound and Outbound Port Mappings.  Now each port only has 1 Inbound and 1 Outbound port mapping.

 

• My orchestration will no longer have a Physical Port to bind to since it will be Direct Bound to the MessageBox

• Now when I execute my test from the WCF Test Client, I get the correct result in the WebAddResponse message type that I am expecting

• I am also getting the correct response from SAP

Conclusion

The magic in this solution is really the Request-Response direct bound port.  The idea is that our Orchestration will place a subscription on our Canonical Request message.  It doesn’t really matter how that message gets into the MessageBox as long as it is there.  In this case we have exposed two end points, one for SAP and one for our Web App.  In both scenarios they will take their specific Request message and transform it into our Canonical message and therefore our Orchestration will pick it up.

Request-Response ports always use a form of Correlation so that it can provide the correct Response back to the calling client.  We can take advantage of this mechanism to ensure we get the correct Canonical Response message which in turn can use Outbound Port mapping and send our response in the correct format to the calling application.

Testing your RFC hosted in BizTalk from SAP

In a recent blog post I discussed how you would host an RFC in BizTalk that SAP could call.  I thought it would be helpful if I also included a post that would discuss how you can test your BizTalk Hosted RFC.  Like most BizTalk Developers, I wanted to be able to perform some tests on my own without bothering our SAP team.  So by following these steps I was able to perform some tests on my own.

NOTE: Performing the following steps will require developer permissions in SAP. I suspect that with this kind of access I could get myself in all kinds of trouble.  Luckily for me, our SAP Security team didn’t ask me too many questions when I requested access. 

 

Testing

• Execute the SE37 “ABAB Function Modules” transaction.
• Type in the name of your Function Module.  In my case it is ZISU_RFC_ADD and then click the Test/Execute button highlighted in Red or press F8

• We now have the opportunity to provide our inputs.  If you recall from my previous post, this RFC will accept two integer inputs and then provided the sum in the response message.  Once we have our two inputs populated we can click on the Execute button (highlighted in red) or click the F8 button.

 

• Our result will now be displayed on screen and we will discover how long it took to get the result.

 

Exceptions

So what happens if BizTalk is not available when you perform one of these tests?  I was curious as well so I simply disabled my receive location, executed my test and received the following result.

Its not pretty but it describes that the “program BizTalk_Z_Add” is not registered.  This is saying that our listener that is using this Program ID is not online. This is a similar error message that we receive during a failed Connected Client test from SM59.

Conclusion

SAP can be a very large and daunting system at times but the more and more I get into it the more comfortable  I feel about its ability to integrate with other systems.  Tools like this one (SE37) and the IDOC resubmit transaction(WE19) can be a BizTalk dev’s best friend when integrating with SAP.

SAP calling RFC hosted in BizTalk

If you have been following this blog you have most likely encountered a few blog posts related to SAP integration.  I also wrote two chapters related to SAP integration in a BizTalk book last year.  In all of the journeys that I have taken with SAP, not once have I encountered a situation were I needed to receive a request from SAP that required a synchronous response.  All of my previous experience required asynchronous messaging with SAP when receiving data from SAP.  We now have a scenario that requires SAP to send BizTalk a “fetch” request and BizTalk needs to provide this information in near real-time.  What was very interesting about this scenario many people within our organization didn’t think, or know it was possible.  I guess it was tough for some to wrap their head around the concept of SAP actually needing information from another system since it tends to be a System of Record.

SAPRFC.INI HUH???

A good starting point for this scenario is in the MSDN documentation.  Initially I thought it would be pretty straight forward and would resemble a situation where BizTalk receives an IDOC.  That was until I received an error similar to the one below indicating that an saprfc.ini file could not be found when enabling the SAP Receive Location.

Log Name:      Application
Source:        BizTalk Server
Date:          3/6/2012 7:12:53 PM
Event ID:      5644
Task Category: BizTalk Server
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SERVER

Description:
The Messaging Engine failed to add a receive location "Receive Location2" with URL "sap://CLIENT=010;LANG=EN;@a/SAPSERVER/00?ListenerDest=ZRFCADD&ListenerGwServ=sapgw00&ListenerGwHost=SAPHOST&ListenerProgramId=Biztalk_Z_Add&RfcSdkTrace=False&AbapDebug=False" to the adapter "WCF-SAP". Reason: "Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_OK. ErrorGroup=RFC_ERROR_SYSTEM_FAILURE. SapErrorMessage=Open file 'C:\SAPINI\saprfc.ini' failed: 'No such file or directory'.  AdapterErrorMessage=Error accepting incoming connection. RfcAccept returned RFC_HANDLE_NULL..
 

This really confused me since I could successfully connect to SAP and receive IDOCs.  After some digging, I discovered the following webpage that indicated: “The RFC library will read the saprfc.ini file to find out the connection type and all RFC-specific parameters needed to connect to an SAP system, or to register an RFC server program at an SAP gateway and wait for RFC calls from any SAP system.”

So how do we solve this?

• The first thing that we need to do is to create a System Variable called RFC_INI.  We then need to provide a path and a filename.  For the purpose of my example I used C:\SAPINI\saprfc.ini.

• Next we need to add the contents to our saprfc.ini file.  The values that I needed to provide include:

Field name	Value
DEST	ZRFCADD	In this case, this is the name of the RFC Destination that our BASIS team created for us from SM59.  More details here.
TYPE	R	Type R is for RFC server programs or for a client program working with another external program as RFC server program which is already registered at an SAP gateway.
GWHOST	SAP_HOST_NAME	In my case, this is the name of the physical server that his hosting the SAP Gateway.
GWSERVER	SAP_GATEWAY_NAME	The name of the SAP Gateway.  A standard naming convention is: SAPGW## where ## is the system number for the SAP instance that you are working on.
PROGID	Biztalk_Z_Add	This is the name of the Program ID that has also been provided by BASIS.

 

So if we compare the details between our Receive Location and our saprfc.ini we will see symmetry between the two.  However, the values in the ini file take precedence.

• Now that we have have our SAPRFC.ini file and SAP Receive location in order we can run a connected client test using SM59.  To perform this test, launch the SM59 transaction and then expand the TCP/IP Connections node.

• Scroll through the list to find your RFC Destination.  In my case, I am looking for ZRFCADD.  Double click on this value.

• Click on the Connection Test button to execute the test.

• You should see a successful Connection Test.  If not, there is no point trying to call your RFC from SAP until you get this connection issue resolved.  If SAP can’t perform this “ping test” it won’t be able to actually send you data.  To troubleshoot this you will need to ensure that the values that you have in your receive location/ini file match the values that are defined in SM59.  In most cases you will need to rely upon your BASIS Buddy to help you out.  As I mentioned in my book, I do have a good BASIS buddy so this troubleshooting usually goes smoothly.

• With our connectivity issues out of the way, we can browse for our desired schemas using the BizTalk Consume Adapter Service Wizard and then add them to our solution.

• We can now build out the rest of our application.  In my case I have a very simple map that will add two values that occur in the request message and provide the sum in the response message.

• The only special consideration that we need to take care of is to set the WCF.Action in the Response message.  We can do this inside a Message Assignment shape.  If you don’t take care of this, you will receive a run time error.

sapResponse(WCF.Action) = "http://Microsoft.LobServices.Sap/2007/03/Rfc/ZISU_RFC_ADD/response";

We now are in a position to deploy our application and start receiving requests from SAP.

Conclusion

Overall the process was pretty similar to receiving IDOCs with the exception of the INI file and the WCF Action property requiring being populated.  Performance is similar to receiving or sending IDOCs so you won’t take any additional performance hits.

BizTalk 2010: Line of Business Systems Integration Book has been released

For the past 10 months I have been involved in a project with 4 other talented individuals.  This project was a little different than the projects that I have been involved with in the past.  While other projects have always had some sort of documentation deliverable, documentation, in the form of a book was the main deliverable this time around.

While many BizTalk books exists, we felt there was an opportunity when it came to discussing Line of Business integration with BizTalk Server 2010.  With the amount of talent involved in this book, I am very confident we have filled some of the void that exists on this topic.

I would like the thank the following authors for their tremendous efforts:

• Richard Seroter
• Sergei Moukhnitski
• Thiago Almeida
• Carl Darski

I also want to thank our Technical Reviewers who spent a lot of hours reviewing our content and definitely increased the quality of the book:

• Ben Cline
• Stephen Thomas
• Mick Badran

You may now find the book available on the Packt Publishing site and on Amazon.com.

BizTalk 2009 64 bit - Don't forget to run BizTalk Adapter v2.0 for mySAP Business Suite in 32bit host

Note: this post is strictly related to the .Net Connector version of the SAP adapter and NOT the WCF based LOB Adapter.


When using the BizTalk Adapter v2.0 for mySAP Business Suite adapter on a 64bit machine, don't forget to run your Host Instance as a "32 bit Host".

Otherwise you will get prompted with the following error:




Log Name: Application
Source: BizTalk Server 2009
Date: 10/15/2009 10:54:28 AM
Event ID: 5697
Task Category: BizTalk Server 2009
Level: Error
Keywords: Classic
User: N/A
Computer: Server
Description:
The Messaging Engine encountered an error when intializing the receive adapter "SAP", HRESULT:"Retrieving the COM class factory for component with CLSID {1EB415A4-242C-4E28-9E9C-33367784F01E} failed due to the following error: 80040154.".
Event Xml:
<event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><system><provider name="BizTalk Server 2009">
<eventid qualifiers="49344">5697</eventid>
<level>2</level>
<task>1</task>
<keywords>0x80000000000000</keywords>
<timecreated systemtime="2009-10-15T16:54:28.000Z">
<eventrecordid>21227</eventrecordid>
<channel>Application</channel>
<computer>Server</computer>
<security></system><eventdata>
<data>SAP</data>
<data>Retrieving the COM class factory for component with CLSID {1EB415A4-242C-4E28-9E9C-33367784F01E} failed due to the following error: 80040154.</data> </event>



Change the Host to 32 bit, restart Host Instance and you should be fine. The reason for this is that the pre-requisite SAP Dot Net connector does not support native 64 bit. Here is a link for more details.

BizTalk Adapter v2.0 for mySAP Business Suite - Could not open a connection to SQL Server

During a non-production dry run implementation of BizTalk 2009 yesterday, we ran into the following error when an application that uses the SAP Adapter (.Net Connector Version) received an IDoc.

Note: this post is strictly related to the .Net Connector version of the SAP adapter and NOT the WCF based LOB Adapter. We have some applications that we have not migrated to the new adapter. It is on our "to do" list, but our upgrade scope is primarily a "like for like" upgrade.


Event Type: Error
Event Source: BizTalk Adapter v2.0 for mySAP Business Suite
Event Category: None
Event ID: 0
Date: 10/13/2009
Time: 4:23:28 PM
User: N/A
Computer: Server
Description:
Error in Check Transaction: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

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



The first clue that something was wrong was that SAP did not show up in the configured list of Adapters. We were able to add it by right clicking on "Adapters" - "New" - "Adapters" before we turned on the application but that should have been our first indication that something wasn't quite right. We then checked for the existance of the following Stored Procedures that are added to the MessageBox database when you install the SAP Adapter:
- Mp_Sap_check_tid
- Mp_Sap_delete_tid
- Mp_Sap_insert_tid

These stored procs were not installed which prompted us to re-install the adapter. We also ensured to use the /console command when launching the Remote Desktop Connection tool. Upon removing the old adapter via control panel(repair didn't work) and re-installing the adapter we now had "SAP" showing up in the adapter list and the stored procedures were successfully added to the MessageBox Db. At this point we were able to successfully receive an IDoc from SAP.

BizTalk 2009 64bit: Missing sapBinding in BizTalk admin and VS .Net 2008

I have been running BizTalk 2009 for quite some time now including the Beta version. Up until now, all of the work that I have been doing was on a 32bit platform. Now that we are moving to a 64bit platform, I am starting to run into some more challenges related to 64bit.

I installed the 64bit version of the WCF SDK SP2. I then went and installed the 64bit version of the BizTalk Adapter Pack 2.0. I opened a project that I had previously built on a 32 bit machine and successfully deployed the application to my 64bit laptop. When I attempted to import the binding file that had been previously used on the 32 bit solution, I got the following error:

At this point I tried to create a new send port that uses the Custom WCF Adapter. I clicked on the "Binding" tab and then on the pull down to see just what bindings had been registered. Here is what I found:

As you can see the sapBinding is no where to be found. I was curious to see what Visual Studio was seeing when I called upon the Consume Adapter Service. The error message that I received was "No valid adapters are installed on this machine"

After some digging, I was able to find the following link on TechNet which discusses the SQL Adapter, however the behaviour applies to the SAP Adapter as well.

Cause
The SQL adapter is a WCF custom binding, which is registered under System.ServiceModel in the machine.config file. A 64-bit platform has two machine.config files, one used by the 32-bit applications and the other used by the 64-bit applications. So, when you install the 64-bit version of the BizTalk Adapter Pack, the setup wizard registers the bindings in the 64-bit version of the machine.config file. However, Visual Studio runs as a 32-bit process and hence when you launch the Consume Adapter Service Add-in from Visual Studio, the plug-in checks for the bindings in the 32-bit version of the machine.config file and fails giving an error.

Resolution
Install both the 32-bit and 64-bit versions of the BizTalk Adapter Pack on a 64-bit WCF LOB Adapter SDK installation.

The document also stresses that you should only install the 64bit version of the WCF SDK SP2 as you cannot run this SDK side by side (32 & 64 bit)

So this explanation deals with Visual Studio, but what about the BizTalk Admin Console? Well, it runs as a 32 bit process as well which explains why the Adapter is not visible inside the console. After installing the 32bit BizTalk Adapter Pack 2.0, the sapBinding will now appear.

Suddenly, I am not as excited about the 64bit platform as I was previously.

BizTalk Light and Easy Viewing Series - SAP Adapter

A couple months back Mick Badran, a BizTalk MVP from Australia, got a few MVPs and other BizTalk experts together to put on a series of webcasts that cover various topics in BizTalk Server 2009.One of the topics that I decided to tackle was the new SAP Adapter ( as found in BizTalk Adapter Pack). In this webcast I cover the following topics:

• SAP Background Information
• Why do companies use SAP
• Challenges with integrating with SAP
• Previous SAP Adapters
• BizTalk Adapter Pack 2.0
• Demos

Alan Smith has launched a site that will host the Light and Easy series in addition to other Microsoft related webcasts. If you are interested in seeing this webcast here is the link: http://www.cloudcasts.net/ViewWebcast.aspx?webcastid=2521554266599869567

If you have any questions or comments about the webcast, feel free to leave a comment on the blog.

BizTalk Adapter 3.0 vs SAP Enterprise Services

For those of you who are interested in integration with SAP, there is a document worth reading called Positioning SAP Enterprise Services vs Microsoft BizTalk Adapter 3.0 for mySAP Business Suite. The document itself describes the different scenarios in which you can use the BizTalk Adapter Pack 3.0 when integrating with SAP. These scenarios include:

• .Net Based Applications
• SQL Server 2005 Integration Services
• SQL Server 2005 Reporting Services
• Sharepoint
• and of course BizTalk.

In case you are not aware, the BizTalk Adapter packs are based upon WCF and therefore can be run outside of BizTalk even though they are branded "BizTalk". The Adapter pack itself is included in the license of BizTalk, but you cannot run the Adapter pack on a server without BizTalk unless you have a separate license for it or you do not have BizTalk installed. See the Adapter pack pricing page for more licensing info.

In my last post, I discussed how the SOAP and SQL Adapters have been deprecated for BizTalk 2009. Well, you can add another adapter to the list and that is the Microsoft BizTalk Adapter v2.0 for mySAP Business Suite. This is the adapter that originated in BizTalk 2006 R1 on the Microsoft BizTalk Adapters for Enterprise Applications cd.

The primary objective of this document is to discuss the scenarios where you would want to use the BizTalk adapter versus when you would want to use the Web Service capability of Enterprise Services. SAP ECC 6.0 natively provides Web Service capabilities. So this document is probably to address those opinions that if SAP has Web Services then why do I want to use BizTalk,or the Adapter pack, to exchange data between SAP and another application?

Here are a couple of ideas that I can think of:

• Avoid point to point integration scenarios
• Take advantage of BizTalk's transformation(mapping) capabilities
• Durable messaging (retries, persistence)
• Monitoring(MOM,SCOM)/Tracking(HAT,BAM)
• Managing a Business Process between multiple systems.
• Adapter provides reliable, performant and secure data transmissions.