Many of us at Codit already installed the WCF LOB SDK multiple times. And in the process we have learned to know the caveats that come with the installation:
- 32 bit vs 64 bit
- Adapter Pack installation (again, 32 bit vs 64 bit)
- Enterprise application installation

Now since BizTalk 2010, there is a great wizard added to the installation screen if you click “Install Microsoft BizTalk Adapters”:

The screen shows up like this once you go through the entire installation:

Please note that the above screenshot is from a production server where I don’t have Visual Studio installed, so I could not install the developer tools (hence the warning)

It is a very welcome change, because before BizTalk 2010, people did not know exactly what they needed to install and in which order.
Now the screen gives you a very handy wizard-style interface.

Now recently I had a strange error: on a 64-bit machine I went through the installation.
I was sure that everything was installed correctly and in the right order!

I checked all machine.config files (for framework 2.0 and 4.0, both 32-bit and 64-bit) and all had the necessary entries added.
However, there was no way I could see/add the WCF LOB Adapters in the BizTalk console:

I went through a lot of online searching until I accidently stumbled upon the BizTalk modify wizard:

It happens that the WCF Adapter components in BizTalk were not installed, so the WCF adapters were not showing up for a good reason!

When I checked both checkboxes (WCF for BizTalk Runtime and Administration Tools And Monitoring), installed it on both nodes and re-opened the BizTalk consoles, I could add the WCF adapters I needed.

I hope this helps at least someone!

Recently a customer of ours asked us if it was possible to include versioning information into the title of the installed MSI.

These MSI files can be generated by right-clicking a BizTalk application and selecting "Export" and then "MSI file":

This generates the MSI file on disk.

Problem however is that the MSI file which gets generated always has version 1.0.0.0 assigned to it.
We can always use Microsoft's Orca tool to manually update the properties of the file, but this is very cumbersome to say the least.

I went on to search if there was an option to pass some parameters to BTSTask.exe.
This tool allows you to perform the "Export MSI" via the command line, allowing you to script it.
Unfortunately this tool does not allow you to set the version information at all. 

Luckily, BizTalk comes with a .NET API that allows you to update the properties of the MSI installer package.
For BizTalk 2010 this is the Microsoft.BizTalk.MSIManager assembly.

using Microsoft.BizTalk.ApplicationDeployment.MSIManager.WindowsInstaller;

This assembly allows you to query/update the MSI database structure contained within the MSI file.

Just provide the following code to update the name of the application for example:
msiPath = full path to your MSI
applicationName = your custom application name that will appear in your "Programs and Features" list under Windows.

static public void UpdateMSIApplicationName(string msiPath, string applicationName)
        {
            Database db = Installer.OpenDatabase(msiPath, DatabaseOpenMode.Transact);
            string query = @"UPDATE Property SET Property.Value = '" + applicationName + "' WHERE Property.Property = 'ProductName'";
            Microsoft.BizTalk.ApplicationDeployment.MSIManager.WindowsInstaller.View vw = db.OpenView(query);

            vw.Execute();
            vw.Close();

            db.Commit();
            db.Close();
            db.Dispose();
        }

You can also update your Manufacturer information to customize the directory where the MSI gets installed. By default this is "Generated by Biztalk".
Use this query to perform the update then:

string query = @"UPDATE Property SET Property.Value = '" + manufacturer + "' WHERE Property.Property = 'Manufacturer'";

I also tried updating the version information, but for some reason this will insert some minor errors during installation having to do with the registry.
I believe this has to do with the registry keys that are installed by default within the BizTalk MSI version. 

Incorporating all of this into a properly automated build/deployment scenario will allow you to publish your MSI files with customized versioning.

Good luck.

Some time ago, with a client using BizTalk 2006 and Covast Accelerator 2006, we suddenly had the following issue popping up in their event log:

There was a failure executing the send pipeline: "Covast.BizTalk.Pipeline.EDI.CovastEDISendPipeline, Covast.BizTalk.Pipeline.EDI.Default, Version=5.0.0.0, Culture=neutral, PublicKeyToken=68bef120a46b49ad" Source: "Covast EDI Assembler" Send Port: "sp_MySendPort" URI: "D:\BTS2006\DumpLocation\%MessageID%.edi" Reason: Message translation failed: (2217) Unknown error (-2217)

The source of the problem was Covast.
Somehow, it was no longer able to perform valid assembling and disassembling (both were failing).

After a lot of digging and research I finally came to the "Covast EDI Accelerator 2006 Reports" screens, hidden deep within the BizTalk Administration Console HAT :-)

When you double click the interchange which was in error, you saw the following error:

The format of the document has not been configured

Finally, this led me to the source of the problem.

Someone at the client fiddled around with one particular ASC file trying to add some extra segments to the schema to accompany a change in one of their flows. No harm done, but unfortunately when re-generating the XSD, he also regenerated the SYNTAX schema and deployed.

The result was that there were now 2 SYNTAX schemas deployed within BizTalk and Covast doesn't know how to handle that.
Reverting back to the old version of the flow fixed the error and after that we just removed the SYNTAX schema from the project, rebuilt and deployed and now it worked.

Reason for posting this is that at the time, neither search engine could come up with a decent answer, so hopefully someone benefits from this post.

Let us know in any case!

Pieter

Anyone who has ever worked with Business Rules and with the Business Rule Composer has had it's share of problems when you want to perform a small modification to their policy or vocabulary.

Normally, when in production or QA phase, you would copy/paste your old version to a new version of the policy/vocabulary and then modify what was needed. The tool does not allow you to change already published policies or vocabularies. This to make absolutely sure that the same version of the policy/vocabulary would not result in different results.

Now this is all fine unless you are actually developing everything from scratch.... 
Now, most of the time you would work with a vocabulary and would build this along the way. Publishing a new version every time you add a new entry to your vocabulary is a common thing, but at the end of your work you end up with several versions (sometimes up to 10/20). This makes it quite difficult to maintain.
What makes it worse is that your rules depend on specific versions of your vocabulary...

At the end of your business rules development you would most likely want just one version of your vocabulary and one version of your ruleset (most likely v1.0).
This means that you would need to update all your rules and all your vocabularies which is again a very time consuming process.

Now, we found a little trick that enables you to "un-publish" a vocabulary and even a ruleset while you are developing them. Off course this is something you would only do while actually developing it from scratch. It would definitely be a bad practice to execute this on production vocabularies and/ or policies!! 

Here's how you do it for vocabularies:

1. Publish your vocabulary and use it in your ruleset to test your rules.
2. When you need additional changes to your vocabulary, go to "SQL Server Management Studio" and open the contents of the DB table "re_vocabulary" in the DB "BizTalkRuleEngineDB".
3. Check your vocabulary name in the "strName" column (second column in the table), together with the "nMajor" and "nMinor" columns which together make up your version number of your vocabulary.
4. Once you found your particular vocabulary, set the "nStatus" column to 0 instead of 1 to "un-publish" your vocabulary.
5. Reload your Business Rule Composer view (Press F5).
   Be aware that you need to be able to save your rulesets/vocabularies without errors to be able to do so.
6. Perform the necessary changes to your vocabulary set...
7. Republish, but not using the Business Rule Composer, but via setting "nStatus" to 1 again.

Good luck!

Pieter Vandenheede

Introduction

EDI interchange batching is the process of creating an EDI file or interchange which contains multiple EDI transaction sets. Creating this interchange is called “EDI batching”.

EDI Batching can be done out of the box in BizTalk 2009:
There is the built-in batching orchestrations within BizTalk 2009 which can be started within the application “BizTalk EDI Application” and managed within the configuration of your party. More information about how this method works, together with a walkthrough, can be found here.

Note that the link will give you a step by step guideline for BizTalk 2006 R2, but should work for BizTalk 2009 as well. The only difference, as far as I can see, seems to be that the batching configuration within BizTalk 2006 R2 is separated between X12 and EDIFACT and for BizTalk 2009, you can configure it within the same dialog box (Parties > EDI Properties).

Screenshot:

Image: EDI Batching settings dialog in BizTalk 2009

Pros & Cons

For most companies the built-in batching solution within the party configuration will be sufficient: You can let the batch subscribe to your messages and your EDI messages will be batched one by one and will be released depending on the release criteria that you have set.

As you can see from the screenshot, these criteria can be scheduled (in a timely manner), based on the number of group segments or transactions sets within the interchange or by an external release trigger.

One important thing that I found while testing this method is that the batching orchestrations will only accept EDI messages which are considered to be “complete”. Otherwise you would get an error from the batching orchestration “71: Transaction Set or Group Control Number Mismatch”.
This is because the orchestration logic tries to assemble your EDI message, but cannot find the UNH and UNT segments within the message instance.
If you have just created the EDI message instance from a map for example, this is not filled in by default. You would first need to execute the EdiSend pipeline on your message to do this.

This built-in batching method should be quite easy to use if your release mechanism requirement is one of the available release criteria. However, I don’t see how you would easily determine the order of your messages in your outgoing interchange.

It also becomes complex when you need to be able to build parallel batches, initialized by different source messages.  

An alternative batching method

And off course, this is where this alternative batching method comes in…
First, I wish to thank my colleague Carl Batisse for providing me a glimpse to this solution: thank you Carl!

This alternative method is using a batch schema that is mainly used for validating instances of interchanges. However, it can also be used to reverse the process and thus create interchanges from the Xml you created.

The EDIFACT batch schema can be found in the BizTalk 2009 folder in the location:
“<BizTalk_Installation>\XSD_Schema\EDI\Edifact_BatchSchema.xsd”
For X12, one would use the “X12_BatchSchema.xsd” file.

In my example, I will only use the EDIFACT schema, which looks like this:

Image: Edifact_BatchSchema.xsd

To validate an interchange against this batch schema, add it to your project together with the EDIFACT schemas that it will contain. If you run the “Validate Instance” on the batch schema, each EDI schema included in your project will be tested against your instance.

If you want to generate an instance of the schema, the batch schema will contain 3 transaction sets of all of the EDI schemas in your project, which is handy!

The result of the generated instance clearly shows you how the schema works. In my example I have added the the EDIFACT schemas for DESADV and IFCSUM and the batch schema to my project:

 Image: Edifact_BatchSchema.xsd generated instance for DESADV and IFCSUM

You can clearly see the UNA, UNB and UNZ records and in between those, you can see that there is one “TransactionSetGroup” and “TransactionSet” record for each transaction set in the interchange. The DocType attribute defines the type of EDI message that is contained within the transaction set.

The attribute at root level “DelimiterSetSerializedData” contains the decimal representation of the characters used for delimiting, just as the UNA segment. The UNA segment can also be filled in with the actual characters instead of the decimal representation, but the notations cannot be mixed.

This means that you can simply map to this batch schema (with XSLT for example, which will be handier in this case). If you, for example, need to have multiple IFCSUM transaction sets within your interchange, you can provide a “xsl:for-each” loop containing the transaction set details.

After the mapping, you would simply let loose the EDI assembler on your instance and the EDI would be created… or not?

Now here comes the tricky part about the use of this schema… it will not allow you to continue without presetting the UNB and UNZ (on interchange level) and UNH and UNT (on transaction set level) segments. The EdiSend pipeline for example will not do this for you. Instead, in this case, it would provide you with a nice error message again.

So BizTalk will not handle the interchange control number and transaction set control numbers for you and this is a bit of a downside to this solution. This means that you would need to store the last used interchange and transaction set control numbers somewhere. This could be a database for example.

Specific nodes to fill in (EDIFACT)

At interchange level:

UNA, UNB1 (syntax version), UNB2 (sender identifiers), UNB3 (receiver identifiers), UNB4 (interchange date and time, depending on UNB1 version), UNB5 (interchange control number), UNZ1 (number of messages in the interchange) and UNZ2 (copy of UNB5).

At transaction set level:

UNH1 (transaction set control number), UNH2 (transaction set type and version), UNT1 (transaction set segment counter), UNT2 (copy of UNH1).

The transaction set segment counter can be a little tricky, because you would need to count the segments in your XSLT. The EDI assembler will however correct this value if it happens to be filled in incorrectly. It will however show you a warning in the event log, which can be ignored.

Pieter Vandenheede, CODit