Tag Archive for 'BizTalk'

Fast, Efficient Message Archiving for BizTalk with the BizTalk Message Archiving Pipeline Component. Download a Free 14-Day Trial!

Gotcha when Exporting Adapter Config in Binding Files

Published
by
Nick Heppleston
on Tuesday, 17th February 2009
in BizTalk 2004, BizTalk 2006 and BizTalk 2009
. 1 Comment

Originally posted by Nick Heppleston at: http://www.modhul.com/2009/02/17/gotcha-when-exporting-adapter-config-in-binding-files/

This one caught me out today – hope it might help others in the future…

If you export Bindings to get the lovely syntax for the ReceiveLocationTransportTypeData element, make sure that all of the properties in the adapter configuration dialog that you are interested in are populated *before* you do the export. Otherwise, it would appear not all properties come out in the Binding File Xml.

In the example below, I have mistakenly not set the username and password properties for the FTP adapter and they have not appeared in the ReceiveLocationTransportTypeData element when I export the bindings:

<ReceiveLocationTransportTypeData>&lt;CustomProps&gt;&lt;AdapterConfig vt="8"&gt;&amp;lt;Config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&amp;gt;&amp;lt;serverAddress&amp;gt;test-ftp-server&amp;lt;/serverAddress&amp;gt;&amp;lt;serverPort&amp;gt;21&amp;lt;/serverPort&amp;gt;&amp;lt;representationType&amp;gt;binary&amp;lt;/representationType&amp;gt;&amp;lt;maximumBatchSize&amp;gt;0&amp;lt;/maximumBatchSize&amp;gt;&amp;lt;maximumNumberOfFiles&amp;gt;0&amp;lt;/maximumNumberOfFiles&amp;gt;&amp;lt;passiveMode&amp;gt;False&amp;lt;/passiveMode&amp;gt;&amp;lt;firewallType&amp;gt;NoFirewall&amp;lt;/firewallType&amp;gt;&amp;lt;firewallPort&amp;gt;21&amp;lt;/firewallPort&amp;gt;&amp;lt;pollingUnitOfMeasure&amp;gt;Seconds&amp;lt;/pollingUnitOfMeasure&amp;gt;&amp;lt;pollingInterval&amp;gt;60&amp;lt;/pollingInterval&amp;gt;&amp;lt;errorThreshold&amp;gt;10&amp;lt;/errorThreshold&amp;gt;&amp;lt;maxFileSize&amp;gt;100&amp;lt;/maxFileSize&amp;gt;&amp;lt;uri&amp;gt;ftp://test-ftp-server:21&amp;lt;/uri&amp;gt;&amp;lt;/Config&amp;gt;&lt;/AdapterConfig&gt;&lt;/CustomProps&gt;</ReceiveLocationTransportTypeData>

Compare this to the ReceiveLocationTransportTypeData element after setting these properties and exporting the bindings – the userName and password properties are now included (yes, I know its like reading spaghetti, but you get the idea!):

<ReceiveLocationTransportTypeData>&lt;CustomProps&gt;&lt;AdapterConfig vt="8"&gt;&amp;lt;Config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"&amp;gt;&amp;lt;uri&amp;gt;ftp://test-ftp-server:21&amp;lt;/uri&amp;gt;&amp;lt;serverAddress&amp;gt;test-ftp-server&amp;lt;/serverAddress&amp;gt;&amp;lt;serverPort&amp;gt;21&amp;lt;/serverPort&amp;gt;&amp;lt;userName&amp;gt;user&amp;lt;/userName&amp;gt;&amp;lt;password&amp;gt;******&amp;lt;/password&amp;gt;&amp;lt;representationType&amp;gt;binary&amp;lt;/representationType&amp;gt;&amp;lt;maximumBatchSize&amp;gt;0&amp;lt;/maximumBatchSize&amp;gt;&amp;lt;maximumNumberOfFiles&amp;gt;0&amp;lt;/maximumNumberOfFiles&amp;gt;&amp;lt;passiveMode&amp;gt;False&amp;lt;/passiveMode&amp;gt;&amp;lt;firewallType&amp;gt;NoFirewall&amp;lt;/firewallType&amp;gt;&amp;lt;firewallPort&amp;gt;21&amp;lt;/firewallPort&amp;gt;&amp;lt;pollingUnitOfMeasure&amp;gt;Seconds&amp;lt;/pollingUnitOfMeasure&amp;gt;&amp;lt;pollingInterval&amp;gt;60&amp;lt;/pollingInterval&amp;gt;&amp;lt;errorThreshold&amp;gt;10&amp;lt;/errorThreshold&amp;gt;&amp;lt;maxFileSize&amp;gt;100&amp;lt;/maxFileSize&amp;gt;&amp;lt;/Config&amp;gt;&lt;/AdapterConfig&gt;&lt;/CustomProps&gt;</ReceiveLocationTransportTypeData>

I can understand why the adapter config only exports those properties that are used – why clutter the config with empty values, but a gotcha to watch-out for nonetheless.

Writing Unit Tests for Pipeline Components with NCover

Published
by
Nick Heppleston
on Monday, 27th October 2008
in BizTalk 2006 and Pipeline Components
. 4 Comments

I discovered NCover over the weekend and wow, am I a fan!

NCover is a code coverage tool which, to quote the website, “helps you test intelligently by revealing which tests haven’t been written yet.” In laymans terms, NCover graphically shows you which lines of code were not touched during the execution of your unit tests, allowing you to create tests accordingly to achieve 100% code coverage, as shown below:

Pipeline Component Testing

Armed with Tomas Restrepo’s excellent Pipeline Testing library, we can now comprehensively test our Pipeline Components:

1. Develop units tests to test your pipeline and ensure that the tests execute and are successful;

2. Invoke your testing framework from the command line to check that your tests will run correctly in the NCover environment (I’m using NUnit here, but you could also invoke VSTS):

"C:\Program Files\NUnit 2.4.8\bin\nunit-console.exe" BizTalkMessageArchivingComponent.Tests.dll

Which should produce the following output on the command line:

3. With our unit tests successfully executing, we can wrap the NUnit invocation in NCover loveliness which will inspect our code coverage while those tests executed:

ncover.console "C:\Program Files\NUnit 2.4.8\bin\nunit-console.exe" BizTalkMessageArchivingComponent.Tests.dll //ea Modhul.BizTalk.Pipelines.ArchiveMessages.Attributes.NCoverExcludeCoverage //et "Winterdom.*;BizTalkMessageArchivingComponent.Tests.*"

Producing command-line output similar to the following (notice the NUnit tests running between the ***Program Output*** and ***End Program Output*** text):

NCover has now determined the code coverage based of your unit tests and produces a Coverage.Xml file. This file contains information relating to the code coverage and can be loaded in the NCover.Explorer tool to produce a VS like environment that displays lines of code that were touched and un-touched by your unit tests.

4. Load the NCover.Explorer tool and open the Coverage.Xml file generated above, you will be presented with a screen detailing your code coverage. In the example below, you can see that the PerformImmediateCopy and StreamOnReadEvent methods do not have full code coverage – both have code which was not executed in our unit tests:

Clicking on one of the methods in the tree view loads the offending method, displaying the lines which were not executed by our tests in red; lines that were executed are displayed in blue:

Based on this information, we can now create tests to cater for these exceptions, ensuring we have 100% code coverage.

NCover is an excellent tool and although it isn’t free, I personally think its a must-have for any developers tool-kit.

BizTalk Assembly Redirection

Published
by
Nick Heppleston
on Monday, 1st September 2008
in BizTalk 2006
. 1 Comment

Over on the BizTalk Gurus Forums, Richard Wallace asked for opinions on best practice for central business logic that would span over a number of BizTalk applications. One of his suggestions was to use .Net assemblies that contained this business logic, however he was concerned about the re-build / re-deploy tax that this would introduce into his BizTalk projects if he needed to change his business logic assemblies.

In my reply I suggested that he looked at assembly redirection, which allows developers to redirect one version of an assembly to another, through changes to an executable’s .config file – in our case, btsntsvc.exe.config. Having never done this in anger in BizTalk, I though this would be a good opportunity for a blog post – here are my findings.

Configuration Changes

To enable assembly redirection, the following lines need to be added to the runtime/assemblyBinding element in the .config file

   1:  <runtime>
   2:      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
   3:          <dependentAssembly>
   4:              <assemblyIdentity name="BizTalkAssemblyRedirectionHelper" publicKeyToken="5cce5ee5c1d7dc25" culture="neutral" />
   5:              <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
   6:          </dependentAssembly>
   7:      </assemblyBinding>
   8:  </runtime>

On line 4, we identify the assembly we wish to redirect; on line 5 we identify the new version. If we had wanted, we could specify a range of ‘old’ assemblies that are to be redirected, as follows:

   1:  <bindingRedirect oldVersion="1.0.0.0-1.2.0.0" newVersion="2.0.0.0"/>

Restart the Host Instance/s for the redirect to take effect. If the new version of the assembly cannot be found in the GAC, you will only see an error when the CLR attempts to load the assembly at runtime, not when the Host Instance restarts, the error is a usual favourite:

Error details: Object reference not set to an instance of an object.

Testing Redirection: Orchestrations & Maps

To test the redirection, I created an orchestration and map that invoked simple helper classes contained within a separate assembly. The helper classes expose a single method which takes two strings as input parameters and returns a concatenation of the these two parameters – an example of the version 2.0 code can be seen below. Versions 1.0.0.0 and 2.0.0.0 were deployed to the GAC.

   1:  using System;
   2:  using System.Diagnostics;
   3:  
   4:  namespace BizTalkAssemblyRedirectionHelper
   5:  {
   6:      [Serializable]
   7:      public static class RedirectionHelper
   8:      {
   9:          public static string ConcatHelper(string a, string b)
  10:          {
  11:              Trace.WriteLine("RedirectionHelper - Orchestration, version 2.0.0.0");
  12:              return (a + b);
  13:          }
  14:      }
  15:  
  16:      public class RedirectionMapHelper
  17:      {
  18:          public string ConcatMapHelper(string a, string b)
  19:          {
  20:              Trace.WriteLine("RedirectionHelper - Map, version 2.0.0.0");
  21:              return (a + b);
  22:          }
  23:      }
  24:  }

Four messages were submitted into BizTalk; in-between the second and third messages, the assembly redirection code was enabled to point to version 2 of the assembly and the Host Instance restarted. The results of the test can be seen in the DebugView screenshot below – once the redirection config change is applied, both the Map and Orchestration start to use the version 2 of the assembly:

Assembly Redirection - DebugView Output

Conclusions

A few conclusions can be drawn from this test:

  • Assembly redirection can be used within BizTalk for helper classes in both Orchestrations and Maps (on ports & in orchestrations). There are other cases I can think of, such as pipeline components, for example.
  • The signatures of these helper methods must remain the same between releases.
  • There is a possible issue with build and revision numbers as highlighted by Richard Hallgren in BizTalk assembly version redirection.
Related articles by Zemanta
Enhanced by Zemanta

BizTalk 2006 (incl. R2) Management Pack for Operations Manager 2007 Released

Published
by
Nick Heppleston
on Tuesday, 15th April 2008
in BizTalk 2006 and MOM
. 0 Comments

Looks like the BizTalk 2006 & BizTalk 2006 R2 Management Pack for Operations Manager 2007 has been released and is available in the Management Pack Catalog.

To quote the catalogue entry, the management pack:

…is a entirely new … providing comprehensive discovery and monitoring of BizTalk Server components and applications. In addition to general support for BizTalk Server 2006, BizTalk Server 2006 R2, this management pack provides coverage for new BizTalk Server 2006 R2 features, such as the native EDI runtime and RFID.

I think its great that we now have native EDI and RFID monitoring ‘out of the box’ – no more need to cludge something together to monitor these two aspects of the product. I’d personally like to see this MP backported to MOM 2005, but I doubt that will happen!

Truncating the BizTalk 2006 Tracking Database

Published
by
Nick Heppleston
on Thursday, 10th April 2008
in BizTalk 2006 and SQL Server
. 4 Comments

In Truncating the BizTalk 2004 Tracking  Database I discussed how to truncate the tracking database in BizTalk 2004. Over on the BizTalk Gurus forums, user Nick Busy wanted to do the same thing for BizTalk Server 2006 – he’s kindly allowed me to repost his instructions for the community on this blog:

0. Before start, ensure you have got the database admin priveleges on the database

1. Stop all BizTalk Server Host Instances

2. Full backup BizTalkDTADb database (just in case)

3. Make scripts to create views (MANDATORY)

dbo.dtav_ServiceFacts
dbo.dtav_MessageFacts
dbo.dtav_FindMessageFacts

4. Run SQL script:

use BizTalkDTADb
GO

– Drop the Views (before you perform this, ensure you take copies of these views!)
– unfortunately, it’s necessary for SQL 2000, but you can skip it for SQL 2005
Drop View dbo.dtav_ServiceFacts
Drop View dbo.dtav_MessageFacts
Drop View dbo.dtav_FindMessageFacts
Go

– Truncate the necessary Tables
Truncate Table dta_CallChain
Truncate Table dta_DebugTrace
Truncate Table dta_MessageInOutEvents

Truncate Table dta_ServiceInstanceExceptions
Truncate Table dta_ServiceInstances

Truncate Table Tracking_Fragments1
Truncate Table Tracking_Parts1
Truncate Table Tracking_Spool1

Truncate Table dta_MessageFieldValues

– end of the script

5. Update statistics on BizTalkDTADb database

– update statistics
exec sp_updatestats

6. Run the saved scripts (see step 3) to recreate the dropped views from your own environment.

7. Shrink BizTalkDTADb database (sometimes it doesn’t work from GUI, so using sql command will help)

– shrink database
dbcc shrinkdatabase (BizTalkDTADb, 10)

8. Start BizTalk Server Host Instances

9. Configure and enable SQL Agent job “DTA Purge and Archive” (to avoid over-growing the database in the future)

P.S. The script above does not truncate Rule Engine related tables.

Thanks Nick, much appreciated.

Get Adobe Flash playerPlugin by wpburn.com wordpress themes