Historically, deploying BizTalk Server solutions across environments is or can be a complicated process depending on how complex is your solution. There are many ways to deploy BizTalk artifacts for example:
Importing them as part of an application by using the Deployment Wizard (from a .msi file), importing them using BTSTask.exe – this is the default way to deploy across environments.
You can replace and use allow BTSTask, and PowerShell scripts.
Or deploy them from Visual Studio – this is the default way to deploy to your development environment.
Throughout the years, the BizTalk Server Community created an open-source deployment framework called Deployment Framework for BizTalk (BTDF) – https://github.com/BTDF/DeploymentFramework. The Deployment Framework for BizTalk is an easy-to-use toolkit for deploying and configuring your BizTalk solutions. In reality, BTDF is an MSBuild project with custom MSBuild tasks and it can be customizable according to customer BizTalk project needs, it is also extensible. This framework brings new capabilities and advantages to deploying BizTalk Server solutions, but it also has limitations or disadvantages.
Microsoft has introduced automated deployment of BizTalk Applications in BizTalk Server 2016 Feature Packs using Azure DevOps (previously called Visual Studio Team Services – VSTS). In BizTalk Server 2016 Feature Pack 1, automatic deployment and application lifecycle management (ALM) experience was introduced. The automatic deployment process has been improved with the release of BizTalk Server 2016 Feature Pack 2. These features were only available on the Enterprise edition of BizTalk Server 2016.
BizTalk Server 2020 brings all these functionalities out-of-the-box across all editions: Enterprise, Standard, Development, or Branch.
To accomplish this, we need basically 3 main steps:
BizTalk Server: Add a BizTalk Server Application project to your Visual Studio solution.
DevOps: Create a build agent.
DevOps: Create a Build and release Azure Pipeline.
This whitepaper will address and explain how you can implement CI/CD oriented to BizTalk Server using Azure DevOps Pipelines.
In this whitepaper, Pedro Almeida and I will provide a detailed introduction to CI/CD. It teaches how to Create a project collection. Learn how to prepare the visual studio for projects end to end. A well-defined pipeline. Helps you understand how to save development time by thinking long-term since it is a low-cost, high-return scenario.
What’s in store for you?
This whitepaper will give you a detailed understanding of the following:
An introduction to:
What is a CI/CD Pipeline?
What are CI/CD Pipelines?
What is Azure DevOps?
Create an organization or project collection in Azure DevOps
Create a project in Azure DevOps
Preparing your Visual Studio BizTalk Server project for CI/CD
Creating a BizTalk Server Deployment Project
Add the application project
Making your Bindings dynamic for deployment
Configure the BizTalkServerInventory JSON template
This time I decided to create a brand new component called the Message Archive Pipeline Component.
For those who aren’t familiar with it, the BizTalk Pipeline Components Extensions Utility Pack project is a set of custom pipeline components (libraries) with several custom pipeline components that can be used in receive and sent pipelines. Those pipeline components provide extensions of BizTalk’s out-of-the-box pipeline capabilities.
Message Archive Pipeline Component
The Message Archive Pipeline Component is a pipeline component that can be used to arch incoming/outgoing messages from any adapters into a local or shared folder. It is very identical and provides the same capabilities as the already existing BizTalk Server Local Archive pipeline component:
It can be used in any stage of a receive pipeline or send pipeline;
It can be used in multiple stages of a receive pipeline or send pipeline;
It provides an option for you to specify the location path for where you want to save the message: local folder, shared folder, network folder.
It can be used from any adapter:
If the adapter provides the ReceivedFileName property promoted like the File adapter or FTP adapter the component will take this value into consideration and save the message with the same name;
Otherwise, it will use the MessageID, saving the file with the MessageID has its name without extension.
So what are the differences between them?
The significant differences between these two components are that the Message Archive Pipeline Component allows you to:
Set the filename using macros like %datetime%, %ReceivePort%, %Day%, etc.
For example, %ReceivePort%_%MessageID%.xml
Set the archive file path once again using macros:
for example C:BizTalkPortsArchiveARCHIVE%Year%%Month%%Day%
If you don’t want to overwrite existing files, you can specify an additional Macro to distinguish them.
For example _%time%
You can set up this component for high performance using forward-only streaming best practices.
In short, this means developing your pipeline components so that they do their logic either as a custom stream implementation or by reacting to the events available to you through the Microsoft.BizTalk.Streaming.dll stream classes. Without ever keeping anything except the small stream buffer in Memory and without ever seeking the original stream. This is best practice from the perspective of resource utilization, both memory and processor cycles.
This is the list of properties that you can set up on the archive pipeline component:
Property Name
Description
Sample Values
OverwriteExistingFile
Define if the archive file is to be overwritten if already exists
true/false
ArchivingEnabled
Define if the archive capabilities are enabled or disabled
true/false
ArchiveFilePath
Archive folder path. You can use macros to dynamically define the path.
C:Archive%Year%%Month%%Day%
ArchiveFilenameMacro
File name template. If empty the source file name or MessageId will be used. You can use macros to dynamically define the filename.
%ReceivePort%_%MessageID%.xml
AdditionalMacroIfExists
If a file already exists and OverwriteExistingFile is set to false, a suffix can be added. If empty the MessageId will be used. You can use macros to dynamically define this suffix.
_%time%
OptimizeForPerformance
Setting to apply high performance on the archive
true/false
Available macros
This is the list of macros that you use on the archive pipeline component:
Property Name
Description
%datetime%
Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).
%MessageID%
Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.
%FileName%
Name of the file from which the File adapter read the message. The file name includes the extension and excludes the file path, for example, Sample.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value the MessageId will be used.
%FileNameWithoutExtension%
Same of the %FileName% but without extension.
%FileNameExtension%
Same of the %FileName% but in this case only the extension with a dot: .xml
%Day%
UTC Current day.
%Month%
UTC Current month.
%Year%
UTC Current year.
%time%
UTC time in the format hhmmss.
%ReceivePort%
Receive port name.
%ReceiveLocation%
Receive location name.
%SendPort%
Send port name.
%InboundTransportType%
Inbound Transport Type.
%InterchangeID%
InterchangeID.
How to install it
As always, you just need to add these DLLs on the Pipeline Components folder that in BizTalk Server 2020 is by default:
In this particular component, we need to have this DLL:
BizTalk.PipelineComponents.MessageArchive.dll
How to use it
Like all previous, to use the pipeline component, I recommend you to create a generic or several generic pipelines that can be reused by all your applications and add the Message Archive Pipeline Component in the stage you desire. The component can be used in a stage of the receive and send pipelines.
Download
THIS COMPONENT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download Message Archive Pipeline Component from GitHub here:
For those who are not familiar, this project is a set of custom pipeline components (libraries) with several custom pipeline components that can be used in received and sent pipelines, which will extend BizTalk’s out-of-the-box pipeline capabilities.
Receive Location Name Property Promotion Pipeline Component
Receive Location Name Property Promotion Pipeline Component is a simple pipeline component to promote the Receive Location Name (ReceiveLocationName) property to the context of the message. Several BizTalk Server context properties are not promoted by default with BizTalk Server, which means that they are not available for routing.
One such property is the ReceiveLocationName property. While the ReceivePortName property is available in the BTS namespace, the ReceiveLocationName property is not promoted. It cannot be used for routing nor access it from inside an orchestration.
My team and I kept that behavior creates this project as a proof-of-concept to explain how you can promote properties to the context of the message.
Create a Property schema
To promote properties to the context of the message, we will need a Property Schema with these properties. In our case, we will add only one property called: ReceiveLocationName.
Property Name
Date Type
Property Schema Base
ReceiveLocationName
xs:string
MessageContextPropertyBase
Note: A MessageContextPropertyBase property means that the XPath may or may not exist.
Create a Pipeline Component
To actually promote the properties to the context of the message, we need to create a pipeline component to do the trick.
Once you deploy the property schema and a receive pipeline component containing the Receive Location Name Property Promotion Pipeline Component, you can start to apply Content-based routing using the Receive Location Name.
Download
THIS COMPONENT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download Receive Location Name Property Promotion Pipeline Component from GitHub here:
For those who are pt familiar, this project is a set of custom pipeline components (libraries) with several custom pipeline components that can be used in received and sent pipelines, which will extend BizTalk’s out-of-the-box pipeline capabilities.
BizTalk PDF2Xml Pipeline Component
BizTalk PDF2Xml Pipeline Component is, as the name mentioned, a decode component that transforms the content of a PDF document to an XML message that BizTalk can understand and process. The component uses the itextsharp library to extract the PDF content. The original source code was available on the CodePlex (pdf2xmlbiztalk.codeplex.com). Still, I couldn’t validate who was the original creator. So, the component first transforms the PDF content to HTML, and then using an external XSLT, will apply a transformation to convert the HTML into a know XML document that BizTalk Server can process.
My team and I kept that behavior, but we extended this component and added the capability also to, by default, convert it to a well know XML without the need for you to use an XSTL transformation directly on the pipeline.
How does this component work?
This is the list of properties that you can set up on the PDF2XML pipeline component:
Property Name
Description
Sample Values
InternalProcessToHTML
Value to decide if you want the component to transform the PDF content to HTML or XML
True/False
IsToApplyTrasnformation
Value to decide if you want to apply a transformation on the pipeline component or not
True/False
XsltFilePath
Path to an XSLT transformation file
C:transfmymap.xslt
Once you pass the PDF by this component and depending on how you configure it, the outcome can be:
All PDF content in an HTML format;
All PDF content in an XML format;
Part of the PDF content on an XML format (if you apply a transformation)
Unfortunately, on my initial tests, this component works well with some PDF files, but others simply ignore its content. Nevertheless, I make it available as a prof-of-concept.
Download
THIS COMPONENT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download BizTalk PDF2Xml Pipeline Component from GitHub here:
Yesterday I spoke about how you can apply custom pattern restrictions to properly validate DateTime, Date, and Time formats inside elements or attributes. You can see more about it here:
And I mention that these Regular Expressions can be simple and relatively easier to read if you have some basic knowledge like this one below:
d{4}d{2}d{2} – that is a simple format that expects 4 digits followed by 2 additional digits and another 2 digits that is the date in the YYYYMMDD format without validating the accuracy of months or days and where:
YYYY is the for digits year, like 2022.
MM is the 2 digits month, like 01.
DD is the 2 digits day, like 21.
But it can get highly complex that even people with good knowledge have difficulty translating the expression to the expected pattern, like the one below:
It is not simple to look to this RegEx and say: “yep, we are expecting this Date format: MM/DD/YYYY like 12/11/1999, and by the way, it validates the Leap Year!”
Imagine users that don’t have strong know-how about RegEx!
So, what can we do to improve this experience? What are the best practices in these cases?
Best practices
A good best practice to improve readability while documenting your schemas is to add notes to these elements or attributes.
We can and should use the Notes property to enter notes, such as comments related to the business process, that you would like to make about the selected Record, Field Element, or Field Attribute node. In these DateTime, Date, and Time cases, we can simply add the expected format in the Notes property, like:
Format: YYYY-MM-DD
Format: HH:mm:ss
Format: YYYYMMDD
Format: HHmm
Format: YYYY-MM-DD – It validates Leap Year
To accomplish this, we need to
Right-click on the Element or Attribute fields in the schema tree view and select the Properties option.
On the Properties window, click on the … (three dots) on the Notes property. This action will open a Notes window where you can add all your relevant notes.
Do that to all your elements and fields that are using pattern restrictions.
Even non-technical guys can understand the Schema specification you provide or are consuming. This best practice implementation will also help you improve productivity since you will not spend too much time decompiling Regular Expressions.
Download
THIS SAMPLE CODE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download the POC: BizTalk Schemas Handle Restrictions on Date from GitHub here:
Today I was involved in a BizTalk Schema importation that includes not-so-used restrictions on Date and Time elements formats. And that gave me the idea and inspiration to create this blog post.
When we work with DateTime on Schemas by default we can choose from the following data types:
xs:dateTime: The dateTime data type is used to specify a date and a time in the following form “YYYY-MM-DDThh:mm:ss.fffK” where:
YYYY indicates the year
MM indicates the month
DD indicates the day
T indicates the start of the required time section
hh indicates the hour
mm indicates the minute
ss indicates the second
fff indicates the milliseconds
K represents the time zone information of a date and time value (e.g. +05:00)
xs:date: The date data type is used to specify a date in the following form “YYYY-MM-DD” where:
YYYY indicates the year
MM indicates the month
DD indicates the day
xs:time: The time data type is used to specify a time in the following form “hh:mm:ss.fffK” where:
hh indicates the hour
mm indicates the minute
ss indicates the second
fff indicates the milliseconds
K represents the time zone information of a date and time value (e.g. +05:00)
or you could use an xs:string that b.asically accepts everything. The only problem here is that by default we can’t do a schema validation to see if it is a valid DateTime format.
But not all systems respect de DateTime formats expected by the XSD default values. So, what are my options if a system expects other types of DateTime, Date, or Time formats? Like:
MM/DD/YYYY
YYYY-DD-MM
YYYY-MM-DD HH:mm:ss
YYYYMMDD
HHmmss
HH:mm:ss
and so on.
Simple Type Derivation Using the Restriction Mechanism
Luckily for us BizTalk Schema Editor and schemas, in general, allow us to derive a simple type, for example, xs:string, by using the restriction mechanism, i.e., we are typically restricting the values allowed in a message for that attribute or element value to a subset of those values allowed by the base simple type. A good and common sample of these types of restrictions is to restrict a string type to be one of several enumerated strings.
Luckily for us, again, we can also apply a pattern (that uses Regex expression) to validate the element or attribute value.
To derive a simple type by using restriction:
Select the relevant Field Element node or Field Attribute node in the schema tree
And then, in the Properties window, on the Derived By property set as Restriction.
This will add/present the Restriction properties on the Properties window.
On the Restriction properties, click on the … (3 dots) on the Pattern property to define the RegEx.
Regular expression samples to validate date formats
Here is where the fun starts. There are many ways to archive this goal:
One’s more simple but probably not that efficient since they may not validate all cases (Leap year, and so on)
Others more complex that requires more knowladge but more accurated.
In a general overview, the use of regex to validate the date format supports a variety of situations and possibilities like:
Rule to validate the year:
d{4} – it says that accepts 4 digits like: 2022
(19|20)[0-9][0-9] -accepts years starting with 19 or 20, i.e., from 1900 to 2099
Rule to validate the month:
d{2} – it says that accepts 2 digits like: 12, but the problem here is that also accepts invalid months like 24 or 99.
d{2} – it says that accepts 2 digits like: 12, but the problem here is that also accepts invalid days like 32 or 99. It also don’t validate what is the month we define to validate if accepts 28, 29, 30 or 31
0?[1-9]|[12][0-9]|3[01] – accepts 01-09 (leading zero), 1-9 (single digit), 10-19, 20-29 and 30-31. It doesn.t check if it is a Leap year or not.
To implement the lead year that needs to be with a concatenation of several rules like this sample:
As you saw above, things can go out of control and become quite complex. Fortunately, the BizTalk Schema Editor and the schemas, in general, allow us to apply multiple patterns to simplify the overall expression.
So, for example, if I want to have the following Date format: YYYYMMDD with Leap year validated I can use the combination of these 4 expressions:
(19|20)dd(0[1-9]|1[0-2])(0[1-9]|1[0-9]|2[0-8])
(19|20)([02468][048]|[13579][26])0229
(19|20)dd(0[13-9]|1[0-2])(29|30)
(19|20)dd(0[13578]|1[02])31
Some samples
Date in the following format: YYYY-MM-DD like 2022-12-11
Simple formats
d{4}-d{2}-d{2} – simple format without validating month or day
Wow… what a 2+ years journey. Writing a book during the pandemic phase and dealing with all aspects of the book was a challenger, and for that, I have to say thank you to Tom Canter and Lex Hegt for taking this journey with me and thank you Kovai and Saravana for supporting us!
I was also surprised that the book was released today because today was also the day I got back to the office and provided a copy of the book to my team! A lucky coincidence! Thanks, Pedro Almeida and Diogo Formosinho, for the support during these last years.
And of course, I have to say thanks to the people that also make part of this book: Mandi Anez Ohlinder for writing the foreword, Steve Lemkau, and JoAnn Een for reviewing it!
Migrating to BizTalk Server 2020
This book is intended to be a valuable resource for managers, architects, developers, testers, and administrators involved in migrating BizTalk Server platforms and solutions running on previous versions toward BizTalk Server 2020. It will provide practical recipes and strategies that will help them enhance and strengthen their knowledge in this sensitive and sometimes complicated upgrade process.
This book is a “mini” bible to migrate your BizTalk Server to the last version of the product covering all most aspects of this topic:
Overview of BizTalk Server 2020: will provide the reader with a full overview of BizTalk Server 2020, the latest version of the product, addressing topics like what are the main components and core features, what is new, what was deprecated or removed from this version and hardware and Software requirements & supported versions as well
Migration Drivers (why upgrade to BizTalk Server 2020): Many companies have this idea that upgrading to newer versions of BizTalk Server can be challenging, and they tend to skip certain version upgrades to minimize the effort and the costs. This chapter aims to address and discuss the main reasons why you should migrate from the previous version of the BizTalk Server to this latest version
Preparing for Your Upgrade: There are specific tasks, considerations, and components standard in each platform migration, but in the end, every BizTalk Server migration is different from each other. This chapter will go thru the Evaluate, Plan, and Implement (EPI) approach, providing you a path for completing your upgrade in a controlled and timely manner, focusing on the key considerations that need to be taken into account when planning your migration
In-place upgrade: Despite in-place migration or BizTalk Server upgrade is not supported in all scenarios, and in most cases, not recommended in production environments. It is still a valid option. This chapter will outline the key considerations that need to be taken into account when planning an in-place migration of your BizTalk Server environment
Migrating to BizTalk Server 2020 (side-by-side): Side-by-side migration is probably the most common migration path used. And once we decided on this approach, we need to understand and clarify all the steps that need to be performed to migrate from your previous BizTalk Server version to BizTalk Server 2020. his chapter will discuss the steps around setting up the new platform, making you aware of challenges that come with maintaining multiple (live) environments, and providing you will all the tips and recommendations for you to migrate your BizTalk solutions peacefully and transparently. After completing this chapter, you will be aware of and understand what will be involved in a migration process and the efforts required for each component
Migrating to Azure: This last chapter covers the key takeaways that you need to consider before deciding to migrate or move your on-premiss BizTalk Server machines to Azure Infrastructure as a Service (IaaS). When you can and can’t move, why you should move and what will be required. While not the focus of this book, this chapter will also briefly look at the BizTalk Server solution migration process to Azure Integration Services. Highlighting what will be possible or not, the difficulties you might encounter, and some approaches they could use to make this transition as simple as possible
Where can I order the book?
For now, the book is available for you can order the book online at Shopify here:
Finally, to my wife Fernanda and my children Leonor, Laura e José, my life would be empty and meaningless without all your hugs, jokes, crying to demand attention, affection, and all our other crazy things. Thanks for being part of my life.
At their core, mainframes are high-performance computers with large amounts of memory and processors that process billions of simple calculations and transactions in real-time. The mainframe is critical to commercial databases, transaction servers, and applications that require high resiliency, security, and agility
Microsoft Host Integration Server (HIS) technologies and tools enable enterprise organizations to integrate existing IBM host systems, programs, messages, and data with new Microsoft server applications.
HIS allows IT administrators to securely and efficiently connect new systems to existing systems using industry-standard High-Performance Routing (HPR) and Transmission Control Protocol (TCP) over Internet Protocol (IP). This reduces operating expenses and total cost of ownership while supporting existing and new computing workload.
HIS 2020 is available in one technology package licensed as additional software to the core editions of Microsoft BizTalk Server 2020.
This whitepaper will discuss a step-by-step guideline – how to install and configure Host Integration Server 2020 on a BizTalk Server standalone environment running Windows Server 2020.
What’s in store for you?
This whitepaper will give you a detailed understanding of the following:
Install Host Integration Server 2020
Configure Host Integration Server 2020
Install Host Integration Server 2020 Cumulative Updates
At their core, mainframes are high-performance computers with large amounts of memory and processors that process billions of simple calculations and transactions in real-time. The mainframe is critical to commercial databases, transaction servers, and applications that require high resiliency, security, and agility
Microsoft Host Integration Server (HIS) technologies and tools enable enterprise organizations to integrate existing IBM host systems, programs, messages, and data with new Microsoft server applications.
HIS allows IT administrators to securely and efficiently connect new systems to existing systems using industry-standard High-Performance Routing (HPR) and Transmission Control Protocol (TCP) over Internet Protocol (IP). This reduces operating expenses and total cost of ownership while supporting existing and new computing workload.
HIS 2016 is available in one technology package licensed as additional software to the core editions of Microsoft BizTalk Server 2016.
This whitepaper will discuss a step-by-step guideline – how to install and configure Host Integration Server 2016 on a BizTalk Server standalone environment running Windows Server 2016.
What’s in store for you?
This whitepaper will give you a detailed understanding of the following:
Install Host Integration Server 2016
Configure Host Integration Server 2016
Install Host Integration Server 2016 Cumulative Updates
We usually see two implementation cases when dealing with unwanted or obsolete messages:
They get suspended on BizTalk Server – not that common, at least in the long run. We may see this earlier when these types of messages are encountered.
or a common way to solve these situations is to create a send port to filter these types of messages and send them to a support folder in BizTalk Server hard drive or a shared location.
Of course, this last option should be considered as a backup plan that can work as intended if you have good control and clean best practices like creating a scheduling task that cleans these messages from the hard drive from time to time. Otherwise, your hard drive becomes full at some point, and more critical issues will arise.
BizTalk Server Void Adapter
The BizTalk Server Void adapter is a simple way to easily discard all unwanted messages from your BizTalk Server environments instead of getting suspended or sent to a hard drive support folder.
This custom send adapter for BizTalk Server discards outgoing messages – sends messages to nowhere – into the void! Without the need for external jobs (like scheduling tasks) or added cleaning concerns.
How to install it?
If you want to install the BizTalk Server FILE-RADITZ Adapter, you need to:
Place the folder BizTalkVoidAdapter on any location on your BizTalk Server box. I will recommend to put it in:
C:Program Files (x86)
Note: if you put in any other path you need to modify the VoidAdapter.reg file
Access the folder and double-click on the VoidAdapter.reg file
This will register the adapter to run under 32-bit host instances. To make it available also for 64-bits, you need to:
Click Start
Type %windir%SysWoW64cmd.exe in the search box and press enter
Run the same adapter registry (.reg) file from this command prompt
Now you just need to add this adapter to the BizTalk Server Administration Console:
Open BizTalk Administration Console by pressing the Windows key to switch to the Start menu, type BizTalk Server Administration or BizTalk, click the BizTalk Server Administration option from the Search window.
In the console left tree, expand BizTalk Server Administration > BizTalk Group > Platform Settings and then Adapters.
In the Adapter Properties
In the Name box, type a descriptive name for this adapter.
Void
In the Adapter combo box, select the adapter from the drop-down that you want to add.
Void
In the Description box, type a description for the adapter (this is optional).
The BizTalk Server Void adapter is a simple way to easily discard all unwanted messages from your BizTalk Server environments instead of getting suspended or sent to a hard drive support folder.
Click OK to complete the process of adding the adapter.
Note: If you want to use the Event Viewer to track/log the discarded messages you should first create the Log Name and Log Source. This way the tracking data will not be registered in the Application Log but instead in a custom log. To do that you can use the PowerShell provided on the runtime folder: mngt-Create-Event-Source.ps1.
Where can you use it?
This version available on GitHub is currently compiled on .NET 4.6 and optimized for BizTalk Server 2020. Nevertheless, you can take this code and compile it in other versions of .NET and BizTalk Server. It will be 100% compatible.
