Off Topic: Introducing BizTweet for Windows Phone 7

In addition to blogging about BizTalk, I have decided to start blogging about Windows Phone 7.  Therefore, I have created a new blog to focus on WP7 and will continue to blog about BizTalk here. 

I recently had my first WP7 App published in the marketplace.  The app is called BizTweet and may be found in the Social category.  The purpose of the application is to aggregate information related to BizTalk and AppFabric.  So if you have a WP7 and are interested in BizTalk and/or AppFabric then I encourage you to check it out. 

For more details, check out the BizTweet blog post.

BizTalk: HTTP Adapter and preventing Cached Responses

A while back I blogged about a service that would go fetch Natural Gas Prices, the price of Oil and Stock Quotes from Yahoo.    The information that is returned from BizTalk is surfaced in an Xcelsius dashboard along with a lot of other business critical data from SAP.  Our executive team accesses this information from a web part in SharePoint site.  As people launch their browsers, they see the Stock Quotes and other commodity prices get updated.  Since this is a dashboard, people will view the data for a few minutes and then close their browser.  This type of user behavior never uncovered a flaw in the application.  It is not like someone sat on the dashboard all day long waiting for the stock price to change.

A request came in to turn this Dashboard into a Windows 7 widget.  Once this widget was in place, we uncovered that the stock quotes were not being updated.   The Widget simply acts as a container for the dashboard.  So we dug out Fiddler and could determine that the BizTalk service was not being called on a regular interval.  The reason?  Caching.  There was no cache command or expiration date sent on the HTTP header going back to the dashboard so it would not be called on a regular basis.  Since this Widget does not get restarted like a Web Browser does, the stock quotes would remain static for the duration of a user’s desktop session.

To avoid this situation, I needed to provide an explicit command in a Message Assignment Shape to prevent my responses from being cached:

msgStockQuoteResponse(HTTP.UserHttpHeaders) ="Cache-Control: no-cache";

Since the client was instructed not to cache the response, it would now go ahead and call the service when it goes to refresh the rest of its data.

 

 

There are many options that you can set within the HTTP Header.  For example,  if you wanted to expire content every 2 minutes, you could set your header to  Cache-Control: max-age=120.  If you are interested in what other features can be set in an HTTP Header, I recommend checking out this site.

BizTalk 2010 – RTM has arrived!

 

As you are probably aware by now, BizTalk 2010 has RTM’d.  You can catch the announcement here.  I am not going to recap all of the new features as you can read about them here.  However, here are a few points worth noting about the new release.

• The  BizTalk 2010 Developer’s edition is now free.  So if you are curious about BizTalk and getting a licensed copy has been a barrier for you in the past, now is your chance to test drive BizTalk at no cost.  Full details and download may be found here.
• For those AppFabric/WCF/WF developers, there is a new compelling feature called BizTalk AppFabric Connect which allows you to leverage BizTalk components such as the BizTalk LOB Adapter Pack and BizTalk Mapper within your .Net projects. This is a true enabler for connecting your WF applications to Line of Business Systems (LOB)
• If you have written applications in the past that have used the traditional line of business adapters, you will now be forced to use the BizTalk Adapter pack when communicating with SQL Server, SAP, Oracle and Siebel.  Microsoft had deprecated these adapters in BizTalk 2009 and they have been officially removed in 2010.  For the past year or so, I have been using the BizTalk Adapter pack when communicating with LOB systems and there are some subtle differences between the legacy and new LOB adapters. Overall, I am satisfied with the experience and there are no “show stoppers” that we have run into  when making the switch.  So if you are planning a BizTalk 2010 upgrade and currently use the legacy adapters, ensure migrating these applications to use the BizTalk adapter pack is in your project plan as you will need to regenerate schemas using these new adapters.

BizTalk 2009 + SharePoint 2010

 

Note:  The following steps do not represent a supportable configuration by Microsoft and extreme caution should be used when following these steps.  To my knowledge, these steps are complete, but it is possible that I missed something.  These steps have been tested in a Send Port Subscription scenario.   Use these instructions at your own risk.

At the organization that I work for, we are rolling out SharePoint 2010.  We currently run BizTalk 2009 and  at this point in time, the  BizTalk 2009 SharePoint Adapter Web Service isn’t supported with SharePoint 2010.  BizTalk 2010 has been updated to support SharePoint 2010.  We really have no choice but to head in this direction since upgrading to BizTalk 2010 just isn’t an option at this point in time.

When you launch the BizTalk 2009 installation on a SharePoint 2010 Server you will not be able to install the Windows SharePoint Services Adapter Web Service as it is not able to detect the pre-requisite Windows SharePoint Services v 3.0 files.

Mick Badran has a post that helped me out tremendously. However, I found that I had to take a few additional steps so I will recap exactly what we did in order for us to get this to function in our environment.

We had an existing MOSS 2007 server that had the BizTalk Adapter Web Service installed and functioning correctly.  Since you cannot use the BizTalk installation wizard to install this Web Service, we decided to reverse engineer what was deployed on MOSS 2007 and manually deploy on SharePoint 2010.

• Copy the c:\program files\Microsoft BizTalk 2009 folder from your MOSS 2007 Server to your SharePoint 2010 Server
• Create the BTSharePointAdapterWS Web Application in IIS Manager and set the physical path to C:\Program Files (x86)\Microsoft BizTalk Server 2009\Business Activity Services\BTSharePointV3AdapterWS 

Note: This path represents a 64 bit installation.

• We leveraged the existing App Pool that the SharePoint Site was using
• Modify the web.config to set the appropriate SharePoint Enabled Hosts, if required.  For us, we use AD Groups and had to change to reflect our “DEV” AD group
• Rebind the Microsoft.SharePoint.dll to point to version 14.

• We removed the Document Tag so that we could browse the WSDL properly.  See this post for more info.

 

• We then exported two keys from the Registry on our MOSS 2007 Server and import them on your SharePoint 2010 Server:
  • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server]
  • [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\BizTalk Server]
• At this point we thought we were done and attempted to push a message from BizTalk 2009 to SharePoint 2010 but discovered the following message in event viewer:

 

Event Type:    Warning
Event Source:    BizTalk Server 2009
Event Category:    (1)
Event ID:    5743
Date:        9/10/2010
Time:        1:37:51 PM
User:        N/A
Computer:    SERVER

Description:
The adapter failed to transmit message going to send port "SendPort1" with URL "wss://SERVER:80/DropOffLibrary". It will be retransmitted after the retry interval specified for this Send Port. Details:"System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.BizTalk.KwTpm.OfficeImporters2, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.BizTalk.KwTpm.OfficeImporters2, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
   at Microsoft.BizTalk.KwTpm.WssAdapter.BTSharePointAdapterWS..ctor()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

   --- End of inner exception stack trace ---

This error was triggered by the Windows SharePoint Services receive location or send port with URI wss://SERVER:80/DropOffLibrary.

Windows SharePoint Services adapter event ID: 12462".

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

 

Once again it was back to the MOSS 2007 server and more specifically, a trip to the GAC where we discovered the following BizTalk Dlls.  This list included the Microsoft.BizTalk.KwTpm.OfficeImporters2.dll that was mentioned in the event viewer.  We then pulled these dlls off of the installation CD and gac’d them on the SharePoint 2010 server using gacutil.

After Gac’ing these assemblies we had success pushing messages from BizTalk 2009 to SharePoint 2010.

 

Note: There is another option which I have not tried that Kirk Hofer discusses here.  It involves installing WSS v3.0 SP2, but not configuring it, so that the BizTalk install Wizard thinks it is installed.  Our SharePoint team was not crazy about having these other dlls on their fresh SharePoint 2010 server so we were unable to proceed with this approach.

Managing your BizTalk Environment using SCOM

I recently had the opportunity to speak at the Swedish BizTalk user group in Stockholm. It was an excellent opportunity to present to one of the top BizTalk user groups worldwide. My presentation consisted of slide ware, a tour of the SCOM 2007 R2 console and several BizTalk/SCOM demos using BizTalk 2010 beta and the BizTalk 2010 Management Pack beta. You may find the presentation below.

BizTalk integration with SharePoint and the Cloud Presentation

I recently had the opportunity to speak at the Calgary .Net User Group. My presentation included slideware and demonstrations involving integrating BizTalk with SharePoint 2010 and the AppFabric Service bus. You can view the presentation below:

BizTalk 2010 Beta – Where are the AppFabric Service Bus bindings?

After installing the Windows Azure platform AppFabric SDK V1.0 - April Update I was expecting all of the AppFabric Service Bus relay bindings to be available inside of the BizTalk Admin Console but they were not.  I could run the AppFabric Echo .Net Sample without any issues.  After re-installing both the AppFabric SDK and BizTalk 2010 Beta I was still unable to find these bindings in the Admin console.  I checked the machine.config files (both 32 bit and 64bit) and both files were updated.  The problem with this is that I checked the .Net 2.0 config files.

After stumbling across Wade Wegner’s blog, the picture became much clearer.  Wade explains “I soon realized that the issue was the machine.config file.  When you install the Azure AppFabric SDK the relevant WCF extensions are added to the .NET Framework 2.0 machine.config file, which is shared by .NET Framework 3.0 and 3.5.  However, .NET Framework 4.0 has its own machine.config file, and the SDK will not update the WCF extensions.”

To resolve the issue you need to run a utility called: RelayConfigurationInstaller.exe which can be found in C:\Program Files (x86)\Windows Azure platform AppFabric SDK\V1.0\Assemblies (64 bit machine) or C:\Program Files\Windows Azure platform AppFabric SDK\V1.0\Assemblies (32 bit machine) and provide an input file that includes

<?xml version ="1.0"?>
<configuration>
<startup>
<requiredRuntime safemode="true"
imageVersion="v4.0.30319"
version="v4.0.30319"/>
</startup>
</configuration>

The name of this file should be called RelayConfigurationInstaller.exe.config.

example:

C:\Program Files (x86)\Windows Azure platform AppFabric SDK\V1.0\Assemblies>RelayConfigurationInstaller.exe /i

After this command was run successfully, I could now see the “Cloud Bindings” including the NetTcpRelayBinding