Yes, it’s been a while. A long while…
I was recently required to import a simple XML file into a set of records in an Oracle table. This sort of integration is pretty simple using BizTalk Orchestrations, but we’re trying to move to an ESB-centric model.
I struggled finding an easy-to-follow guide, so am going to document my findings to help myself, and hopefully others, next time I need to complete a similar task.
The major sticking point was in the creation of the ESB Resolver string for the Routing Messaging Extender (Microsoft.Practices.ESB.Services.Routing).
Note: These settings are just a valid for use in an Orchestration Extender as well as the Messaging one.
The settings for your Routing Resolver are pretty simple to work out, but you need to remember to include the Action from your generated WCF binding file.
The trickier part was the value of the Endpoint Configuration setting:
As highlighted in the above image, ensure the Binding Type is “oracleDBBinding” (case-sensitive), and set your username and passwords as appropriate. The password will be stored in clear-text in the Itinerary, but hopefully you’re using an x.509 certificate to encrypt the contents.
Next up is the BindingConfiguration setting within the Endpoint Configuration setting. This should be considered akin to a mini Xml Document that gets passed to the Adapter at runtime, with a couple of simple, but important, settings:
As can be seen, these settings can be derived from the settings used in the Static WCF-Custom configuration dialog for a binding of the same type. The important thing is the use of < and /> as start and end delimiters.
Save your settings, complete your Itinerary, and you should be interacting with your Oracle database without any need for Orchestrations or inflexible Static Send Ports.
BizTalk comes with a couple of tools for automating and simplifying the publication of Web-Service and WCF based services.
The problem with both these tools is that once the service has been published, there’s no easy way to make changes to the service definition without re-configuring all the properties of the Service, a time-consuming and manual procedure.
Fortunately, there is a way to initialise the wizards with the contents of a previously saved set of Service configuration file. These configuration files are conveniently created by the Wizard just before you publish the definition, and are saved into a “temp” directory under your Web/Wcf Service application root directory.
For the Web Services Publishing Wizard, the command line syntax is:
For the WCF Services Publishing Wizard, the syntax is:
Both of these tools can be found in the BizTalk installation directory, such as “C:\Program File(x86)\Microsoft BizTalk Server 2010\”
I have run into an instance where I need to terminate and raise an exception from within an XSLT template, based on values (or lack thereof) within the source document. The XSLT transform is running within a BizTalk map.
The secret is the following little-known XSLT construct, which can be conditionally called at any point in the transform:
<xsl:message terminate="yes">Custom error text</xsl:message>
This will cause the XSLT engine to stop processing immediately, and raise an exception. This exception, including the custom error text contained within the message segment, can be caught in the BizTalk Orchestration engine by explicitly catching an exception of type Microsoft.XLANGS.BaseTypes.TransformationFailureException.
I had developed a simple Rule Policy in the Business Rule Composer, and was attempting to include it in an Orchestration using the Call Rules shape. The Policy was correctly Published and Deployed, and was available in the ‘Select the business policy’ drop-down, however, I was unable to specify any parameters to pass to the Policy. The parameters section simply did not provide any facility for mapping a local message instance to a policy parameter.
A little research revealed this post, detailing the solution.
It is important that there is no ambiguity with the schemas for messages being passed to the BRE. To this end, the BRE requires you set the Document Type name of any Schema Facts to the Fully Qualified Name (FQN) of the schema. The Fully Qualified Name can be found in the Properties of the .xsd file in Visual Studio.
Once the Document Type has been changed to use a FQN, and any Rules and/or Vocabularies appropriately updated, the Policy can be re-published, and parameters will be accessible within the Call Rules shape.
While installing BizTalk 2010 in a multi-server configuration (one server for BizTalk, a different server for SQL), I received the following error while attempting to configure the BAM Archive database:
Microsoft SQL Server Data Transformation Services (DTS) 2008 with SP1 or higher for BAM Archiving is not installed on the local machine. Please install Microsoft SQL Server 2008 Integration Services. Could not load file or assembly
Could not load file or assembly ‘Microsoft.SqlServer.ManagedDts, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies…
The wording of the suggested solution takes a too literal approach. Whilst installing Integration Services would solve the problem, only the actual DLL library ‘Microsoft.SqlServer.ManagedDTS‘ needs to be installed.
This can be done by performing an install from the Sql Server installation media, but choosing to install only the following:
- – Management Tools – Basic
- – Management Tools – Complete
It should now be possible to complete the configuration successfully.
Great, if long, post on integration between BizTalk and SAP.
With SAP being one of the better known, and widely adopted ERP systems, there are a lot of opportunities for integration experts who can “bridge the gap” between SAP and Microsoft technologies.
I am currently working with a customer that use Sybase (remember them?) Adaptive Server Enterprise, as their primary database environment. Sybase and Microsoft originally co-developed the early versions of SQL Server, so there are still enough similarities that it “feels” like working with MS-SQL, albeit an older version.
However, the BizTalk Adapters are not so forgiving, and will not work with ASE. Our solution was to use the open-source ODBC Adapter provided by TWOCONNECT (link). This was when we ran into trouble.
Opening the ODBC Data Source Administrator to add a new System DSN left me with only 2 available options in the Driver’s tab:
Digging into things a little, I determined that the Sybase drivers are 32-bit only, but my development machine is running 64-bit Windows. In order to be able to configure 32-bit ODBC drivers, you need to run the 32-bit version of ODBC Data Source Administrator. This can be done by entering “C:\Windows\SysWOW64\odbcad32.exe” from the Run prompt:
Now the full range of “legacy” 32-bit ODBC drivers and data sources are available:
One final issue to consider. If you have configured and wish to use a 32-bit DSN, you will need to run any associated Send and Receive Ports within the context of a 32-bit Host Instance.
I recently ran into an intermittent problem where we were receiving the following exception:
System.InvalidOperationException: There were not enough free threads in the ThreadPool to complete the operation.
in conjunction with a stack trace indicating we were well and truly down in the WCF ServiceModel code base. This resulted in numerous suspended messages, and a messy Event Log.
A little investigation showed that it occurred due to a bulk update of the source system, which propagated a whole bunch of messages (around 1000 in a 5 minute period), via WCF, to a web service on the destination system. This resulted in a flood of messages from BizTalk to the WCF Send Adapter, which happily allocates each message to be sent to the back of it’s own processing queue. Each pending message gets allocated a work item thread.
The destination system only exposed a ASMX-style web service, so we were restricted to using basicHttpBinding. Windows, and by inference, BizTalk, limits the default number of outbound HTTP connections to 2. So were were pumping a whole lot of messages to WCF, as quickly as BizTalk could, but WCF could only dispose of, at maximum, 2 at a time. Within a short amount of time, the process thread pool is exhausted, and errors resultant.
My solution was two-fold:
Increase the ‘maxconnections’ property for outbound Http connections.
This can either be applied at the machine level, or at the app config level. I chose to avoid unwanted side effects by only modifying the BTSNTSvc64.exe.config, adding the following snippet within the <configuration></configuration> root:
<system.net> <connectionManagement> <add address="http://name.of.server.here" maxconnection="12" /> </connectionManagement> </system.net>
Again, I took the conservative option, and only altered the maxconnection property for those intended for that specific server. I dislike side-effects…
Increase the maximum number of threads allocated to the Host Instance
Fortunately, the BizTalk architecture was set up in such a way that this specific application had it’s own set of Host Instances. This allowed me to increase the number of Maximum Engine Threads, without too much risk of starving other applications and processes on the server.
This is done within the Host Settings Dashboard, accessed by right-clicking on the BizTalk Group and selecting ‘Settings…” (sorry, BizTalk 2010+ only, folks). You get a screen similar to the one below:
So, I doubled the number of threads, which in conjunction with the increased throughput, above, should ensure we don’t run into this issue again.
Simply a minor facepalm moment I want to document to help both myself and others avoid unnecessarily wasting an hour. Like I just did…
You’re attempting to perform a ‘Validate Instance’ of a document against the .xsd schema definition, and receiving the following error:
C:\path\to\sample\data.xml: warning BEC2004: Root element is missing.
Step 1: Make sure to close Excel/TextEdit/whatever external program is preventing Visual Studio from obtaining an exclusive lock on the sample file.
Step 2: Step away from the keyboard, grab a cup of tea and some air. You need it…
Further to a question I recently answered on StackOverflow, I wanted to expand a little on when it is necessary to restart a BizTalk Host Instance, and when this is overkill.
Host Instance restart required
Any change to an underlying datatype, map or orchestration will require a restart of the corresponding Host Instance. This is due to the way the .Net runtime manages type-loading of assemblies.
All BizTalk schemas, maps and orchestrations are compiled to .Net code inside an Assembly. The .Net runtime supports dynamic loading and type-discovery of Assemblies, but does not support removal or un-loading. This means that any time you change any code-based .Net artefact, a Host Instance restart is required before the change will be seen.
Runtime Configuration change
The counter to this is Configuration based runtime artefacts, including the configuration and binding of BizTalk Adapters. For example, it is possible to change the path and file-mask properties of a File based Receive Adapter, or even change from using a File Receive Adapter to a SQL Receive Adapter within the same Receive Port, with the chage reflected immediately, and with zero down-time.