Ben's profileMS Innovations BlogPhotosBlogListsMore  |  Tools Help |
|
|
November 09 WCF-SQL Adapter's Database Schema GotchaIntroduction
On a recent project I was working with BizTalk 2009 and SQL 2008 and the customer was interested in moving some database objects to a new SQL database schema (for example, from dbo to MySchema). In this post, I refer to types of schemas: BizTalk schemas (XSDs) and database schemas (SQL security mechanism).
I had been interacting with these database objects using the WCF-SQL adapter from the BizTalk Adapter pack. Typically, BizTalk's port abstraction will take out all description of the physical connectivity details and provide you with a connection independent message type. Connectivity details are stored in the port properties and persisted as binding information. Through the use of the Adapter pack wizard, BizTalk schemas are created for interacting with various adapter data sources such as with the WCF-SQL adapter and SQL databases.
Initial Observations
So initially I expected the database schema change would not be a problem because the database object details were all specified as properties of the port. I modified the following port properties to point to the new schema, expecting this to work:
I restarted my BizTalk application and hosts and I started getting errors that referred to my old database schema. At this point I realized that the database schema is actually hard coded during the BizTalk schema generation process. This is a significant gotcha; that the changing of the database schema for custom objects that BizTalk uses requires a regeneration of the BizTalk schemas. The next section describes the steps I went through to correct the old database schema references after moving my database objects to the new database schema: Resoluton In addition to the deployment steps done above, I had to update several of my BizTalk solution artifacts. For my BizTalk solution, I was working with 5 different database objects and I did not want to delete all of my BizTalk schema files (approx. 15 different files) and go through the adapter wizard so many times. I decided to opt for a find and replace solution instead. Here are the steps I did to replace the old database schema references:
Conclusion This post has shown that a change to the database schema for SQL objects can have a major ripple effect on a BizTalk solution that uses the WCF-SQL adapter. I do not expect that changes to database schemas occurs very often so you may never encounter this but if you do, be prepared for a little bit of work to get the updated database schema names back into your solution. Thanks for reading! November 05 Configuring BAM Tools on W2K8 R2Introduction
To continue my tradition of trying BizTalk in unsupported (or not fully supported) environments, I have been working with BizTalk 2009 on Windows Server 2008 R2 on 64-bit. This OS is being used at my current client and I have been able to configure everything in BizTalk to work except for the BAM Tools / BAM Alerts functionality.
I had posted on setting up BAM with SQL 2008 a few months ago and once the 4 hotfixes were released, I was able to get everything working on a single machine after applying the hotfixes and reconfiguring BizTalk. The current release of the BizTalk install/setup guides only go so far as supporting W2K8 R1 but do not officially announce support for R2. This is due to the way the dates lined up around the BizTalk 2009 release, but I always wonder if there are any issues, especially breaking ones.
This post walks you through a hurdle I encountered configuring BAM Tools in a multi-server environment.
System Configuration
Here is the configuration I am trying now:
Configuration Issues After applying the 4 hotfixes I try to configure BAM Tools. I am getting the following error:
This error looks similar to the one I had back on October 30, 2008 in this post: http://msinnovations.spaces.live.com/blog/cns!62E68922E47BC425!400.entry. With the changes to SQL 2008, the workstation tools were moved into a different package component known as the Management Tools. The similar error was resolved with SQL 2005 by installing the Workstation Tools on the BizTalk server. I was able to resolve the above error by checking the Management Tools (Basic & Complete) SQL 2008 features as shown in the screenshot:
 Conclusion
As software products change, their names and subsystems also change. But the documentation for the products usually changes slower so there is often a small gap to watch out for. I found one when configuring BAM Tools for BizTalk 2009 with SQL 2008 on Windows Server 2008 R2. This post can also serve as some of the scant evidence that BizTalk 2009 runs successully on Windows Server 2008 R2, but the issue described above might be one of the supportability gaps.
Thanks,
November 04 BizTalk 2009 on Visual Studio 2010 Beta 2If you saw my posts a few months ago, I was testing BizTalk 2009 compatibility with VS 2010. My earlier posts found that the BizTalk extensions would only load in VS 2008 and not in VS 2010. In this post, I do a refresh of the install experience and give some preview of the .NET 4 features showing up in BizTalk 2009. The same conclusion about compatibility is reached here: the BizTalk 2009 extensions do not work with VS 2010. There is a new workarounds for getting a VS 2008/VS 2010 environment for working with BizTalk 2009.
Application Install Order
BizTalk Configuration Then when configuring BizTalk on the first step for Enterprise Single Sign-On I get an error similar to this (cannot remember exact wording sorry):
Cannot connect to SSODB (Win32)
0x80131700
I found this blog post about re-regasm-ing the SSOSQL assembly: http://blogs.msdn.com/ashishme/archive/2009/08/14/fixing-biztalk-entsso-failure-on-windows-7-vista-or-server-2008-after-vs-2010-beta-installation.aspx#comments. This helped me get around the error when configuring SSO. It is interesting that the problem occurs when VS 2010 is install prior to or after BizTalk 2009. I was then able to go through the BizTalk configuration wizard successfully. I was able to create BizTalk projects in VS 2008 fine. I did open the VS 2010 extensions manager and check for the BizTalk extensions but they are not showing up there.
There are quite a few valuable improvements with WCF 4 such as WS Discovery support, routing, and additional changes to Windows Workflow. All of these will have an impact on the Connected System landscape. Enjoy!
October 30 BizTalk 2009 Roadshow in ChicagoOn December 4th I will speaking on the ESB Toolkit 2.0 under the topic "Improving Business Agility with an Enterprise Service Business" This roadshow is actually going to be happening in 20 cities across the world. The roadshow is a morning series of keynotes followed by some food.
Here is a link on this event: https://microsoft.crgevents.com/BusinessIntegration2009/Content/Default.aspx?p=Home
Please join me at this free event!
Thanks! October 22 BizTalk 2006 R2 SP1 WCF ExtensionsA few days ago a service pack for BizTalk 2006 R2 (known as BizTalk 2006 R2 SP1) was released and it includes a large number of rollup fixes accumulated from quite a few hotfixes. I ran it on my local development box and it installed fine for the most part. It did do have a hickup on HL7 though. It also includes some new product features which is a little unusual for a service pack release. Perhaps it should be called BizTalk 2006 R2.5. :)
Here is the link on the release announcement: http://blogs.msdn.com/biztalkcrt/archive/2009/10/09/announcing-biztalk-2006-r2-sp1.aspx
One of the major new product features in the service pack is better tooling around WCF extensions. This post is going to give an introduction on how this worked prior to the service pack, then go through a brief tutorial of how I tested the new functionality. This post is based on SP1 beta so it is subject to change.
Prior to SP1:
If you implemented a WCF extension prior to SP1 then you had to go through a considerable amount of complexity to get the extension to show up in the BizTalk WCF port configuration pages. I retraced Richard Hallgren's steps in his post http://www.richardhallgren.com/category/wcf/ as a good example of getting an WCF extension in the form of an EndpointBehavior. The relevant steps I want to focus on are:
The difficulty with this approach is that for every custom behavior (which might be used on a per port basis), you have to put stuff in machine.config. In most server environments this can require moving mountains to edit machine.config. Also, if you use behaviors on many ports it can quickly become difficult to manage. SP1 limits the scope of the config item to the executing host but it also introduces a couple challenges of its own.
With SP1:
The current SP1 approach is to configure config options using a tab on the adapter handler properties. The directions are given for the custom send handler here:
http://msdn.microsoft.com/en-us/library/ee519505(BTS.20).aspx. This comes from the overall documentation for the release: http://msdn.microsoft.com/en-us/library/ee532481(BTS.20).aspx
Basically what is involved is importing a config file that has the custom behavior defined. The SP1 beta documentation mentions this as a custom binding but it means the custom behavior. Here is a screenshot of what the page will look like after SP1 is installed:
 Then here is what the page looks like after you have imported a custom extension:
 This current documentation does not provide a template or starting point for what the imported config file should be so there is essentially a gap. What I did was try to use the machine.config from the Pre SP1 directions because I thought this is the most direct route that people are likely to do after they run SP1. A better approach would be to use the template I have at the bottom of this post as a starting point for the config file you import. Unfortunately the process is more complicated using machine.config because there are extra nodes in the machine.config that the import config button does not like.
You will get errors like:
---------------------------
Import WCF configuration --------------------------- Unable to import configuration from file "C:\Documents and Settings\benc\Desktop\machine.config".(System.Configuration.ConfigurationErrorsException) It is an
error to use a section registered as allowExeDefinition='MachineOnly' beyond machine.config.
(C:\Documents and Settings\benc\Local
Settings\Temp\Config\73d27aa8-b21b-4d47-abeb-c81ec7a756fc.config line 202)
So if you want to go this route, follow these steps to clean the machine.config to the point that the page imports the config file properly. These steps are subject to what is in your machine.config. Also, I am not sure if any of these steps will have any undesired consequences and you should use these steps at your own risk. But these worked for me:
Then try to import again and it should work. The screen will look exactly alike to the picture Richard Hallgren had for choosing the custom behavior, you just took a different path. The custom WCF extension behavior is the first in the list shown below:
 I am guessing that the import config button is trying to merge part of the imported configuration into some master configuration and this is why it is failing. If you try to import a config file that does not cause errors and does not have any extensions, you will not get a message back that nothing was imported, the text box just stays blank.
You will then be able to select the custom behavior for a port running under the handler where you imported the config file.
I have found that it is actually possible to import the same config file multiple times across multiple handlers so this means it is possible to have one WCF extension configured for multiple BizTalk hosts.
Once you get through the wizard you can then export the WCFExtensions config file which gives you a template for the future that I have included here (not sure why the ESB line exported here):
<?xml version="1.0" encoding="utf-8"?>
<configuration> <enterpriseLibrary.ConfigurationSource selectedSource="ESB File Configuration Source" /> <system.serviceModel> <behaviors> </behaviors> <extensions> <behaviorExtensions> <add name="addCustomWCFProperties" type="CustomWCFProperties.Behavior.PromoteUserNameBehaviorElement, AddCustomWCFPropertiesBehavior,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=705e34637fdffc54" />
</behaviorExtensions> </extensions> </system.serviceModel> </configuration> Here is a link to my exported .config file (shown above) that I used to successfully import Richard Hallgren's
custom endpoint behavior: http://cid-62e68922e47bc425.skydrive.live.com/self.aspx/Public/WcfExtensions.config
Hopefully the documentation will improve in the final version of BizTalk 2006 R2 SP1.
Thanks, April 28 More BizTalk 2009 Install Guide Info UpdatesI checked in the Windows Server 2008 English BizTalk 2009 pre-requisites redistributable and it DOES now include the ADOMD v10 install. Yahoo!
So after exploring the new information available on BizTalk 2009, I noticed that the whole SQL Server Notification Services documentation story has been updated dramatically. I had posted a few days ago about how the link from the 2009 Beta install guide for SSNS went to a version from SQL 2005 RC1 did not provide enough files and resulted in lots of errors. Now the documentation sends you to a Microsoft support site where you can download the missing SQL dependency files (SMO among them): http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=953752. This should be a huge improvement - this should enable BAM Alerts to work without needing to install a secondary SQL 2005 instance. The result of my configuration research shows there is more than one supportable configuration for using SSNS - either as a scaled down version or on a separate SQL 2005 instance.
For the last couple of months I have been playing with BizTalk 2006 R2 on Windows Server 2008 and SQL 2008 to get a better understanding of software compatability between these products. I had posted on the gap of information about what server roles and features would be necessary to use BizTalk in a Windows Server 2008 environment. Fortunately, the recently released BizTalk 2009 install guide for Windows Server 2008 does mention the required roles and features for Windows Server 2008 under the section describing what should be installed with IIS. The install guides have now been split up by OS, but there is unfortunately not one for installing onto Windows 7 - perhaps we will have to wait for this to be released later. :)
It looks like the updated documentation does not include any mention of the two separate BizTalk 2009 RFID install images - one bundled with the BizTalk server software, and one as a separate ISO. The separate ISO has a lot more samples on it so be sure to get the separate ISO too. Both are available on MSDN. April 27 BizTalk 2009 RTW (Release to World)I just found out that the BizTalk 2009 release has been extended to the general public: http://seroter.wordpress.com/2009/04/27/quick-thoughts-on-formal-biztalk-2009-launch-today/. I have been posting on various issues with the RTM version. It looks like the 2009 install guides can now be found at
http://go.microsoft.com/fwlink/?LinkID=128383 - the link was reset and it connects successfully. Additionally, the install guides now mention ADOMD v10 so please stop using the Beta install guide - it has now been replaced. I will be posting here soon about whether the updated prerequisites CAB includes ADOMD v10 and some other details I have been working on from the RTM version. Interestingly, the MSDN downloadable version is still from 4/6/09 (when the RTM release occurred) so it does not look like there has been an updated build; just updates of the supporting files. If I notice anything in the install guides or the other support files, I will be sure to post about it here. Thanks, April 16 BizTalk 2009 RFID - new WCF Endpoint BehaviorI was looking around in BizTalk 2009 RTM trying to find new features that have been mostly undocumented and found one today! It looks like there is a new endpoint behavior that comes with the BizTalk 2009 RFID installer for use with RFID events. The WCF-Custom adapter properties does not really give you the ability to edit the endpoint's array of events so I opened up a WCF Service Application to explore it more. The following blog post gives an example of how to build a WCF service that takes advantage of this new endpoint adapter: http://blogs.msdn.com/krishg/archive/2009/04/13/epcis-support-in-biztalk-rfid-2009-part-1.aspx. Here is a screenshot of the WCF Service Configuration Tool (it is right in the middle):
 I did a little reading on the blog post mentioned above to find out that this endpoint behavior basically is like an event pipeline or event bus for working with RFID in a standards-based way. Previously, you could work with BizTalk RFID using an event-sinks approach and then connect the dots and add decision logic using the Business Rules Engine. Custom events with EPCIS can be implemented and exposed on a WCF service and called on the basis of a event chain based on device events or programmatic .NET code. One of the examples in the BizTalk RFID help file shows using REST behaviors to interact with the service that exposes EPCIS events. This is really interesting because it provides a way to interact over WCF events with the BizTalk RFID infrastructure. Since .NET 3.5 WCF services can be exposed from a WF, this development makes it a very interesting development because RFID-workflows could be created. I am still learning about the BizTalk RFID capabilities, but thought this was worth blogging on.
There seem to be some interesting new areas to learn about with the advances in BizTalk RFID provided with the 2009 release.
Thanks, April 15 Getting BAM Alerts to Work on SQL 2008With the release of BizTalk 2009 RTM, I wanted to have a development VM to do all of the latest and greatest in BizTalk development. So I decided to build a VM with SQL 2008, BizTalk 2009, and all of the adapters I could pull together. I used the BizTalk 2009 beta install guide and installed SQL Server Notification Services (SSNS) 2005 RC1 which was the version linked to the beta install guide. When I tried to configure BAM Alerts (which depends on SSNS), I got an error, then another error and I realized there must be a gap in the 2009 beta install guide. Since a 2009 RTM install guide has not been released, I was stuck trying to figure out a way to get BAM Alerts to work. BAM Alerts configures fine on SQL 2005, but due to SQL 2008 not including SSNS, there is a cliff you can fall off trying to get BAM Alerts to work properly. This post describes the errors I received and the final workaround I came up with to get BAM Alerts to configure properly and work on a server with BizTalk 2009 and SQL 2008.
When I used the SSNS 2005 RC1 version, I started encountering errors that indicated there must be other dependencies that this install relied on. Here is the first error I was getting while configuring BAM:
 The main error here is "Could not load file or assembly 'Microsoft.SqlServer.Smo, Version=9.0.242.0' ...". So I tried copying all of these SQL 2005 assemblies to my VM and then dropped them in the GAC. Then I tried to configure the BAM Alerts again and got this message:
 The main error here is "This SQL version (10.0) is not supported.". So obviously at this point I was steaming mad - what is the problem here? I did some searching on the nscontrol.exe named in the error and found this http://download.microsoft.com/download/f/4/e/f4e80c76-3b69-4a42-a90b-79aeaca1177d/ReadmeSQL2005SP3NotificationServices.htm which mentions that there are 3 dependencies of SSNS and all must be loaded in order for SSNS to function properly. I tried download all three but still could not get BAM Alerts to configure properly. At this point I realized the next option to try would be to install a named SQL 2005 instance because SSNS really requires the 9.0 database version to work properly. This turned out to be what worked for me. I later found out that in order for BAM Alerts to configure properly, all of the BAM databases have to be on the same SQL instance so you need to have the SQL 2005 database services there anyway in order for BAM to all configure properly. Below I give the final install order if you want to use BAM Alerts with SQL 2008.
Final successful install order:
VM Base: Windows Server 2003 R2 SP2, SQL 2008, VS 2008 (minus SQL Express) installed in this order.
VM Diff:
April 09 BizTalk 2009 RTM Install Guide MissingFor anyone that is downloading the BizTalk 2009 RTM from the MSDN downloads, you may have found that the Installation Guide.htm on the image refers to http://go.microsoft.com/fwlink/?LinkId=128383, which is the location of the BizTalk 2006 R2 guides. This link should be updated soon. As far as I know, no new installation guide has been released yet so your best guide is the 2009 Beta install guide download from https://connect.microsoft.com/site/sitehome.aspx?SiteID=218.
Once I hear about a new version of the install guide I will post more about this. Good luck to everyone trying out BizTalk 2009 RTM.
Thanks, April 08 BizTalk 2009 RTMWell I guess I missed the launch party - BizTalk 2009 is now available for MSDN subscribers. I reported a lot of bugs during the BizTalk 2009 Beta and TAP releases so it will be interesting to see if people encounter any of these. Thanks to my friend Thiago Almeida for pointing out the ADOMD 10 error (http://connectedthoughts.wordpress.com/2009/04/06/biztalk-2009-rtm-prerequisites/). I had seen this during the TAP version and unfortunately it looks like a final bug.
The following screenshot shows what you will see if you install BizTalk 2009 in an environment with SQL 2005:
 This error is due to the installer needing the SQL 2008 version of ADOMD, v10. I have downloaded ADOMD v10 from SQL 2008 and run it on a SQL 2005 instance to get the BizTalk 2009 installer to work. Hopefully this will be resolved soon. There may be a couple of other issues out there too.
It is exciting to see the launch of the new product and it will be exciting to see people talking about this new version of BizTalk!
Thanks! March 27 BizTalk 2009 on Dev 10 Part 2I was able to play with BizTalk 2009 Beta on Dev 10 a little more and had some advice. When I installed earlier, I had not seen that the Developer Tools and SDK was grayed out and this was the reason the .btproj extension had not been installed properly. I eventually realized that on the VS 2010 CTP VPC, VS 2008 BIDS did not have VS 2008 SP1 so this was required to get the BizTalk 2009 Beta VS extensions to install at all.
With the VS extensions for BizTalk installed correctly, I was still not able to open BizTalk 2009 projects using VS 2010. For some reason the VS extensions are just not being applied to VS 2010.
Here is my updated install order to get BizTalk to work with as much as possible:
So I still wanted to answer a few questions. I was able to add a BizTalk 2009 project to TFS 2010 through VS 2008 w/ Team Explorer 2008 and view the source code in VS 2010, I was just not able to open the BizTalk projects. Here is a screenshot from VS 2010 with the BizTalk files in source control in TFS 2010:
So this is good because it means it is possible to upgrade to TFS 2010 without affecting BizTalk solutions. VS 2008 will just need to remain in order to keep editing BizTalk 2009 projects. The other question I had was whether a BizTalk 2009 project can reference a .NET 4.0 assembly. VS 2008 SP1 cannot create .NET 4.0 versioned projects, so the reference would have to be a GAC or file reference rather than a project reference. I created a .NET 4.0 assembly from VS 2010 and referenced some v4.0.11 assemblies and recompiled. Then I tried referencing the assembly in my BizTalk project in VS 2008. It looks like it is possible to reference a .NET 4 assembly from VS 2008 for a BizTalk project but I was unable to build it successfully. Here is the message I got when adding the reference:
After trying to compile I realized it was not possible to reference a .NET 4 assembly from Visual Studio 2008 SP1 (yet). I also tried referencing an M project using the latest Oslo January CTP SDK and was not able to successfully. So the good news is that you can migrate your TFS investment ahead of BizTalk and the BizTalk files will still check-in and import successfully. My next task will be to see how well the new ALM features of BizTalk 2009 translate over to working on TFS 2010. Thanks, BizTalk 2009 on Dev 10 (VS 2010)Today I was working on a project for a client and was unsure about compatibility between Visual Studio 2010 and BizTalk 2009. BizTalk 2009 is going to be released soon and it seemed like a natural question to wonder if the VS 2010 / .NET 4 CTP (http://www.microsoft.com/downloads/details.aspx?FamilyId=922B4655-93D0-4476-BDA4-94CF5F8D4814&displaylang=en) would work with this. This CTP has been out for around 5 months but I had not had a chance to try the BizTalk 2009 install on it. I used the 2009 Beta install and got some mixed results. Here is the high-level results:
Some obvious questions I am wondering about are given below. I will be researching and checking on these more:
Thanks, March 16 BizTalk Performance Guides vNextOne of the themes I have been blogging on for a while is the relationship of BizTalk Server 2006 R2 and Microsoft's 2008 product stack including Windows Server 2008, SQL 2008, and Visual Studio 2008. As everyone should know, the 2008 product stack is not supported with BizTalk Server 2006 R2. Over the past couple of weeks I have learned that some of the BizTalk Server Performance Optimization Guide articles (starting at http://msdn.microsoft.com/en-us/library/cc558617.aspx) should not be applied to Windows Server 2008 BizTalk implementations due to some performance differences between Windows Server 2003 R2 and Windows Server 2008. Even though it is a best practice to avoid unsupported environment configurations, I know for a fact there are quite a few organizations that have BizTalk 2006 R2 running with Windows Server 2008. I recommend against this configuration on production boxes due to the supportability issues, but it is very valuable from a BizTalk vNext perspective especially if you are working on a BizTalk 2009 migration plan.
So what is the result of following the performance guide in an unsupported configuration of BizTalk 2006 R2 and Windows Server 2008? Well, the guide was made with the assumption that Windows Server 2003 was being used, so the optimizations made specifically for that OS will not be the best ones for 2008. So watch out for OS tuning parameters or options in the guide because these will not always be the best ones for Windows Server 2008. Microsoft will be releasing an updated performance optimization guide a couple weeks after BizTalk 2009 is released under RTM. So if you are working in a high performance BizTalk environment and want to migrate to Windows Server 2008 then I would wait to deploy your applications until after the new optimization guide is released because the newer guide will include optimizations for Windows Server 2008.
But wait, what if you want to use BizTalk 2006 R2 in the unsupported configuration in production? Unfortunately, I have not heard the configuration will ever be supported, but I would still wait for the updated optimization guide so you can at least optimize the OS settings. If I uncover any other snafus or gotchas of using the updated performance guide in the unsupported configuration, I will be sure to let you know about them. :)
Thanks,
February 18 Simplify the Install Experience of the BizTalk SAP AdapterDuring a recent project I was using the BizTalk SAP Adapter to interact with a custom BAPI that was exposed as an RFC. In order to get the Add Adapter Service Wizard in BizTalk to work properly, I had to install all of the SAP dependency libraries on the BizTalk server. I was amazed at how complicated this whole process was. There are a couple things I would like to do in this blog post:
I wonder if the reason Microsoft is not able to provide a redistributable of these SAP components is due to SAP licensing restrictions. In any case, these directions will help you simplify the complexity of the SAP adapter dependencies' install and dramatically improve the install experience after you get all of the files downloaded.
Thanks,
February 08 Operations Management for BizTalk published in BizTalk HotrodI just found out the latest BizTalk HotRod to hit the web (February 2009) does include an article I did on Systems Center Operations Manager (SCOM) and BizTalk. Go here to get a copy of the article: http://biztalkhotrod.com/Documents/BizTalk%20HotRod%20Magazine%20Q1%202009.pdf. This is my first published article so it is exciting for me. This is partially based on my Operations Management for BizTalk presentation from about a year ago.
Thanks, December 29 WCF-SQL Adapter Modernizes BizTalk SQL Adapter CapabilitiesIn my spare time I have been playing and testing all of the latest released capabilities of BizTalk Server 2009. During some of my time I have been working with the new WCF-SQL adapter that exposes a new WCF binding, SqlBinding, as part of the latest Adapter Pack. If you have ever worked with the BizTalk SQL adapter you know that the wizard in Visual Studio frequently caused problems and unfortunately these shortcomings were never adequately addressed in a service pack or updated release. Usually it was required that you just take a working example of the SQL adapter and then manually modify it to work with your database objects. More often than not you probably just avoided the SQL adapter completely and worked with the database through ADO.NET calls in an orchestration or custom pipeline. Now with the updated Adapter pack the WCF-SQL adapter finally modernizes the SQL adapter experience and gives you a stabile and very functional environment for interacting with SQL via an adapter. This article will highlight some of its capabilities and provide a walkthrough of the new WCF-SQL adapter wizard. All of my testing has been with the BizTalk 2009 Beta loaded on a Windows Server 2003 box with Visual Studio 2008 (including SP1) installed. I installed the BizTalk Adapter Pack found at https://connect.microsoft.com/content/content.aspx?ContentID=10580&SiteID=218. To add a schema based on the WCF-SQL adapter, open or create a BizTalk project in Visual Studio 2008 and right-click on the project. Clcik on the Add New Item > Add Generated Items as shown below:
Then after the window loads you should see the following window:
Click on "Add Adapter Metadata" and then click "Add". This will open up a general window that is used for several different adapters. After installing the BizTalk Adapter Pack V2, you should see an item listed in the listview called WCF-SQL. You should also see the older SQL item listed as well as any other Adapter Pack or Line-of-Business (LOB) adapters. You will need to enter a SQL server name and database in the combo boxes below the listview. I entered my local SQL Server instance and my BizTalkMgmtDb as seen in the screenshot below:
You do not need to enter a port for this adapter so just leave this one blank and click Next. The following screen shows the form that is loaded next to help you determine which SQL objects to include in the WCF-SQL schema. If you worked with the previously mentioned rudimentary SQL adapter in BizTalk, at this point you would be presented with the option of entering a command text or a single SQL object name for the wizard to use to generate the schema. But the WCF-SQL adapter wizard provides database object browsing and filtering to further simplify the task of schema generation. The following screenshot shows the form when it is initially loaded:
If you merely want to use the database you specified earlier in the wizard, click the configure button and then click OK to generate the default URI of mssql://.//?. Then click Connect to connect to the database specified. This will enable the bottom half of the screen where you can expand the categories of database objects and then find one or more objects to select. It is also possible to select a different database and/or configure additional database connectivity properties via the Configure button's window. Below is an image of the Configure button's window with the SSO database details specified:
I have found that it is not possible to specify "(local)" for the SQL instance name as shown above so do not try this. Below is the form changed to allow selecting from several of the SSO databases's tables:
The "Search in Category" box in the middle of the form provides a way to filter the list of database objects. I have found that it is possible to use wildcards in this box by the percent character "%" but not by the asterisk - "*". Once you have selected objects to generate a schema for, click OK. Visual Studio will generate a schema and a related code class as well. The designer experience provided by the WCF-SQL adapter wizard is a huge step forward for the creation of BizTalk SQL schemas. December 11 BizTalk Dream MachineI have been playing with the new features of BizTalk 2009 and have been finding a few bugs. But some of what is available with this release is awesome. For example, due to Visual Studio 2008 integration you can reference a WCF Service library from your BizTalk project. You can also reference a project that uses LINQ so will be able to use LINQ indirectly in a BizTalk map. Another cool thing is that you can reference a WF library from your BizTalk project. This makes it possible to call a WF method directly from BizTalk and potentially move logic over to a WF process from BizTalk. I have not tried running a workflow from the BizTalk host but that will be the next thing to try. I have not seen any new BizTalk orchestration shapes for calling WF activities or workflows either.
The new UDDI functionality included with the BizTalk 2009 beta is a little buggy at this point but the functionality seems to be a big step forward. More details on this soon.
Lots of the wish list ideas I have had for where BizTalk could be going are things I am testing right now. Check back here as I find new features as part of the beta.
Thanks, December 08 BizTalk Server 2009 Public Beta Released TodayToday Microsoft released the public beta of the next version of BizTalk, BizTalk Server 2009 and it is available for download at the Microsoft Connect site - http://connect.microsoft.com/site/sitehome.aspx?SITEID=218. The latest version of the Microsoft ESB Guidance was also released at the same time and is available at the same CodePlex location - www.codeplex.com/esb. There are quite a few updated BizTalk features with this release and I will be showcasing some of these features in the next couple days.
There were a couple of installation gotchas that I noticed initially with BizTalk 2009. I worked with BizTalk 2009 during the Microsoft TAP program a few weeks ago and have already installed it once. The 2009 TAP install did not require you to run Visual Studio 2008 SP1 but the new BizTalk release does require this so be sure to do this before running the installer. The 2009 install will add the Visual Studio extensions to Visual Studio 2008 so that you can now include your .NET 3.5 projects right alongside BizTalk projects.
The developer tools will not be enabled as an install option without Visual Studio 2008 SP1. Since BizTalk 2009 is in beta you will want to report any issues to Microsoft as part of the feedback link on the BizTalk 2009 connect site or report it at the MSDN forums under BizTalk - http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1470&SiteID=1.
The ESB Guidance no longer includes JMS features so you if you have been using JMS subscriptions with the ESB Guidance, do not upgrade at this time if you want to continue using JMS.
Thanks, November 20 Major BizTalk Incomatibility - IIS 7 and WCF Publishing WizardOn my current project the client has been dabbling with BizTalk 2006 R2 in a very unsupported configuration with Windows Server 2008, and SQL 2008. In previous posts I talked about Windows Server 2008 and some challenges installing BizTalk on this OS. Generally, Windows Server 2008 behaves well for BizTalk. SQL 2008 has behaved well and has not presented any problems for BizTalk other than the fact that it does not include Notification Services so you must install this optional component from the installer included with SQL 2005. This post describes some new difficulties I have identified when using BizTalk Server 2006 R2 with IIS 7.
Working in the unsupported environment has been very interesting because it has identified that there are issues with BizTalk's WCF integration on Windows Server 2008. Windows Server 2008 includes IIS 7 which has been overhauled extensively. Several issues have been identified with IIS 7 and BizTalk Server 2006 R2:
- It is possible to run the BizTalk WCF Publishing Wizard through completely to create a .svc WCF endpoint and a virtual directory to host the WCF service but by default IIS 7 is not configured to support the .svc extension. In order to setup the .svc extension, use the IIS 7 directions at http://msdn.microsoft.com/en-us/library/ms752252.aspx.
- When running the BizTalk WCF Publishing Wizard sometimes IIS 7 will get dumped out completely. From time to time running the wizard the web.config at c:\Inetpub\wwwroot and all of the virtual directories in this folder get removed during the time that the WCF Publishing wizard is running. For this reason, I strongly recommend you backup the web.config in the web root and all virtual directories stored under the web root before running the WCF Publishing wizard on a box that includes IIS 7. If you just registered the .svc handler and IIS 7 gets dumped out you will need to create it again. Due to this issue, I also strongly recommend that if you need to work with HTTP or IIS related adapters, use Windows Server 2003 R2 with IIS 6 rather than Windows Server 2008 with IIS 7.
- The BizTalk WCF Publishing Wizard may require additional permissions when run on Windows Server 2008 than on Windows Server 2003 due to the secure by default nature of IIS 7. I identified issues with the NetMSMQ binding and MEX-only endpoints created with the BizTalk WCF Publishing Wizard in which permissions must be loosened while the wizard is running although they may be tightened afterwards.
Thanks,
|
|
|
