BizTalk Server 2016/Visual Studio 2015 - Pipeline Component Wizard Update

Hello BizTalk Techies,

This is an update to the BizTalk Server Pipeline Component Wizard to work for BizTalk Server 2016 in Visual Studio 2015. Original version from the Codeplex supports only till BizTalk Server 2010 in Visual Studio 2010. This is an community effort to improve development efforts.

For more details of description and download link please visit below URL,


The hard Purge interval cannot be less than the soft purge interval

On one of the BizTalk env(non prod) there arouse a space crunch scenario which was call for purging the data from BizTalk tracking database(DTA DB).(dtasp_BackupAndPurgeTrackingDatabase is not configured on this env)

So do that, we decided to purge/delete only those instance which are completed and are older than 30 days and incomplete instances of only past day.

Note: No archiving was needed so instead of dtasp_BackupAndPurgeTrackingDatabase we used dtasp_PurgeTrackingDatabase

Thus the parameters set were:
@nHours tinyint(Any completed instance) :0
@nDays tinyint(Any completed instance) : 30
@nHardDays tinyint(Any including incomplete instance): 1
@dtLastBackup(Set this to GetUTCDate() to purge data): CurrentDateTime

And when started the job, it failed at second step and to check the reason went through history and found the error as below

The error says that 3rd parameter should be greater than 2nd parameter -- for me it is still puzzling and will try to get it understood by product team. But to proceed with purging went ahead and changed the parameters

And started the job and waiting for some time the job was successfully executed

Note: Even now the database size remain same -- here we have to select the DB and Shrink it. This actually forces to release the unused space from DB and as can be seen from below snap - around 20 GB data was purged.

Original Post: http://tech-findings.blogspot.in/2017/01/the-hard-purge-interval-cannot-be-less.html


How to check what BizTalk Server 2016 Cumulative Updates are installed in your Servers with PowerShell

Information about all installed BizTalk Cumulative Updates on the Server (see here). 
Now it is time to update this script to BizTalk Server 2016.

Checking what CU are installed it is not a difficult task to do, but without a doubt it is one of the most annoying task to do as an administrator because, and once again:
  • You can do it manually by checking "Control Panel\Programs\Programs and Features" and then view the "Installed Updates", try find them in the list can be sometimes very confuse because they are not organized in a category BizTalk;
  • Or rely in tools like BizTalk MsgBoxViewer, which sometimes are not up to date, to check and provide that information;

Probably there are other ways, nevertheless, this simple task should be simple, extremely easy and fast to do, what you really want to know is what are the BizTalk Cumulative Updates installed like:
This is the list of BizTalk Cumulative Update installed in this machine: BTS2016LAB01
- Microsoft BizTalk Server 2016 CU1
To check if the last Cumulative is installed or not.

PowerShell script overview

So how can we easily automate tasks? and reuse them whenever necessary and at the same time saving significant time for other tasks?

Using PowerShell is a good option. Windows PowerShell is a Windows command-line shell designed especially for system administrators and can be used by BizTalk administrators to help them in automating repetitive tasks or tasks that are time consuming to perform manually.

This is a simple script that allows you to configure the template name of the cumulative updates, that will change from version to version, and will give you the list of all BizTalk Server 2016 cumulative updates installed in your server:
$keyResults = Get-ChildItem -path HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ -Recurse -ErrorAction SilentlyContinue | where { $_.Name -match $CUNameTemplate}
foreach($keyItem in $keyResults)
    if ($keyItem.GetValue("DisplayName") -like "*$CUNameTemplate*")
        write-host "-" $keyItem.GetValue("DisplayName").ToString().Substring(0,$keyItem.GetValue("DisplayName").ToString().IndexOf(" CU")+4)


Download: Check what BizTalk Server 2016 Cumulative Updates are installed with PowerShell

Original Post: https://sandroaspbiztalkblog.wordpress.com/2017/02/03/how-to-check-what-biztalk-server-2016-cumulative-updates-are-installed-in-your-servers-with-powershell/


7 Lessons learnt from the first production Azure Logic Apps project

Article posted by Stephen Thomas on BizTalk 360 Blog.

For starters, I need to start out saying I am very new to working with Windows Azure Logic Apps; so a lot of the issues we faced were just from lack of experience. That said, since it is a relatively new technology, most people are going to be new to it as well.

In general, the experience was straight forward and we were able to build an Enterprise class EDI solution in a short amount of time at a huge cost saving as compared to a new BizTalk Server installation. For clients who already have BizTalk up and running, the cost savings would not be as significant.

Overall, the Azure Logic Apps platform is fantastic. It gives great details into current and the past running instances with complete auditing on a per-shape basis. We were able to track down issues very quickly using all the tools provided. The monitoring features are extensive.

Dev-Ops is challenging

The big trade off at this point comes in terms of Dev-Ops. While the Dev-Ops side of Azure Logic Apps is getting better all the time, it takes a change in thinking that is not going to work for every organization. When you look at traditional on-premises solutions, they generally have a rigid build and deployment process.

For Logic Apps, things are a little more free-flowing. To start with, you have two designer options. The Web Designer or Visual Studio.
  • The Web Designer rocks and makes Logic App creation super simple but migration and source control is challenging
  • The Visual Studio designer gives you both easy migration and adding to source control at the cost of being the web designer and semi-clunky.

Deciding what works best for you will take balancing between these features and the amount of time you want to spend filling the gaps. I’m confident you could build a robust deployment process around the Web Designer using PowerShell giving the right amount of time.

For us, it was not being able to easily change URL and SQL connections that made us go with Visual Studio.

Of course, if you are ok with needing to make these changes manually or don’t have a lot of them, the Web Designer could be the best option.

Key Lessons Learned

Below I summarized my key lessons learned from my first production Logic App project. This was for a smaller client with a very small Logic App implementation.

#1: Reacting to major workflow changes was easy and quick
We got an undocumented requirement after we went live that we needed to send separate EDI files for each location. We were able to re-work the Logic Apps in less than a day to accomplish this.

#2: For serious stuff, build your Logic App inside Visual Studio
Why? This seemed the simplest way to ensure the files are checked into source control and we can deploy to any region we wanted. Plus we took the time to create custom parameters for per-environment variables like web URLs and SQL Connections.

Using the web designer, you can clone, change resource groups, and change subscriptions but not sure how to easily change regions. Based on that, using Visual Studio seemed to give the most flexibility with the least effort.

#3: Working with the Visual Studio Designer : ensure the following
  • If using an Integration Account, assign it right away.
  • Always complete your shapes once you start them even if you just put in “foo”’.
  • Always save (and do the two points above) before switching to code view (if you switch to code view and back, sometimes uncompleted shapes disappear).
  • Do not panic when you are not able to get back from code view to the designer view; it will tell what needs to be fixed.
  • If you have more than one Logic App project in a solution when you do a deployment ensure the Resource Group setting are correct plus confirm the results in the output windows. We saw cases that one project would deploy another. If you run into issues, clear All from the list of deployments then close and re-open Visual Studio.

#4: Pick a region and stay with it
In general, moving between regions seemed to cause some complexity. The web designer does not seem to support it at all and using Visual Studio seemed to work most of the time. If you deploy to a new region using Visual Studio, you need to open and save the Logic App using the Web Designer to get the internal APIs to update to the new region.

#5: Working with SQL Azure
  • Returning output parameters of XML seem to not be supported.
  • Doing a For-Each around a ResultSet seemed great – until the ResultSet returned no records. So we had to do a pre-check on the Count using a different procedure. This could have just been our ignorance in working with SQL in Azure.

#6: Brush up on your JSON skills
I found a lot of cases that I had to manually edit the JSON file. Some cases included parsing stored procedure out parameters and changing the RunAfter parameter for exception handling.

#7: Working with retry and exception handling
Logic Apps have powerful retry and exception handling options, but in most cases needs to be done manually inside the JSON file.

Original Post: http://blogs.biztalk360.com/7-lessons-learnt-first-production-azure-logic-apps-project/