Today I've encountered a problem with the party configuration, specifically while reconfiguring send ports from a party. An error occurred when I removed a send port from a party and saved my settings.

The error

The error occurred during the removing of a send port from a party: Sendport Reference [Microsoft.BizTalk.B2B.PartnerManagement.SendPortReference] cannot be deleted as it is use by agreement [Microsoft.BizTalk.B2B.PartnerManagement.SendPortReference]. (Microsoft.BizTalk.B2B.PartnerManagement)

The troubleshooting

Based on a forum thread on MSDN, this seems to be a bug in the BizTalk console, but has never been officially announced or patched. The forum thread suggests waiting for the next cumulative update for BizTalk server [link: cumulative updates Biztalk]. But even when I applied an update for BizTalk to the next version, the problem didn't got solved.

Based on the error message, a constraint prohibits removing the send port record assigned to this party. The OnewayAgreementSendPortReference table contains all send port records for each party. A foreign key is present between OnewayAgreementSendPortReference.SendPortReferenceId and the SendPortReference.Id colomn.

The solution

I had to manually remove the Foreign key record from the SendPortReference table.

Connect to the BizTalk SQL database instance of the BizTalkMgmtDb catalog.
Change the @Name variable to the name of the send port you would like to remove from the party.

DECLARE @NAME varchar(100)
SET @NAME = 'spo_3025816970108_3014683300200_INVRPT_EDI_FTP_PRD'

DECLARE @ID int
SELECT @ID = id
  FROM [BizTalkMgmtDb].[tpm].[SendPortReference]
  WHERE Name = @NAME  
  
DELETE FROM [BizTalkMgmtDb].[tpm].[OnewayAgreementSendPortReference]
  WHERE SendPortReferenceId = @ID

  DELETE FROM [BizTalkMgmtDb].[tpm].[SendPortReference]
  WHERE Name = @NAME

After running this query, refresh your BizTalk administration console and the send port is now removed from the party.

Important note:
Be aware that fiddling with the BizTalk internal databases is not a recommended approach and is not supported by Microsoft.
Any support case dealing with issues after manually changing the BizTalk internal databases will have to be paid fully or result in a re-installation!

For a recent project I needed to create and modify the party settings for a specific party through code.

All the ‘basic’ settings like UNA/UNB/Validation/… where rather easy to configure and are pretty straight forward.

However when wanting to configure the UNG segment, we ran into some issues.

But first things first, let’s create a new Party

To modify the EDI properties through code you need to initialize/load a Partner profile as shown below

When you loaded/created the Partner profile it’s rather straight forward to modify the basic Party Settings.

The real problem started when we had to create a UNG segment trough code.
To create a UNG you need to create a PartnerEdifactReceiverGroupUpdatable object and add it to the EdifactReceiver as shown below:

The actual problem here is that the PartnerEdifactReceiverGroupUpdatable class has no constructors defined. Also extending the base class

or implementing the interface did not give us the desired result.

After some investigation we ran into the GetUninitializedObject method from the FormatterServices class (http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatterservices.getuninitializedobject.aspx).

This method will create a new object of a class without calling the constructor, that way we initialized a new instance of PartnerEdifactReceiverGroupUpdatable and managed to create the UNG segment as show below.

Enjoy!

Glenn Colpaert

Recently, I encountered a strange problem at a customer. MSDN blogs warned us about the leap year date 2/29/2012 when using EDI in BizTalk Server 2006 R2 or 2009, as you can see on this blogpost. It was during the install of this hotfix on a BizTalk 2006 R2 server I was encountering the problem. I’ll explain the problem over here and show you the easy work around.

EDIT: Apparently Microsoft has solved this error. A more recent version of the hotfix download does autodetect Cumulative Update 3, without using a version number. The latest version of the hotfix can be found over here.

However, I will show you how I worked around the problem (because the newer version was not yet available at that time).

Prerequisites

MSDN blog is indicating that the install of the EDI leap year hotfix on BizTalk Server 2006 R2 requires some prerequisites.

Since BizTalk 2006 R2 Service Pack 1 was already installed in this particular case, I only still needed to execute step 2 and 3. Installing the Cumulative Update 3 gave me no problems. So far, so good.

Install of the leap year date hotfix itself

However, when installing the leap year hotfix, I encountered following error:

“The patch 861c5534-6cfa-4dcf-ba70-cbf01129b646 in the package Microsoft BizTalk Server 2006 R2 Hotfix [See KB article 2435900 for detail] cannot be applied.  The minimum installed version of Microsoft BizTalk Server 2006 must be 3.6.2222.12.  The installed version on this computer is 3.6.1404.0.”

This was quite strange to me, since MSDN blog was indicating that Service Pack 1 and Cumulative Update 3 should be sufficient as prerequisites to install the hotfix. A little investigation led to the following.

Checking the Registry Editor (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BizTalk Server\3.0), showed us that the current product version is ‘3.6.1404.0’. 

This is just like the error indicated, while it expects a version of 3.6.2222.12 or higher. So I started searching the web to check if that Product Version Key was correct and related to BizTalk Server 2006 R2 SP1.

BizTalk Server 2006 R2 SP1 Product Version Key

On a Microsoft Technet wiki page I found following table with the all product version key’s correlated to the product name:

What you can see over there, is that the Product Version Key is not adapted when Service Pack 1 of BizTalk Server 2006 R2 is installed. This is not consistent if you compare it with the other version of BizTalk Server.

Strange thing, BizTalk 2006 R2 SP1 comes with Product Version Key 3.6.1404.0, while the install of the hotfix needs a version of 3.6.2222.0 or higher. Because the prerequisites for the hotfix (BizTalk 2006 R2 SP1 and CU3) were correctly installed and yet the Product Version Key seemed not to be right, I started thinking about a possible solution to fix this little error.

Workaround for the error

Since installing the hotfix for the leap year date is all about just running a ‘Setup’ and there’s also a Setup.xml file in the folder, I had a look over there.

As you can see in the print screen below, there indeed is a field ‘MinProductVersion’ indicating the version should be at least 3.6.2222.12. This is why we encountered the error.

So what about changing this value to a Product Version lower than 3.6.1404.0, the one that is installed on the server now? Let’s give it a try.

NOTE: make a copy of the original Setup.xml, in case the change would not be effective.

As you can see below, I changed that one value in the xml document to ‘MinProductVersion = “3.6.1.12” ‘.

Before executing the Setup again, and hoping it will not fail on the Product Version again, we need to find a way to check if the setup will be executed effectively.

In the Setup xml file we can see some assemblies that will be adjusted to a newer version when executing the hotfix. Therefore we can check the current file version of a specific assembly and see if the file version has been changed after the execution of the Setup.

For example, we can see in the setup xml file that ‘Microsoft.BizTalk.Edi.Shared.dll’ should have version 3.6.2230.12 after the execution.

A quick lookup shows us that the file version of that assembly is ‘3.6.2224.12’ right now.

If we now execute the Setup and check this file version of the assembly again afterwards, we should see it’s changed to ‘3.6.2230.12’ if the Setup was successful. Let’s try this!

I executed the Setup again and did not encounter the same error again, indicating the product version is too low. So that’s a good start. Now that the wizard indicates the execution has successfully ended, let’s have a look at the file version again.

And yes, the file version was changed to 3.6.2230.12 and therefore the assembly was updated. Together with the fact that our newly installed hotfix is shown in the ‘Installed programs and updates’-overview (as you can see below), we can conclude that our workaround for the error and therefore the installation of the hotfix itself has been successful!

From private to public CTP

Last weekend, a new big step was set for companies in the Microsoft integration space, since the Microsoft Azure team released the first public CTP of the ServiceBus EAI & EDI Labs SDK.  This was formally known as Integration Services.  In september, we got a chance to play with a private CTP of this Azure component and since then we have provided a lot of feedback, some of which has already been taken up in the current release.  The current release seems much more stable and the installation experience was great.  (I installed the CTP on various machines, without a hickup)

It wasn’t surprising to see the BizTalk community picking up this CTP and start trying out various typical BizTalk scenarios in the cloud:

• Rick Garibay discussed the various components in his blog post.
• Kent Weare posted two articles (introduction & mapper) on his blog.
• Mikael Håkansson showed the content based routing capabilities in this article.
• Steef-Jan Wiggers added an overview TechNet wiki.
• Harish Agarwal wrote an overview on EAI bridges.

Multi-tenancy & high-density

A huge difference for this model is that our pipelines, mappings and message flows are running on shared resources in the Windows Azure data center in some kind of high-density / multi-tenant container.  This introduces an entire new architecture and concept for isolation.  That also seems like the main reason why following capabilities are not yet possible or available:

• It is not possible (yet) to develop custom pipeline components and have them running in the Azure runtime.
• The mapper does not support (yet) custom XSLT or Scripting functoids.
• Message flow does not contain workflow or custom endpoints.

This is feedback that the Microsoft team has received and is well aware of.  Things just get more complex and risky, when running custom applications or components in a shared environment.  You don’t want my memory leak causing a downgrade, or even failure, in your processes, right?  Based on feedback I gave on the connect web site, I really have the feeling these items will be available over time, so being patient will be important here.

The various components

This CTP contains a nice set of components:

Service Bus Connect

Service Bus Connect introduces an on premises service that exposes local LOB applications (like SAP, SQL, Oracle…) over the Service Bus Relay to the cloud.  This is a more lightweight service, compared with BizTalk and gives customers the ability to have a more lightweight and cheaper solution than buying BizTalk Server for the LOB connectivity.  It also make sure we no longer have to write custom services, or even worse: console applications to expose LOB adapter services over the Service Bus.

Service Bus Connect leverages the LOB Adapter SDK and the available adapters and exposes these endpoints over the Relay services of the Service Bus.  The local endpoints are hosted in Windows Server AppFabric and we can manage these endpoints in various ways:

• In Visual Studio Server Explorer (ServiceBus Connect Servers).  This makes me think back about the BizTalkExplorer in Visual Studio that took 2 or 3 releases to disappear.  Admins still want MMC, in my opinion.
• Over a management service, exposed as a WCF service.  One of the things that we want to do for our Codit  Integration Cloud, is exposing this management service over the service bus, so that we can maintain and operate the on premises services from our Cloud management portal.
• Through powershell

EDI processing

It took Microsoft 5 releases of BizTalk Server, until they provided a full fledged EDI solution in BizTalk Server.  Therefore, it’s great to see these capabilities are already available in this release, because EDI is not disappearing and doesn’t seem to disappear any time soon, how much we all would like it to...  Support for X12 is available and also for AS/2 (the exchange protocol).  What is missing for us, Europeans, is EDIFACT.  Again, some patience will be rewarded over time.  What is very promising for migration or hybrid scenarios, is the fact that the provided EDI/X12 schemas look the same as those that were provided with BizTalk Server.  That will make migration and exchange of these messages from Cloud to On premises BizTalk much easier.

The EDI Trading Management portal allows to define partners and agreements, linked with various messaging entities on the service bus.  All of this is provided through a nice and friendly metro-style UI (what else).

I believe this is one of the most suitable scenarios for cloud integration.  B2B connectivity has been very expensive for years, because of the big EDI Value Added Networks and this is, after AS/2, a new step forward in making things cheaper and more manageable. 

EAI processing

One of the strengths and differentiators of BizTalk towards its competition was that it was one generic suite of components that could be used for both EAI, B2B and ESB solutions.  One products, one tool set, one deployment model.  That’s why it worried me a little to see that EDI and EAI are being seen as two totally different things in the release.  Looking a litle deeper shows that the EDI portal is mainly configuration of partners and endpoints, in order to link messages to the right Service Bus or messaging entities.  Still I think the same portal concepts can become valid for non-EDI integration, where companies just exchange messages in different formats (flat file, XML…) over various protocols (mail, file, FTP, AS/2).  I hope to see that we will be able to configure all of these connections in the same and consistent way.

Looking at the EAI capabilities, there are some nice new and refreshed items available:

• Mapper: this looks like the BizTalk mapper, but is much different.  One of the biggest differences is that it does not create or support XSLT, or it does not support custom code. 
• XML Bridges: these are the new pipelines.  A bridge is a head in front of the service bus that is exposed as an endpoint.  Various options are available and are discussed in the posts, mentioned above.  The biggest missing link here, is the extensibility with custom components.  At this moment, it doesn’t look possible to have (de)batching, custom validation, zipping and all these other things we do in BizTalk pipeline components.
• Another thing that is interesting that a new concept of pub/sub is introduced here.  You can use filters in the message flows and those filters are applied in memory and the first matching filter will make sure the incoming request gets routed to the right endpoint.  The pub/sub here is in memory and is not durable.  Making it durable, requires to have it routed to either a queue or topic.  So, this routing model looks much similar to the WCF Routing service and less to the durable BizTalk or Service Bus topics.

Conclusion

This release is much more stable than the private CTP and looks promising.  To be able to deliver real world integration projects with this, there is still a lot of things needed towards customization and extensibility and towards management and monitoring.  The components are also targeted to real technical/developer oriented people.  With Codit Integration Cloud, we provide the level of abstraction, monitoring and extensibility, while using these EDI & EAI capabilities under the hood.

Sam Vanhoutte

A couple of weeks ago, I had to create a custom EDI party trough code.
I noticed that the information provided on this topic was rather small and that other people were experiencing the same problem as well.
After some research I did on this topic, I discovered it’s actually rather easy to do these kinds of modifications through code.
Below you can find an example on how to create and modify your EDI Party.

Prerequisites

You will need to add references to following assemblies in order to create and modify an EDI Party trough code.

These assemblies can be found in the BizTalk installation folder.

Add new Party

The first step is to add a new party to your BizTalk Group.
Below is an example how to add it through code, but it’s perfectly possible to add this through the BizTalk Administration Console.

Modify the Party Settings

The party you just created will be used to create a new partner.
After that you can tweak and modify every setting needed for your Party/Partner.
There are tons of possibilities to adjust, but below you can see some basic modifications I did.

The result

When we open the BizTalk Administration console, we can view the result.

The source code of my example can be found here.
EDIPartyManagement.zip (18.43 kb)

Glenn Colpaert, CODit

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

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