Yes, I know that in my last post, I told you that it was the previous blog post from Thomas Canter that I was revitalizing. Still, last week, while I was relaxing in my car waiting for my wife to get out of the pool, I received an email titled: Are you interested in more old blogs? Hell yes! was my prompt response… So, here it goes, another Thomas Canter old and still very updated blog post: The New VirtualStream in BizTalk Server 2006.
I bet you are all drooling over the new VirtualStream support in BizTalk Server 2006 (once again, valid for any version of BizTalk Server, including 2020). With this, you can access a forward-read-only stream as if it were a fully implemented stream with backward and forward access to the data.
The VirtualStream is implemented in the undocumented APIs but is also exposed in the SDK as VirtualStream.cs, so I feel pretty safe in using the deployed version.
But, the use of the VirtualStream is not what this is about. This is about the security implications of the VirtualStream. The VS supports a disk caching scheme to store large streams…
As such, this means that the stream size in the cache can be quite large, and you _generally_ don’t have to worry about it, but in fact, you do because this can fail subtly and unexpectedly.
Two things can go wrong in this scenario.
Understand that the stream is cached to the BizTalk Server Host Instance account’s %TEMP% folder, generally under:
C:Documents and SettingsLocal SettingsTemp
The first problem I see here is that the C: drive is NOT a good place to put large files that grow unexpectedly. The IO performance is poor, and in addition, you could exhaust the drive space unexpectedly. So, I recommend manually setting the BizTalk Host Instance’s TEMP folder to a separate drive, preferably a non-backed-up high-speed disk.
Ok, so now you have the TEMP folder set to a separate drive, the second problem that could occur is that the BizTalk Host Instance account may not have Read-Write access to that folder. When the account is logged on the first time, the OS builds the account’s local folder structure and gives it the correct access, but you need to manually set this when you manually set the TEMP folder location.
So:
Try to move the TEMP folder of the BizTalk Host Instance account to a large and non-OS used drive.
Make sure that the BizTalk Host Instance account has full control of the folder.
That’s it! Then you won’t get surprising failures in your pipeline when processing large files.
Thanks Tom for sending me this interesting stuff!
Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego!
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.
He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira
Sometimes I have the need to have a Logic App (LA) disabled when I deploy it. For instance, when deploying to Production, I like to have my LAs disabled, because I want to double check everything before starting the process.
This is helpful because usually, when using the “Recurrence” trigger, the LA will start immediately. If for some reason, a connector has the wrong configuration or is broken or the end system is offline, the execution will fail. Other scenarios can happen as well, but that’s another story.
An interesting fact is that you don’t have a proper way to control this in the Portal. You can add the control line to the code, but you won’t be able to control it with CI CD.
So, in comes Rocket science (or not).
The resource code contains a property that will allow you to control the state of a LA and it’s quite easy to set. If you do not specify this property, the LA will start enabled and will trigger if it can.
The property is called “state” and lies within the “properties” node. Setting this property as a global parameter, allows you to prepare your CI/CD pipeline also allowing to parameterize this in your release.
This is quite and easy and simple insert, that should take no more than 5 minutes for you to configure.
If you choose the “Disabled” state, the LA will not start unless you specifically activate it.
BizTalk Server 2020 – 20 days, 20 posts – day 11. Following my recent blog posts here is another pipeline component migrate to BizTalk Server 2020 that makes part of my BizTalk Pipeline Components Extensions UtilityPack project: Zip File Pipeline Component.
Zip File Pipeline Component
The Zip File Pipeline Component is a pipeline component for BizTalk Server which can be used in a send pipeline (encode stage) and is intended to compress (zip/gzip) outgoing messages.
The capabilities are similar to those available in compression software such as WinZip or 7-zip.
No compression/decompression software needs to be installed in the BizTalk Server machines.
To use this pipeline component in your projects you just copy the BizTalk.PipelineComponents.ZipFile.dll file into the Pipeline Components folder that exists in BizTalk Server Installation directory: “..Program Files (x86)Microsoft BizTalk ServerPipeline Components” on every server.
You do not need to add a custom pipeline component to be used by the BizTalk Runtime to the Global Assembly Cache (GAC).
This component requires two configurations that are:
the FileExtension: where you can specify if you want for example a .zip or .gz file.
and Enabled: that is a true or false value to activate the compression.
What is BizTalk Pipeline Components Extensions Utility Pack?
BizTalk Pipeline Components Extensions Utility Pack is a set of custom pipeline components (libraries) with several custom pipeline components that can be used in received and sent pipelines, which will provide an extension of BizTalk out-of-the-box pipeline capabilities.
At the beginning of this week I ask on twitter what should be the topic of my next blog posts: BizTalk Server and JSON support or Azure Logic Apps. And the majority of the replies was: BizTalk Server and better JSON support.
For that reason, I will respect my reader’s decision and I will be releasing today a new addition to my BizTalk Pipeline Components Extensions Utility Pack community project for BizTalk Server 2016: Custom JSON Encoder Pipeline Component.
You may be asking yourself: this component already exists by default in BizTalk Server 2016, so why we need another?
Yes, Microsoft provides out-of-the-box a JSON Encoder to transform the XML messages into a JSON message and sends it out. But, unfortunately, in some cases, it doesn’t work as you should expect to work and it will fail, in my case with this error:
Reason: Value cannot be null. Parameter name: key
And in reality what I just want is a simple way, that, I hope, it would work for all scenarios (aka XML messages) in a simple and effective way.
JSON Encoder Pipeline Component
The Custom JSON Encoder is a pipeline component for BizTalk Server which can be used in a Send Pipeline (Encode stage) to encode any XML message into a JSON equivalent in a simple and effective way.
Because I would like to have a choice between using the default pipeline component provide by Microsoft, at least the internal behavior, this pipeline component is an extension of the default JSON Encoder pipeline component and fully compatible with it and you will be able from the BizTalk Administration console you will be able to decide if:
You want to use
the behavior of the default JSON Encoder pipeline component provide by
Microsoft by setting the UseCustomEncoder property to False;
or use the custom
behavior to generate the JSON message by setting the UseCustomEncoder property
to True;
What is BizTalk Pipeline Components
Extensions Utility Pack?
BizTalk Pipeline Components Extensions Utility Pack is a set of custom pipeline
components (libraries) with several custom pipeline components that can be used
in received and sent pipelines, which will provide an extension of BizTalk
out-of-the-box pipeline capabilities.
And once again, BizTalk Pipeline Components Extensions Utility Pack community project for BizTalk Server 2016 got a new update. A new component that you can use in your custom BizTalk Server Send pipelines is now available: Zip Pipeline Component.
Zip Pipeline Component
The Zip Pipeline Component is a pipeline component for BizTalk Server which can be used in a send pipeline (encode stage) and is intended to compress (zip/gzip) outgoing messages.
The capabilities are similar to those available in compression software such as WinZip or 7-zip:
This component requires two configurations that are:
the “FileExtension” where you can specify if you want for example a .zip or .gz file.
and “Enabled” that is a true or false value to activate the compression.
No compression/decompression software needs to be installed in the BizTalk Server machines.
This was an old component that I had that I now updated and improved to BizTalk Server 2016 with the help with my internal team at DevScope, in special, Pedro Almeida.
To use this pipeline component in your projects you just copy the “BizTalk.PipelineComponents.ZipFile.dll” file into “Pipeline Components“ folder that exists in BizTalk Server Installation directory: “..Program Files (x86)Microsoft BizTalk Server <version>Pipeline Components” on every server.
You do not need to add a custom pipeline component to be used by the BizTalk Runtime to the Global Assembly Cache (GAC).
What is BizTalk Pipeline Components Extensions Utility Pack?
BizTalk Pipeline Components Extensions Utility Pack is a set of custom pipeline components (libraries) with several custom pipeline components that can be used in received and sent pipelines, which will provide an extension of BizTalk out-of-the-box pipeline capabilities.
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
In the sequence of one of my last blog posts, I notice that in the same project also while trying to open a BizTalk pipeline inside Visual Studio, again, normally a simple and easy double-click operation to open this time the BizTalk Pipeline Editor, the resource didn’t open with the correct editor: BizTalk Pipeline Editor, instead, it opened with the XML (Text) Editor
I’m used to seeing this behavior ins orchestration but it is the first time, that I can remember, to see the same happening with pipelines. Again, this has a quick workaround but it becomes annoying after a few times.
Cause
Well, again and similar to the orchestrations, I don’t know exactly what can cause this problem but I suspect that this behavior happens more often when we migrate projects, or when we try to open previous BizTalk Server versions projects in recent versions of Visual Studio, special if we skip one or more versions, for example: from BizTalk Server 2010 to 2013 R2.
And may happen because of different configurations inside the structure of the “<BizTalk>.btproj” file.
The cause of this strange behavior is without a doubt related to a mismatched setting inside the structure of the “<BizTalk>.btproj” file in the Pipeline nodes (each pipeline inside your project will reflect one Pipeline node specifying the name of the file, type name, and namespace. Normally it has this aspect in recent versions of BizTalk Server:
When the SubType element is present, this strange behavior of automatically open the pipeline with the XML (Text) Editor.
Solution
First, once again let’s describe the easy workaround for this annoying problem/behavior:
On the solution explorer, right-click on the pipeline name and then select “Open With…” option
On the “Open with …” window, select “BizTalk Pipeline Editor” option and click “OK”.
Once again, this will force Visual Studio to actually open the pipeline with the Pipeline Editor. But again, this will be a simple workaround because next time you try to open the pipeline inside Visual Studio it will open again with the XML (Text) Editor.
Similar to the orchestration behavior, force to “Set as Default” inside the “Open with …” window:
Select “BizTalk Pipeline Editor” option, click “Set as Default”
And then click “OK”.
It will not solve the problem, once again, if you notice in the picture above it is actually already configured as the default viewer.
So, to actually solve once and for all this annoying behavior, once again you need to adjust the configurations inside the btproj file, by:
Open the “<BizTalk>.btproj” (or project) file(s) that contain the pipeline(s) with this behavior with Notepad, Notepad++ or other text editors of your preference.
Remove the <SubType>Designer</SubType> line
Save the file and reload the project inside Visual Studio
If you then try to open the pipeline it will now open with the BizTalk Pipeline Editor.
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.
He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
