Integration Hashtags
With the recent name change from Windows Azure to Microsoft Azure, the old WABS (Windows Azure BizTalk Services) hashtag has become obsolete. It was a risky hashtag to view at times anyway, given some of the dodgy meanings for “WABS” particularly in my neck of the woods – but that’s another story!
So far I haven’t seen a consistent replacement for the WABS hashtag being used, which got me thinking about the other hashtags we use in the integration space.
It would be really nice to have a definitive list of those hashtags to keep things relatively consistent when tweeting about integration technologies.
I’ve kicked this off below and created a poll for the ones there is some uncertainty around.
Please send me any alternatives or any I’ve missed and I’ll them to the list. In a weeks’ time after the polls close I’ll re-publish the list here.
- #MSBTS – BizTalk Server
- #Integration – Generic Integration
- #Azure – Microsoft Azure
- #ServiceBus – Microsoft Azure Service Bus
- #Cloud – Generic Cloud
- #WCF – Windows Communication Foundation
- #AppFabric – Microsoft AppFabric for Windows Server
- #SSIS – SQL Server Integration Services
Update:
Here is an updated list of suggested integration hashtags to use:
- #MSBTS – BizTalk Server
- #MABS – Microsoft Azure BizTalk Services
- #ESBT – BizTalk ESB Toolkit
- #Integration – Generic Integration
- #Azure – Microsoft Azure
- #ServiceBus – Microsoft Azure Service Bus
- #Cloud – Generic Cloud
- #WCF – Windows Communication Foundation
- #AppFabric – Microsoft AppFabric for Windows Server
- #SSIS – SQL Server Integration Services
BizTalk Adapter Service Installation
In an article I recently published on TechNet Wiki I covered the installation steps required for the BizTalk Adapter Service (February 2014 Update).
The BizTalk Adapter Service facilitates communication between a cloud application and an on-premise Line-of-Business (LOB) system. The following on-premise LOB systems are supported:
- Microsoft SQL Server
- Oracle Database
- Oracle E-Business Suite
- SAP
- Siebel eBusiness Applications
With the Windows Azure BizTalk Services February 2014 Update there is no longer a SQL Server installation requirement for the BizTalk Adapter Service. The BizTalk Adapter configuration data has been moved from an on-premise SQL Server database to a Windows Azure SQL database.
Sysprep BizTalk Server
The System Preparation (Sysprep) tool prepares an installation of Windows for duplication, also called imaging, and enables you to capture a customized Windows image, or “golden image”, that can be reused throughout an organization.
This can be particularly beneficial when provisioning machines for a team of BizTalk developers. Installing and configuring BizTalk Server machines from scratch increases the lead time on a project. The other main advantage is the guarantee that each developer is working off a consistent configuration reducing the chances of “it works on my machine” incidents.
However, Sysprepping a BizTalk Server image is not as straightforward as Sysprepping a base Operating System image; mainly due to BizTalk Servers reliance on SQL Server.
BizTalk Server ships with some sample Sysprep scripts, but as with most samples these just serve as a foundation and require some customizations and additions. The documentation that accompanies the sample scripts is misleading in places and contains some gaps that can cause confusion.
I recently wrote an article on the TechNet Wiki that covers the steps required to Sysprep a fully configured BizTalk Server virtual machine.
The article was subsequently awarded a silver medal in the TechNet Guru Contest for January 2014.
Tracing with ESB Toolkit 2.2
Thanks to Tomasso Groenendijk for figuring this one out and sharing.
As with previous versions of the ESB Toolkit there is a minor change required to get tracing working. The switch name no longer has the version number appended to it. So instead of “BizTalkESBToolkit20” or “BizTalkESBToolkit21” as in previous versions, it is now “BizTalkESBToolkit”.
This should remain constant going forward removing the need to guess what the switch name is on each release!
Similar to ESB Toolkit 2.1, the full list of steps are:
- In Notepad openC:\Windows\Microsoft.NET\Framework\v4.0.30319\CONFIG\machine.config for 32-bit
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\CONFIG\machine.config for 64-bit - Locate the line with the closing configSections tag.
- Under that line paste the following section:
<system.diagnostics> <switches> <add name="BizTalkESBToolkit" value="4"/> </switches> </system.diagnostics> - Save and close machine.config.
- Start the DebugView program (Download)
- In DebugView, on the Capture menu, click Capture Global Win32 to make sure that it is checked.
- In the BizTalk Server Administration console, restart the BizTalkServerApplication host instance.
ESB Toolkit 2.2 Itinerary Designer Installation
Brian Loesgen has a post on his blog describing an issue he ran into performing a clean build of BizTalk Server 2013 and ESB Toolkit 2.2, where the Itinerary Designer extension is not registered in Visual Studio 2012 after the ESB Toolkit 2.2 installation step.
I experienced this also so it may be more widespread than first thought. I’d be interested to hear how many other people run into it; it might be the case that this step will need to be added to installation instructions.
Before Brian pointed me to his post I had resolved this inadvertently when I installed the latest Visual Studio 2012 update, which would have resulted in a similar command being executed with the same outcome.
ESB Toolkit 2.1 Installation Checklists
Overview
One of the biggest barriers to ESB Toolkit adoption I have come across is the installation and configuration overhead. This is a genuine concern, especially when you need to deviate from the standard configuration. If project timelines are tight, this can result in the ESB Toolkit being overlooked.
Through working on a number of ESB Toolkit based solutions for different customers I have compiled some high level installation checklists that cover the most common environment configurations. I will cover each of these in this blog series with a view to removing the initial barrier to building solutions based on the ESB Toolkit.
The Installing BizTalk 2010 ESB Toolkit 2.1 guide and Installing the BizTalk ESB Toolkit MSDN library topic should be used as a reference for drilling down into the detail of the steps included in the checklists.
If there is anything you have come across that you feel should be included in the checklist please get in touch and we can look at adding it.
Checklists
ESB Toolkit 2.1 Core Standalone Installation
Environment
The environment configuration covered under this checklist is as follows:
- 1 x 64-bit Windows Server 2008 R2 Enterprise Edition
- BizTalk Server 2010 Developer Edition
- SQL Server 2008 R2 Developer Edition
- ESB Toolkit 2.1
- All programs are installed on a drive isolated from the OS, an E drive in this case
Checklist
- Install the BizTalk ESB Toolkit 2.1-x64.msi
- Install the Microsoft.Practices.Services.Itinerary.DslPackage
- Import and install the Microsoft.Practices.ESB.CORE64.msi
- Create a 32-bit Host, Host Instance and assign the SQL send and receive handlers to it
- Configure the All.Exceptions send port in the Microsoft.Practices.ESB application to use the 32-bit SQL send handler
- Launch the ESB Configuration Tool and configure the toolkit
- Copy the following ESB Toolkit pipeline components from the “C:\Program Files (x86)\Microsoft BizTalk Server 2010\Pipeline Components” folder to the “E:\Program Files (x86)\Microsoft BizTalk Server 2010\Pipeline Components” folder:
- Microsoft.Practices.ESB.ExceptionHandling.PipelineComponents.dll
- Microsoft.Practices.ESB.Itinerary.PipelineComponents.dll
- Microsoft.Practices.ESB.Namespace.PipelineComponents.dll
- Microsoft.Practices.ESB.PipelineComponents.dll
- Copy the ItineraryDescription.xsd from the “E:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Web\ESB.ItineraryServices.Response.WCF\App_Data” folder to the “E:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Web\ESB.ItineraryServices.Generic.Response.WCF\App_Data” folder
- Add the SQL Server Service Analysis account as a User to the BAMStarSchema database and grant it the db_datareader role
- Deploy the BAM activities
- Configure Tracing
- Restart host instances and perform an IISRESET
- Verify all services are browse-able
ESB Toolkit 2.2 Beta (Windows Azure VM): Configuration
Overview
The following is a “brain-dump” of my experiences configuring ESB Toolkit 2.2 on a Windows Azure VM using the BizTalk Server 2013 beta (February 15th 2013 revision) on Windows Server 2012.
What’s New
There have been some enhancements made to the ESB Configuration Tool.
Default Configuration
The ability to apply a default configuration, similar to that provided with the BizTalk Server Configuration Tool, has been added. Clicking on the root tree node, ESB Configuration, produced an empty screen in previous versions of the ESB Toolkit but with ESB Toolkit 2.2 the following screen containing default configuration properties appears.
Using this screen we can set default values for the Database Server, IIS Web Services and the BizTalk User Groups and have those applied across to the Exception Management and ESB Core Components.
This simplifies the configuration for typical installations. For greater control of the configuration the Exception Management and ESB Core Components can be customised using the approach provided with previous versions of the ESB Toolkit.
ESB BizTalk Applications
This is a new node that has been added to the configuration tool. It consists of two options; Enable ESB Core Components in BizTalk Server and Enable ESB JMS/WMQ Components in BizTalk Server.
These replace the post configuration steps that were required with previous versions of the ESB Toolkit which involved manually running MSI’s to create the BizTalk Server Applications.
Moving these steps of the configuration process to the configuration tool is an obvious progression and you’d have to wonder why they were ever left as a manual step when the configuration tool was first introduced with ESB Toolkit 2.0.
Steps
As mentioned above a custom configuration is similar to the steps followed in previous versions of the ESB Toolkit, so we’ll cover a default configuration here.
1. Launch the ESB Configuration Tool.
2. Click on the ESB Configuration node and enter the Database Server, User Account and Password. The Website Name can be selected here – I’ve left it as the Default Web Site. I’ve also left the default BizTalk User Groups as this is an isolated configuration.
3. Click on the ESB BizTalk Applications node.
4. I am just going to install the ESB Core Application so select the Enable ESB Core Components in BizTalk Server checkbox and leave the Use Default Binding option selected.
5. Click Apply Configuration
Issues
The steps above should result in a fully configured ESB Toolkit. Some of the issues I encountered in reaching this point have been listed below.
IIS Install Registry Key is missing. Check that you have IIS 6.0 Extensions installed.
The ESB Toolkit is still reliant on IIS 6.0 extensions which are not installed by default on the Windows Azure BizTalk Server 2013 Beta image. To resolve this issue you must install the IIS 6 Management Console feature.
Note: The IIS 8 Management Console feature is not installed by default either on the Azure image but that is not a pre-requisite for the ESB Toolkit.
Cannot open database BizTalkMgmtDb on server XXXXX. Verify that you have the required security permissions and that communication between…(the error message cuts off here).
So far I have been unable to reproduce this error.
Application: Microsoft.Practices.ESB already exists
In an attempt to resolve the error in 2 above I decided to test out the resilience of the ESB Configuration Tool when things go wrong. I re-applied the configuration again and this time received the error above informing me that the Microsoft.Practices.ESB application already exists. Clearly the ESB Toolkit Configuration Tool still doesn’t support rollbacks or idempotency.
DeployPolicyAsResource failed (full error message is not visible)
After my attempt to re-apply the configuration in 3 above was unsuccessful I carried out the following steps to allow me to retry the configuration.
1. Click Unconfigure Feature
2. Select EsbBizTalkApplications and click Accept
3. The ESB BizTalk Applications features are now unconfigured
The reason for just unconfiguring the ESB BizTalk Applications is because I was able to identify this step as the one where the original error occurred. I could see that each of the other steps had completed successfully by viewing their state. This is done by clicking on their nodes in the ESB Toolkit Configuration Tool; a greyed out screen indicates a configured component.
After unconfiguring the ESB BizTalk Applications I selected Enable ESB Core Components in BizTalk Server again and applied the configuration which produced the “DeployPolicyAsResource failed” error.
As can be seen in the screen shot above the full error message is not visible. However, hovering over the ESB BizTalk Applications node (or any node that resulted in an error) will briefly show a tool tip containing the full error message. Depending on the size of the error message this can take a number of attempts to view the full error, as was the case here.
I was able to see that the error was being caused by the existence of the ESB.Deployment.Policy policy in the BRE which couldn’t be overwritten as it was in the “Deployed” state.
This was confusing as I had assumed that unconfiguring the ESB BizTalk Applications would have resulted in the Microsoft.ESB.Practices artefacts, including the ESB.Deployment.Policy policy, being removed.
I unconfigured the feature again and performed a visual check and confirmed everything had been removed even going as far as checking the database tables. However, no matter what I tried the same error appeared.
As a last resort I decided to unconfigure the ESB BizTalk Applications, close the ESB Toolkit Configuration Tool, launch the ESB Toolkit Configuration Tool and configure the ESB BizTalk Applications.
Result! It appears that caching in the ESB Toolkit Configuration Tool was the cause.
Summary
The enhancements that have been made to the ESB Toolkit Configuration Tool fully automates the configuration process and will hopefully remove the initial barrier to adoption I have spoken about on previous posts. There is still room for improvement though, particularly when things go wrong. Not being able to view the full error message is frustrating. Hopefully with it being a cosmetic fix this will be resolved in the final release.
Be sure to install the IIS 6 Management Console feature prior to configuring the toolkit and in the event of an error during configuration:
- Unconfigure the offending component
- Close the ESB Configuration Tool
- Launch the ESB Configuration Tool
- Re-configure the component
ESB Toolkit Configuration Error
While closing out some tasks before the Christmas holidays I ran into this “head scratcher” during the Enable Exception Management Database step of the ESB Toolkit configuration.
Error
Fix
The server I was configuring the ESB Toolkit 2.1 on was the final one in a series of servers for this customer. I had previously configured two test servers without any issues so I was surprised to see this exception; one I had not come across before on any ESB Toolkit configuration.
As I had not configured the BizTalk Server 2010 environment personally and no benchmarking had been carried out yet I checked the list of SQL Server Logins to verify that the BizTalk Server Administrators group had indeed been added during the BizTalk Server configuration.
It had so there appeared to be no issues with the BizTalk Server configuration. However, what I did notice was that the group had been added with a lowercase domain name. So, instead of it being ‘XXXX\BizTalk Server Administrators Prod’ as it was in the ESB Toolkit configuration wizard it was ‘xxxx\BizTalk Server Administrators Prod’ in the SQL Server Logins.
I wouldn’t normally consider case sensitivity to be the offender when configuring a tool from Microsoft but having come across a few quirks with the ESB Toolkit before I decided to modify the case of the SQL Server Login to rule it out.
First of all I needed to unconfigure the Exception Management Database in the wizard and manually delete the EsbExceptionDb database from SQL Server.
Next I modified the case of the domain portion of the BizTalk Server Administrators group in the SQL Server Logins. Changing it in the ESB Toolkit configuration wizard was not an option as it is retrieved from Active Directory.
Once that was complete I tried the Enable Exception Management Database step again and to my surprise it configured successfully.
Conclusion
The domain name of the groups and users in the ESB Toolkit 2.1 configuration wizard is case sensitive. I would imagine this to be the case for 2.0 also and I will need to try the latest version that ships with BizTalk Server 2013 to verify whether that is also.
I haven’t tried changing the case of the group name or user name portions to see whether they are case sensitive also but I would be pretty confident they are.
BizTalk Server 2010 Map Deployment Bug
This is more of a “note to self” but I feel it is worth sharing with the community.
Microsoft recommends that hot fixes should only be applied if you are experiencing the issues they address. There are good reasons for this, mainly around the amount of testing a hot fix goes through in comparison to a service pack.
I am going to go against that advice for BizTalk Server 2010 installations and add “Cumulative Update Package 1” to my installation checklist. This is to avoid a bug that has been present in every BizTalk Server 2010 environment I have installed and configured; from development machines to production servers.
Background
I first came up against this bug through being trigger happy with the Deploy menu item on a transforms project. I mistakenly deployed the transforms project before deploying one of the schema projects it referenced. Whilst previous versions of BizTalk Server would have prevented the transforms project from being deployed, BizTalk Server 2010 allows it.
The Bug
The bug manifests itself in the BizTalk Server Administration Console. When trying to expand the Applications folder you will receive the following error:
Schema referenced by Map ’map_name’ has been deleted. The local, cached version of the BizTalk Server group configuration is out of date. You must refresh the BizTalk Server group configuration before making further changes.
Refreshing the BizTalk Server group does not resolve the issue and the error continues to appear. This prevents access to every application in the group.
For further information on the bug have a read through Knowledge Base article 2516201
This has been covered under VSTS Bug number 678144 and is fixed in Cumulative Update Package 1 For BizTalk Server 2010.
The Fix
Applying the CU will only prevent the issue from occurring again by generating an error in Visual Studio. In the case of an MSI deployment, the error will appear during the import. However, it will not resolve the problem in the BizTalk Server Administration Console.
To remove the error you must delete the offending map in the transforms project from the bt_mapSpec table in the BizTalkMgmtDb database.
-- Locate the itemId of the map Select * from bt_mapspec -- Using the itemId retrieved above delete the map Delete from bt_mapspec Where itemid = 'itemId_of_map'
On refreshing the BizTalk Server group the error will disappear and the applications can be accessed again.
Deleting entries from the BizTalk Server tables is not something I am overly comfortable with, but unfortunately it was the only resolution I could find to get rid of this particular error.
Colin Meade's Blog 