Last week Microsoft released a new version of BizTalk, and they’ve added some exciting new features. A comprehensive list of changes has been provided by Microsoft here, but we’ll take a closer look at a few of the changes in the admin console which make life a lot easier for BizTalk users.
If there’s one problem that an integration system needs to address, it’s standardizing the format of all data being exchanged. Before any type of data can be processed or transformed, the system handling it must be aware of its format and structure. Using a service, at the client endpoint, forces the user to provide proper data that is agreed upon. This acts as a contract between the service and the client. Given a certain format of data, the client will receive another format of data in return. Anything that happens behind the curtain is the responsibility of the service; the client simply waits for the returned data set.
BizTalk WCF Service Publishing Wizard
One of the more popular tools offered by BizTalk 2010 is the WCF Service Publishing Wizard. This handy tool can automatically create a WCF service, and fully configures the…
SWIFT – or the Society for Worldwide Interbank Financial Telecommunication – is the main global provider for secure messaging in financial transactions. The standard they created and currently maintain is utilized by hundreds of banks throughout the world. Today we’re going to go through a quick tutorial for getting set up with A4SWIFT, BizTalk’s SWIFT messaging accelerator for speeding up integration with this platform.
Today marks the release of Microsoft BizTalk Server 2016. This is an important milestone that not only reinforces strong on-premises application integration capabilities, but also provides flexibility and control to our customers to adopt cloud applications as and when it makes sense for the business. Microsoft realizes that every company is undergoing digital transformation with the proliferation of applications, data and services. Whether your applications run in the cloud or on-premises, you should have the flexibility to seamlessly connect applications, unlock data and automate business process anywhere.
Earlier this year, Microsoft shared their commitment to build a comprehensive hybrid integration platform. Today, Microsoft is the only vendor that provides a truly hybrid integration platform, offering a consistent experience to our customers and partners whether they are looking to connect on-premises or cloud-native applications. This consistent experience is enabled through Microsoft BizTalk…
On the provider side of healthcare integration, HL7 (particularly v2) is a critical message type to understand. While it is standardized and heavily used by various EHRs/EMRs, it’s used in slightly different ways. There are efforts to further standardize and normalize its use across the board (such as with v3/FHIR), many EHRs and EMRs continue to use 2.x messages. Common HL7 messages include admissions/transfer/discharge (ADT), scheduling (SIU), lab orders and results (ORU, ORM), and medical reports (MDM). Choosing the right HL7 or EDI Software platform can be challenging.
Some of the challenges of HL7 2.x messages include:
The ability to add non-standard custom segments or additional data anywhere in the message (whether they are completely custom “Z Segments” or other segments that aren’t typically part of the message, such as IN1 segments in an ADT message to include additional insurance information).
A myriad of…
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.
Recently while working on a Biztalk project there was a number of suspended instances that were appearing in the Biztalk Admin Console, after some investigation in to the cause of these suspended instances it was determined that the orchestrations were failing because of uncaught exceptions being thrown from within the orchestration’s exception handlers.
The cause of these uncaught exceptions was eventually tracked down to the following line of code inside of a message construction shape.
To give a little bit of context to the code snippet above, the xmlExceptionMsg object is an orchestration variable of type System.Xml.XmlDocument which is being used to construct a BizTalk message and the LoadXml method is meant to take a string of text which is valid Xml from which that message will be built.
However, it was this method call that was raising the exception that subsequently caused…
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…
On one of our Dell Boomi projects we had a simple task which was to create an XML profile by importing an XSD file that was generated using BizTalk‘s schema generator. While this task seemed trivial at the time, when importing the file that was provided the following error was generated: “Error Occurred: Error on line 1: Content is not allowed in prolog.”
Tom Babiec wrote a great blog a few months back on inserting multiple parent child tables in a single stored procedure. We use this technique a lot in our data integration work, and it’s proven to be very robust in many contexts. The SQL procedure outlined in that blog is useful not just for BizTalk, but generally speaking for ADO.NET and other applications trying to load multiple rows into SQL Server for multiple parent child tables. However, when dealing with larger datasets (and as the table grows), we’ve noticed some degradation in performance. In some cases, we were seeing variances of 30 seconds to 10+ minutes for loading the same exact data set on the same database. We tried a few different options, including forcing a recompile of the stored procedure between each load
, but this did not solve…