Tag: AS2

BizTalk 2010 Party Migration Tool Issues & Workarounds

Introduction

Back during the BizTalk 2010 beta I was testing out the Party Migration tool. This tool enables a smoother migration path from BizTalk 2006 R2 and BizTalk 2009 to BizTalk 2010. It is very useful once you get it to run successfully. Back during the beta I experienced quite a few issues and apparently these issues remain in the final version (RTM) of the tool. This post will describe these issues and give the full steps for a workaround. I am using very similar steps I used during the beta here.

Issues

The party migration tool can be found on the install media at <install media path>\core\BT Server\PartyMigrationTool\PartyMigrationTool.exe. The help description found at http://technet.microsoft.com/en-us/library/aa578307(BTS.70).aspx mentions this should be run from a CD.  It would be nice to know this when trying to run the tool but this is not mentioned in the error messages.

Back during the beta the files were distributed just as they are now with the BizTalk 2010 Developer edition – as an extractable exe that does not come as an ISO. This is problematic because the intention for running this tool is that it will be loaded on an ISO or removable media. So you will need to either burn an ISO or use a workaround.

This tool does require you to right-click Run as Administrator or to execute it from an elevated prompt. Otherwise you will get odd CAS errors:

Request for the permission of type ‘System.Security.Permissions.UIPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed.. For more details please see the event log.

Initially, if you are using the BizTalk 2010 Developer edition or have not burned an ISO, and try to open the PartyMigrationTool.exe you will receive assembly not found errors like this:

System.IO.FileNotFoundException was unhandled
Message: Could not load file or assembly ‘Microsoft.BizTalk.Migration.PartnerManagement, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

If you run off the ISO or removable media everything works but there is another way for this to work.

Workaround

  1. If you are using BizTalk Developer edition or did not make an ISO, go to the PartyMigrationTool folder. Keep this open.
  2. You will need to add 3 assemblies to the GAC next. I found it easiest to copy these three assemblies to the PartyMigrationTool folder to keep everything together. All of these assemblies are found on the BizTalk 2010 install media. The assemblies you will need are:
    a. Microsoft.BizTalk.B2B.PartnerManagement.dll in \core\BT Server\MSI\Program Files\Developer Tools
    b. Microsoft.BizTalk.Migration.PartnerManagement.dll in \core\BT Server\MSI\Program Files
    c. Microosft.BizTalk.Migration.PartnerManagement.XmlSerializers.dll in \core\BT Server\MSI\Program Files
  3. [Note]: I had previously recommended modifying the PartyMigrationTool.exe.config to redirect the assemblies but upon retrying with the RTM bits I thought it was just easier to GAC everything necessary. 2.a. fails anyway because there is not an entry for it in the config.

I did want to mention one other note. When you finally get the tool running, you will need to connect to SQL Server using Windows authentication, SQL authentication is not supported.

Thanks,

6

More Tips for BizTalk ManagedDTS Issue

I was working on tracking down an issue with MDNs not being received for some AS2 communications. So I decided to enable the AS2 status reporting capabilities in BizTalk. I needed to configure BizTalk so that the BAM Tools functionality was available in order for the AS2 status reports to be available. During the process of using the BizTalk configuration wizard I received an error, which is given below:
 
"BizTalk 2006 Configuration: Microsoft SQL Server 2005 Data Transformation Services (DTS) for BAM Archiving is not installed on the local machine.  Please install Microsoft SQL Server 2005 Integration Services.  (Microsoft.BizTalk.Bam.CfgExtHelper.ToolsHelper" … Additional information: “Could not load file or assembly ‘Microsoft.SqlServer.ManagedDTS, Version=9.0.242.0”…
 
This error occurred when trying to configure the BAM Tools and I was specifying the database server names and the names of the databases. A red icon with an "X" occurred to the left of the database name. If you did not know, you can double click on the red icon on all of the pages of the BizTalk configuration wizard to see the error. 
 
After looking on the internet I came across two blog posts (http://blogs.msdn.com/mattlind/archive/2006/08/30/730575.aspx, http://geekswithblogs.net/andym/archive/2006/11/27/99246.aspx) that gave me a few hints on what needed to be done but I still felt there were gaps in documentation and the blog posts so I wanted to give a little more information here for other people so that they would not need to come up with their own ideas of what needed to be done. I will also be referring to the multi-server BizTalk installation guide which can be found among the guides here: (http://www.microsoft.com/downloads/details.aspx?FamilyID=df2e8a88-fb23-49a4-9ac7-d17f72517d12&DisplayLang=en). The AS2 and EDI Status Reporting features of BizTalk Server 2006 R2 do provide a huge help in doing diagnostics of EDI interchanges and AS2 communications, but the process of enabling this feature is complicated.
 
A multi-server install usually means that BizTalk is on one (or more) servers and the SQL Server engine components are on some other (one or more) servers. In the BizTalk multi-server install guide, if you are trying to setup BAM Tools (one of the prerequisites for the AS2 Status reporting), it recommends that you install SQL Server Integration Services (SSIS) on the BizTalk box. This is wrong and could represent a license violation if you actually did this. This is one solution but there is actually a different solution which is better. BTW, the BAM install guide does not mention anything about the AS2 Status reporting so you can just skip this document if you are trying to setup the AS2 reporting functionality.
 
Although the error message indicates that the problem is a DLL named Microsoft.SqlServer.ManagedDTS is missing, this does not mean that something about the DTS functionality outside of SSIS is not functioning properly. This refers to a DLL that is installed on the SQL Server box relating to SSIS but not part of it that also needs to be on the BizTalk server. If you open up the SQL Server system and look in the GAC (at c:Windowsassembly), you will see that this DLL exists on a SQL Server where the "Workstation Tools" have been installed. So all that is required is that you install the SQL Server client tools on the BizTalk server which in the SQL installer are designated as "Workstation Tools". BTW, there is not a way to export a copy of the DLL from the GAC and I would advise against trying to individually copy this DLL out of a CAB from the SQL install because there are also additional DLLs that may need to be on the BizTalk server as well. It is important to note that it is not enough to just have the Workstation Tools installed only on the SQL Server itself. As one of the previous posters mentioned, you should select all of the Workstation Tools components on the install on the BizTalk server. This may require that you insert the install media into the BizTalk server or that you copy the installation software over to the BizTalk server.
 
In Andy Morrison’s post, he mentioned he had received an error when installing the SQL client tools (Workstation Tools), regarding OWC11. This is a variation on the install of the client tools. You could get other errors too – the key is to ensure the client tools run through successfully. Right before the client tools are installed you will see a window that goes through a series of prequisite checks for the SQL client tools install and you may need to ensure all of these tests pass with a warning or are successful before the client tools install will work. When I ran the client tools on the BizTalk server I did not receive an error so you may not need to reinstall OWC11 and you may not need to do a repair on the BizTalk installation. Ok, there are just a few more steps.
 
Then after you have run the Workstation Tools on the BizTalk server you will need to close the BizTalk configuration wizard and re-open it in order for the BAM Tools page to successfully see the Workstation Tools and connect to SQL Server appropriately. You can then specify the BAM Tools options and then recheck the AS2 status reporting option under the EDI/AS2 Runtime page. After running through the BizTalk configuration wizard successfully you will then need to open up the BizTalk administration console and go to the Party properties. On your AS2 party you will need to open up the AS2 properties and then on the General tab check to enable the AS2 status reporting. You may also want to check the other boxes on the Sender and Receiver pages of AS2 properties for whether to store the wire and decoded messages of the AS2 communications so that you can drill into this data from the Group Hub page.
 
After all of this configuration, you should restart your BizTalk applications and hosts and then wait a while so that the AS2 status reporting can collect some data. Then go to the Group Hub page and click refresh. The Group Hub page will now have some additional links to reports but you will probably need to scroll down on the group hub page in order to see them. Normally all of the group hub page fits within the standard size window but the additional AS2 status reporting enables the use of the scroll bar so be aware that these links may be off-screen initially when you view the Group Hub page.
 
Thanks,
 
0

BizTalk EDI Routing Workarounds

I have been in the final stages of a large BizTalk EDI project and I have been struggling with the appropriate infrastructure for managing a single AS2 HTTP endpoint that interacts with a VAN over which multiple trading partners’ data is sent. The main challenge has been that if a single endpoint to BTSHTTPReceive.dll is exposed, it will provide data for many trading partners yet these partners may be used across one or more BizTalk applications. Since the endpoint usually exists as a 2-way receive port with As2EdiReceive/As2Send as the pipelines, I have been using send ports with filters to catch the messages after they are pushed to the MsgBox from the exposed endpoint. When just a single BizTalk application exists that includes the endpoint, all messages can be routed easily. But when more than one BizTalk application exists, it becomes much more complicated.
 
For example, if you have the exposed endpoint in Application 1 and two send ports in Application 2, these send ports will be able to pick up messages received on the exposed endpoint but you will see errors being logged from Application 1 that the messages could not be routed successfully. For this reason, I have found that it is important to have send ports that are used for picking up messages received through BTSHTTPReceive.dll in the same BizTalk application as the receive port for the endpoint. So I have written to disk the messages received from the endpoint that are used in other BizTalk applications as a way of offloading the messages to processes and orchestrations in the other BizTalk applications.
 
One problem with this approach is that sometimes the messages received in Application 2 do not have the correct ISA/GS headers or may have been altered through the application of the Global EDI properties. These properties can make understanding BizTalk routing very painful because they frequently cloud or disguise the intended recipient of messages. In my project, messages that are received in Application 2 have been placed in the correct folder so I know that the routing infrastructure was able to match the ISA and GS headers to the party properties, yet at some point during the routing the Global EDI properties were applied anyway. Today I identified a workaround for a situation in which a message has been routed with incorrect headers.
 
For send ports that have filters that write messages out to offload to other BizTalk applications, you can use a PassThruTransmit pipeline on the send port filter to write the body of an EDI message out to disk. You are probably thinking that this is crazy because this will represent the XML of the EDI message body. For me this worked great because the EDI message body stayed intact even when the EDI global properties got applied. Then on a receive port you can use the XmlReceive pipeline to pull in the message text written out via PassThruTransmit, which is an XML version of the EDI message body. This identifies the root of the message and identifies that it is the XML version of the message. In essence this functions a lot like an EDI receive without needing to worry about the resolution of the ISA/GS headers to determine the namespace because the namespace is included on the root of the EDI-XML message. So to summarize the process of getting an EDI message body from an exposed AS2 endpoint when the EDI global properties get messed up, use the following pipeline pattern in your ports:
 
BTSHTTPReceive.dll –> (R) AS2EdiReceive / AS2Send –> (S with Filter) PassThruTransmit –> (R) XmlReceive
 
Good luck to everybody working with EDI in BizTalk. Its easy once you get the hang of it, but until then its usually bumps and bruises. 🙂
 
Thanks,
0

Some Tips on BizTalk AS2 Development

Here are a few tips I encountered when working on an AS2 and EDI project.
 
You will want to avoid using an EdiSend on the send side of a 2-way port in which the receive is As2EdiReceive because you will encounter EDI assembler errors where the SOAP messages are being run through the EDI assembler. Make sure to use just the As2Send on the send side of the receive port. The AS2 tutorial at http://technet.microsoft.com/en-us/library/bb245935.aspx mentions creating a 2-way port with As2EdiReceive/As2Send. This is the correct way of doing this.
 
When developing with EDI and AS2, you will eventually want to create a filter for receiving BizTalk NACKs that you may see with AS2 communications. You can create a send port filter using the filter property EDIInt.IsAs2Http200OKRresponse == true. This way if BizTalk does receive a NACK it will not log it as an error. This is a valuable tip for setting up an BizTalk environment for AS2 communications so that low-level AS2 message errors can be filtered out to a separate folder or location.
 
Thanks,
2

Tips for “The Signing Certificate has not been configured for the AS2 party”

Recently I have been working on an AS2/EDI project at a client and have been struggling for a few weeks with a certificate issue. The situation I was having trouble with is that I needed to send an AS2/EDI message through BizTalk and have it digitially signed as well as encrypted. I had already distributed a public key to my trading partner, it was just that when trying to send the message out via BizTalk I would receive the error:
A BTS MIME error was encountered when attempting to encode a message. Error: The Signing Certificate has not been configured for AS2 party. AS2-From: <From Value> AS2-To: <To Value>
Event ID: 8132
Overall, the MSDN documentation on this issue (http://msdn.microsoft.com/en-us/library/bb967848.aspx) is pretty limited, and in the documentation at the link it mentions that this error occurs with the “BizTalk Server 2006 EDI”, when in fact it also occurs with BizTalk Server 2006 R2 EDI. This is just one of the many misleading details that make this a difficult issue to overcome.
 
So the documentation mentions that you need to provide a certificate for the BizTalk group through the group properties under the Certificate tab. A big gotcha to know about this is that the certificate must have the private key included. The following image shows what you should expect to see when a certificate includes the private key – a grey key symbol and note at the bottom of the view certificate window:
 
Private Key Image-sm 
Depending on what adapters you are using with the certificate, you will also need to import this certificate to other certificate stores for other user accounts. The BizTalk environment I have been working with is a multi-machine install on a machine in a domain controlled by Active Directory. All of the BizTalk service accounts are domain accounts. What I had been doing for importing the certificates was that I created a custom MMC and then added all of the snap-ins for the different service accounts – one for the current user, one for the machine account, and then one each for the BizTalk AppHost and IsolatedHost accounts. One very important detail I did not understand about until today was that a service account’s certificate store was different when accessed from one user than another. So for example, I would login into the BizTalk Administrator account and add the Certificates snap-in for the BizTalk AppHost user (service account for the BizTalk Windows service and drop the certificates into the Personal store but I would still get the error.
 
Today I was looking at the following article – http://msdn.microsoft.com/en-us/library/aa559902.aspx#step5. This is the certificates setup step for the B2B solution. About halfway down the page you find a note that mentions you must login to the service account (interactively) in order to manage the certificates for this user. Usually service accounts do not have the right to logon interactively so this was something I kept overlooking. Once I enabled the BizTalk AppHost and IsolatedHost accounts the ability to login, and then I added the certificate to their personal certificates store I was able to get past the above message. The MMC snap-in framework perhaps disguises the fact that a certificate is not placed in the correct location for Personal certificates when logged in under a different user. The Certificates MMC makes it seem like you are adding a certificate to a shared storage location when in fact Personal certificates are more like an isolated, individual storage.
 
Another very important tip to know about is that you need to avoid enabling private key protection in the certificate with the private key or you will get additional error messages. Here are the messages I received when I did not disable private key protection:
A BTS MIME error was encountered when attempting to encode a message. Error: Exception of type ‘Microsoft.BizTalk.Component.MIMEException’ was thrown. HResult – 1061152225
The next error I saw in the logs was a little more helpful:
There was a failure executing the send pipeline: “Microsoft.BizTalk.EdiInt.DefaultPipelines.AS2EdiSend, Microsoft.BizTalk.Edi.EdiIntPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856as364e25” Source: “AS2 encoder” Send Port: <Send Port> URI: <HTTP Address> Reason: The MIME encoder failed to sign the message because the certificate has private key protection turned on or the private key does not exist.
Please disable private key protection to allow BizTalk to use a certificate for signing.
This message means that the certificate that was loaded in a couple of certificate stores is protecting the private key and is not allowing it to be used by BizTalk. When exporting, be sure that you do not check the box for “Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) as seen below:
 
export cert shot
 
Also, when importing, do not check the box for “Enable strong private key protection. You will be prompted every time the private key is used by an application if you enable this option” as seen below in the following shot:
 
import 2
 
So as you can see, there are many pitfalls along the way to configuring a certificate for use with BizTalk. These tips should help clear up some of the gaps in the documentation.
 
Thanks,
3

BizTalk AS2 and EDI error documentation

Today while working on debugging some AS2 and EDI message tests, I encountered an MSDN area that I realized needs to be more heavily documented. Whenever I encounter an error number or code in the event log I have to go to a search engine and look it up to find out more information on the error. Many times the error codes are documented on 3rd party websites where Administrators can punch in a hex value to determine the error category. Today I was trying to get to the bottom of an EDI error and found the following MSDN listing of AS2 and EDI error details: http://msdn.microsoft.com/en-us/library/bb968036.aspx. If you go to this link the article itself will not have any subarticles linked below it. You will need to use the table-of-contents on the left frame to see all of the subarticles, which represent all? of the different errors you might receive when doing AS2 and EDI processing in BizTalk. Each of the articles for the errors also suggests some possible resolution strategies, which is really helpful. I just wanted to pass along this information for anyone doing diagnostics on AS2 and EDI processing in BizTalk because this is helping me enormously.
0

Blog at WordPress.com.

Up ↑