One of the great new additions of the recently released Feature Pack 1 for Microsoft BizTalk 2016 is a REST API, which can be used to administer BizTalk Server. Longtime users of BizTalk may have experience with using ExplorerOM.dll or WMI based scripts to manage their BizTalk environment. The REST API introduced in Feature Pack 1 provides a more flexible alternative, including a Swagger definition providing rapid implementation of an application to consume the API. In this post, I will walk through the process of installing the API as well as using Swagger to generate a C# client and demonstrating a simple command.
We heavily use the BizTalk Deployment Framework to aid in the deployment of simple to complex BizTalk solutions. One of the greatest benefits is the ability to run custom deployment tasks and scripts. In previous blogs we have shown how to run a custom post deployment scripts in BTDF, today, we will show how custom scripts can be used to conditionally import a binding file during BTDF deployment.
I have often run into the same errors in my time developing BizTalk HL7 applications to interface with various HL7 EHR systems. These errors stem from using out of the box BizTalk maps to transform HL7 messages using the Microsoft BizTalk Accelerator for HL7. Here are two of the errors that I have come across that others might have too…
Dell Boomi’s AtomSphere integration platform provides a simple, yet very powerful feature – the ability to utilize temporary, and semi-temporary files system folders. Coming from a Microsoft BizTalk integration background, the ability to store documents to a temporary directory is a huge advantage over storing into a database such as the BizTalk MessageBox, especially with larger files. While BizTalk does provide the necessary mechanism to save files to a local folder through the use of the file adapter, Boomi provides an easier way of achieving this.
The Tallan Integration Practice heavily utilizes Azure Infrastructure as a Service (IaaS) virtual machines for quickly setting up isolated environments for prototypes and BizTalk development environments. However, with so many virtual machines it is often difficult to remember to shut them off when not needed. With Azure’s Automation features, we can setup a scheduled job to shut down non mission critical VM’s, saving on hosting costs.
BizTalk is great in its ability to store messages within the MessageBox even after processing failure, however its not always so easy to get those messages back out! I recently had a need to retrieve all messages that were currently suspended due to validation failures while attempting to generate X12 EDI messages using the Microsoft.Practices.ESB.
Recently, while troubleshooting performance issues at a client, I came across a peculiar issue. The environment in question was a multi- server environment with multiple BizTalk Servers (2010) connected to a SQL Server cluster. The issue was extremely slow performance when trying to view, refresh, start or stop the host instances through the Administration Console. Now usually it takes a few seconds for host instances to start, stop, or restart, however, in this case just refreshing the status of the host instances was taking over a minute.
The problem was that one of the BizTalk Servers in the group was offline for some time, causing the host instances tied to that BizTalk Server, within the same group, to become unresponsive. This caused slowdown in viewing the host instances for any of the other servers in the BizTalk Group.
There are two ways to resolve this:
1. Turn on…
While building BizTalk projects within Visual Studio, it is possible to receiving the following error when trying to compile a project with multiple orchestrations:
“The namespace ‘[namespace]’ already contains a definition for ‘_MODULE_PROXY_’”
While the error seems obvious, in my case, the namespaces were indeed unique, such that the above error did not make much sense. The underlying issue was in fact that the type names of two of the orchestrations within the project were identical. It turns out that an orchestration was at one point duplicated, and only the namespace was changed. After making the type names unique, the project successfully compiled and deployed.
Learn how T-Connect EDI technology can improve 5010 processing performance in Microsoft BizTalk Server 2016 for your organization.
There are a few common deployment errors in Microsoft Visual Studio when redeploying a previously deployed BizTalk project.
“Failed to add resource(s). Change requests failed for some resource. BizTalkAssemblyResourceManager failed to complete end type change request. Failed to update binding information. Cannot update receive port “”. Transform “” not found”
A quick tip today – I came across an error while trying to enlist one of my send ports while deploying a BizTalk application using the amazing BizTalk Deployment Framework.
“Could not enlist Send Port ‘X’. Exception from HRESULT: 0xC00CE557 (Microsoft.BizTalk.SnapIn.Framework)