by Sandro Pereira | Jul 31, 2021 | BizTalk Community Blogs via Syndication
Recently while I was testing an integration solution on a client that uses a WCF-SAP adapter to receive an IDOC from the SAP system I got the following error:
The Messaging Engine failed to add a receive location “IN_IDOC_SAP” with URL “sap://CLIENT=003;LANG=EN;@a/ip-addres/00?ListenerGwHost=ip-address&ListenerGwServ=sapgw00&ListenerProgramId=name” to the adapter “WCF-SAP”. Reason: “Microsoft.ServiceModel.Channels.Common.ConnectionException: The parameter Program Id required for SAP Inbound Handler was not specified.
I knew I had this error in the past. Still, I couldn’t remember the reason immediately – this is one of the main reasons I often blog about the errors I face and solutions I found, my blog serves as my notes, and I’m one of the primary consumers of my blog.
Cause
Of course, and as always, there may be several reasons to face this problem, but in my case, the reason was quite simple.
If you pay attention to the URI on the error message and that highlight below:
- sap://CLIENT=003;LANG=EN;@a/ip-addres/00?ListenerGwHost=ip-address&ListenerGwServ=sapgw00&ListenerProgramId=name
You will see that we are using the ampersand as an HTML entity (&) and we cannot in this case we need to use only the character &.
Solution
To solve this issue, you need to fix the URI to use the character &, instead of the HTML entity (&):
- sap://CLIENT=003;LANG=EN;@a/ip-addres/00?ListenerGwHost=ip-address&ListenerGwServ=sapgw00&ListenerProgramId=name
The post WCF-SAP Adapter error: The parameter Program Id required for SAP Inbound Handler was not specified appeared first on SANDRO PEREIRA BIZTALK BLOG.
by Sandro Pereira | Jul 23, 2021 | BizTalk Community Blogs via Syndication
BizTalk Server leverages the Enterprise Single Sign-On (SSO) capabilities for securely storing critical information such as secure configuration properties (for example, the proxy user ID, and proxy password) for the BizTalk adapters. Therefore, the BizTalk Server requires SSO to work properly.
But it also can keep your own application configuration data in the SSO database, let say the usual configurations that we normally keep in a configuration file (“app.config”)). Unfortunately, there is no command-line tool to allow you to script the deployment SSO Application Configurations or perform CI/CD thru DevOps.
BizTalk Server SSO Application Configuration CLI
BizTalk Server SSO Application Configuration CLI is a command-line tool that provides the ability to import SSO configuration applications – key-value pairs in the SSO database – that can be deployed to different environments. This way enables you to script these tasks.
This tool is designed to address this gap allowing you to:
- You can securely import Application configurations by using this CLI application;
And it mandatory accepts 5 arguments:
- Path: full path to the .sso file
- Password: password to unencrypted the .sso file
- Contact Info: Internal field that is normally in the format of an email that is used internally in SSO tables for Application Configurations
- Application User Account: SSO Affiliate Administrators Group or the Group that will access (read) key.values, for example: BizTalk Application Users.
- Application Admin Account: SSO Administrator Group – Administrators of the Enterprise Single Sign-On (SSO) service.
Download
THIS TOOL IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download BizTalk Server SSO Application Configuration Tool from GitHub here:
The post BizTalk Server SSO Application Configuration CLI Tool for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.
by Sandro Pereira | Jul 21, 2021 | BizTalk Community Blogs via Syndication
This is a so common task on BizTalk Server that I already forgot how many times I did it. Depending on several scenarios, like:
- Testing
- Certain parts of the application are not yet ready to production
- Or even discarded unwanted messages
We want/need to create a send port and subscribe specific messages to be discarded on a folder. Otherwise, they will get stuck on the administration console, and we don’t want that.
After a while, the problem is that the folder will get a considerable amount of messages, and writing a large number of files to disk will get progressively slower as the number of files in the target directory gets large. This is because your computer’s operating system must keep track of all files in a directory. Even bulk deleting all of these files will take a longer time. Moving or deleting files from the target directory on a regular basis will ensure that the performance is not adversely affected.
A large number of small files make more impact than a small number of large files, and most of the time, BizTalk Server consumes/produces small messages. However, at some point, you may completely fill the hard drive, which is more critical.
With this script, you can easily configure the folders and the type of files you want to monitor and delete.
Get-ChildItem -Path C:Temp -Include *.* -File -Recurse | foreach { $_.Delete()}
This will help BizTalk Administrators to take full control of their environments
Download
THIS POWERSHELL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download Delete Discarted messages from local folders PowerShell script from GitHub here:
The post Delete discarded messages from local folders using PowerShell appeared first on SANDRO PEREIRA BIZTALK BLOG.
by Sandro Pereira | Jul 16, 2021 | BizTalk Community Blogs via Syndication
Patrick Wellink, a long-time BizTalk Server consultant from the Netherlands, asked me to broadcast this news. I’m happy to do it because I know that many of you use and like BizTalk Deployment Framework (BTDF) to perform deployment across your environments.
Patrick suppresses a need by developing a Visual Studio 2019 plugin (VSIX) for BizTalk Server 2020. Of course, there was already a new version of The BTDF Framework. But one of the convenient things was the visual studio plugin… that was missing.
Unfortunately, and I understand this feeling entirely because I also have several community projects, we always have to for the owner and developer to upgrade his project, and we usually struggle to find the time. So I take this opportunity to encourage all community members to start contributing to these initiatives as Patrick did. Start performing changes and submit your contributions to the repo. I speak for myself, and from what I know from the community, we accept the changes and are happy that you contribute.
And it wasn’t that difficult, rephrasing Patrick:
With some guidance of this post and some fiddeling I got the VSIX to work for VS2019. After some more fiddeling I got the project wizard to run as well.
I did so with minimal effort.
Where I can download it
You can download the Visual Studio 2019 plugin (VSIX) for BizTalk Server 2020 here:
The post BizTalk Deployment Framework (BTDF) Visual Studio plugin for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.
by Sandro Pereira | Jul 15, 2021 | BizTalk Community Blogs via Syndication
Surprisingly enough, or not, legacy systems can still be found across many organizations. IBM MQ is a family of message-oriented middleware products that IBM launched in December 1993. It was called MQSeries initially and was renamed WebSphere MQ in 2002 to join the suite of WebSphere products. In April 2014, it was renamed to IBM MQ.
We can mainly see the use and the need for integration with these products in banks systems. BizTalk Server provides two ways to communicate with IBM MQ:
- By using the MQSeries built-in adapter that will act as a bridge between Microsoft BizTalk Server and IBM MQSeries servers:
- The MQSeries adapter is available with the BizTalk Server installation. It supports transactional and non-transactional messaging by setting the Transaction Supported property in the MQSeries adapter transport properties
- The MQSeries adapter uses the MQSAgent2 COM+ application to put/get messages into the IBM WebSphere Queue Manager
- The MQSeries adapter requires IBM’s MQSeries Server for Windows to reside on the client system to communicate with an IBM WebSphere Queue Manager running on Windows or non-Windows. MQSeries Server for Windows is not a Microsoft product and must be obtained from your IBM WebSphere MQ program
- By using the Host Integration Server (HIS) that provides a WCF Channel for MQ and BizTalk Adapter for MQ Series Client (MQSC) — depending on the version of BizTalk Server you are using that will support a variety of IBM WebSphere versions:
This whitepaper’s goal is not how to install and configure MQSeries, neither compare the advantages or disadvantages of using this adapter compared to MQSC. Instead, this whitepaper’s focus is on improving the performance of the MQSeries adapter to better support low latency scenarios that most of the time are required in financial transactions.
Where I can download it
You can download the whitepaper here:
You can also find, download and enjoy several other free whitepapers of my own here:
The post BizTalk Server 2016: How to configure the MQ Series Adapter for low latency scenarios whitepaper appeared first on SANDRO PEREIRA BIZTALK BLOG.
by Sandro Pereira | Jul 12, 2021 | BizTalk Community Blogs via Syndication
Recently I wrote my version of a script that Mike Stephenson initially created: Find Orphaned Azure API Connectors with PowerShell. This PowerShell script will look at all of the API Connections in a specific resource group and then inspect every Logic App in your resource group to check if the API Connections are being used or not. The goal of this script, of course, is to identify orphaned API Connections in a single Resource Group quickly and effectively.
I modify the original script to have a better output or at least a different output that works better for my needs. Automatically add a Deprecated tag on all the API Connectors with the value True or False. And add additional capabilities on the generation of the output report in a CSV format.
The only limitation of this script is that it only checks a specific Resource Group. So, if you have 3 or 4 Resources Groups, you need to configure this script and run it 3 or 4 times.
To streamline this process and not waste so much time, I decided to create a new version of this script. This new script will look at all the API Connections in all resource groups on a single Azure Subscription and then inspect every Logic App in that specific Resource Group (RG) to check if the API Connections of that RG are being used or not.
What’s new on this PowerShell script:
- It will check in all Resources Groups available on a single Subscription if API Connections are being used or not.
- Subscription Details output is improved and with coloring to better read
- List of available API Connectors group by Resource Group output is improved and with coloring to better read
- List of Logic Apps and API Connectors association group by Resource Group and Logic App output is improved and with coloring to better read
- List of Orphaned API Connectors order by Resource Group output is improved and with coloring to better read
Download
THIS POWERSHELL SCRIPT IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download Find Orphaned API Connectors in all Resource Groups from GitHub here:
The post Find Orphaned Azure API Connectors in all Resource Groups with PowerShell appeared first on SANDRO PEREIRA BIZTALK BLOG.
by community-syndication | Jul 8, 2021 | BizTalk Community Blogs via Syndication
Following Sandros last post on BizTalk Server: Automation Deployment with Azure DevOps – Create a build agent, we’re going to show how to create the deployment steps, by creating the Pipeline and Release Pipeline, using a few DevOps tasks.
The standard BizTalk Deployment task does a decent job in deploying the application, but it doesn’t handle changing tokens or registering DLLs in GAC.
To deploy in multiple machines or to change your Bindings according to your environment, you have to make your file dynamic. This means, replacing your connections with variables.
Let’s start with the basic:
Creating the project and installing it in DEV
As always, it’s better to first create the DevOps repository and clone it in your machine.
Having this created, you need to get your project working and have a Deployment Project as well. This will contain the needed DLLs and Binding files pointers to your BTS project. This will also contain the Application name to be deployed and some other configurations.
You will see that you can set the Biztalk Assemblies path as well as other Assemblies, Pre and Post processing scripts and the Deployment Sequence. This is one of the most important steps, because, as you know, it does matter in which order you deploy your BT Assemblies.
When referencing your BT projects, do make sure that the Application Project is using the same framework version as your other projects. If it’s not the same version, it will not be able to copy the DLLs to the referenced Path and will not build successfully.
Building this project will generate a ZIP file that contains all that is needed. You can try to publish it directly, after configuring the application.
The bindings file that is created with the project is just an empty template, so you’ll want to deploy your application in your Dev Environment and create those bindings. It will make a difference if you export your application bindings when it’s started and when it’s stopped, so keep that in mind.
For this example, I’m going to export the bindings with the Application fully stopped.
Your standard Bindings export will carry the ports and URIs/connections straight from the Admin console. Through a little magic, we will configure these values to be dynamic and it’s super easy.
Making your Bindings dynamic for deployment
Now you’ve exported the bindings and you want to make it ready for DevOps and to accept multiple configurations.
From my example, you can see that the ReceiveLocation and ReceivePort names are static. If we tokenize this, you can call it whatever you want, therefore reducing the risk of colliding with other existing ports in your end systems.
So, keeping in mind the desired token, I’m going to replace these values, ReceiveLocation address included, with a variable and token identifier. With a few magic touches, we end up with something like this:
And that’s it. Of course, this is a very small and simple example, but even with a goliath project, it will still be the same pattern. You find what you want to make dynamic, tokenize it, save and upload your changes to your Repo.
Building your Pipeline and Release Pipeline
Now you have your source code in your Repository, your bindings ready for dynamic changes and you want to deploy it.
You will need to set up your build Pipeline before you can get your Release ready, so get to work.
The Pipeline itself doesn’t need to be too complicated, you just need to build your Solution, with or without the OutPath argument (I found that setting this would make my life easier in some projects) and publish the drop.
With your drop created, your Release pipeline needs the following tasks:
- Extract Files – to unzip your file
- Replace Tokens (a great extension by Guillaume Rouchon, more info here)
- Archive Files – to zip it back
- BizTalk Server Application Deployment – I recommend this, but you can do it with PowerShell
Extracting your file contents is straight forward, you just need to select your zip in your drop contents and a destination folder. Keep in mind that you will need to know where it lands, to zip it back.
Replacing the Tokens is just as before, you select the *.XML mask or point directly to your bindings and select the Token that it should be looking for. Remember, that the variables you define are case sensitive. You can also use a Variable Group, it is a great way of knowing your environment specific variables or common variables that your might have.
Once this is done, you can proceed to recreate the Zip file and it’s contents. The destination folder you’ve selected when Unzipping will now be the Root folder you are pointing to.
Remember to tick out the “Prepend root folder name to archive paths” option. If you keep this selected, your file will end up with a structure like “Zip / bindings” instead of just “bindings” and the deployment will fail, because it’s not the expected folder structure. Also, tick the “Replace existing archive” option, else you will create a copy and deploy the original version instead.
And for the final step, the Deployment Task. I chose to use the standard task instead of PowerShell, because I didn’t want to handle scripts at this point.
Select the Zip package and set the operation to Create. From what I’ve found out, this will Upsert your application, while Update will not create the app if it doesn’t exist.
And this is what you need. If you’ve set everything properly, your Release Pipeline will deploy your Application to your Server and get it up and running, with the parameters you’ve set in your bindings file.
It took a while to understand how this process worked but in the end, it turned out to be very simple and all it took was to apply the same concept we already used with the ARM deployment for Azure resources.
Happy coding!
The post BizTalk Server: Automation Deployment with Azure DevOps – Deploying the Project appeared first on SANDRO PEREIRA BIZTALK BLOG.
Open Source – Microsoft makes it easier to build scalable platforms
