Archive for October, 2008

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,
 

, , ,

Leave a comment

Another BizTalk/PeopleSoft Integration Option

As I am wrapping up my BizTalk EDI project I also wanted to mention that this project has incorporated a nontraditional integration option between BizTalk and PeopleSoft. Microsoft provides the BizTalk Enterprise Adapter Pack which includes the PeopleSoft adapter. This provides a way to integrate between BizTalk and PeopleSoft and provides a handy way for extracting the message schemas of the different services exposed by PeopleSoft via the Compontent Interfaces. These days PeopleSoft itself has its own EDI integration platform as well as the ability to interact with the Filesystem and so there are various layers of infrastructure within PeopleSoft that you can choose to integrate over.
 
On my project it was possible to map PeopleSoft flat-file formats to EDI message types and exchange the files over the network and then out to the VAN. So rather than work directly with PeopleSoft, the solution was to work across a file system, receiving PeopleSoft flat files and transforming them to EDI and then on receipt of EDI messages, transforming them into PeopleSoft flat file acknowledgements. In my opinion this was a less difficult implementation option than the use of the PeopleSoft adapter because you did not need to configure a Java environment or install a PeopleSoft component interface. Next I will give some details of the PeopleSoft flat-file format to give you a little more information about how involved the mapping was in this solution.
 
The PeopleSoft flat file format was based on 3 groups of positional lines, the first group always has one line for each transaction (multiple in a batch), then the second group has n lines below the first group and the third group has m lines below the second group. The first group is tagged with 000A, the second group with 100A and the third with 200A. So for basic EDI messages this nesting of groups corresponded pretty well with the traditional PO1, N1, and SCH loops. Unfortunately the message format in PeopleSoft is configurable in the PeopleSoft administrator website and it is possible to add or remove columns very easily so it is possible that a message format could be changed and result in a disruption of the BizTalk application that uses the messages. 
 
The benefit of using the PeopleSoft adapter is that you have a sure reference for the generation of the message types. This was by far the largest challenge of the project; knowing the format details for the PeopleSoft adapter is not documented that well and is variable based on the message type configuration. But if you do not have the security option to install a custom component interface for the PeopleSoft adapter or have other difficulties getting the PeopleSoft adapter to work, this post has provided you with yet another option for integration.
 
Thanks, 

, ,

Leave a comment

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,

, , ,

Leave a comment

Role Link Deployment Issue and Workaround

On my most recent project I am employing send port role links as a way to route messages within BizTalk for test and production EDI trading partners. This is one way to use a single orchestration for handling multiple trading partners (BizTalk parties). So in my orchestration instead of simply having a send port, I have a role link that contains a send port. Since the project’s deployment simply consists of a single server I am deploying directly from Visual Studio. During a recent round of changes I encountered an error that was consistently blocking deployment from Visual Studio. This error is given below:
 
Failed to update binding information.
Could not validate TransportTypeData, Address or Public Address properties for Receive Location <Receive Location Name>. Retrieving the COM class factory for component with CLSID {CFF09884-6582-49C2-A74F-0FD85849281E} failed due to the following error: 8007045a.
 
Another variation of this error is:
Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Failed to update binding information. Could not validate TransportTypeData, Address or Public Address properties for Receive Location <Receive Location Name>. Retrieving the COM class factory for component with CLSID {CFF09884-6582-49C2-A74F-0FD85849281E} failed due to the following error: 8007045a. 
These errors occur when trying to redeploy over BizTalk applications that use role links with send or receive ports. These deployments from Visual Studio have been attempted with the deployed BizTalk applications in both the enlisted/started and unenlisted/stopped states. I have found that these errors occur for me on more than one BizTalk development system, on both Windows XP and Windows Server 2003 systems, both running BizTalk Server 2006 R2. I was able to determine a modified deployment process to enable deployment to be successful in these scenarios. Here are the steps I came up with in order to successfully deploy a project with role links which is my workaround for the errors above:
 
  1. Build/rebuild in Visual Studio in the build configuration you want to deploy under.
  2. Stop the BizTalk application you want to deploy to.
  3. Export the latest bindings for the BizTalk application. This will include information about all of the send and receive ports and role links. You may want to check to include the global party information in a separate file for an exhaustive binding backup.
  4. Unconfigure the receive ports by right-clicking on the BizTalk application and clicking “Configure…”. I would specify <None> for the receive port bindings. Leave the role links completely configured and do not worry about removing the send ports from the BizTalk parties.
  5. Delete the receive ports from the BizTalk application.
  6. Deploy from Visual Studio
  7. Reimport the bindings that you exported in step 3.
  8. Make sure everything looks correct in the Configure window. The bindings should be rebound successfully.
  9. Start the BizTalk application again.
This is a mysterious problem that was not solved by rebuilding or cleaning my BizTalk solution. At this point it may be a BizTalk deployment bug. The benefit of the workaround is that you do not need to unconfigure the role links themselves or modify the send ports specified for each party. With one role link you could have many configured parties so this workaround could save you a significant amount of time during deployment.
 
Thanks,

, ,

1 Comment

Now a BizTalk MVP!

I am very excited to say that I was recognized as a Microsoft MVP (http://mvp.support.microsoft.com/) for BizTalk today. I was nominated for this award for my contributions on the MSDN forums. This is a huge honor for me. I am glad to be a member of the BizTalk and Connected Systems communities and look forward to the new opportunities that this award will bring.
 
Thanks,

1 Comment