Forum Discussion
MicrosoftBizTalk Server 2020 CU1
We are actively planning content for CU1 for BizTalk Server 2020. If there is anything you like product group to consider for this, please add to this conversation.
39 Replies
Azure DevOps BizTalk Server task. Please add Operations:
- Undeploy Biztalk App (full undeploy according to https://docs.microsoft.com/en-us/biztalk/core/undeploying-biztalk-applications)
ElvisShiWe are trying to understand this request, from my understanding, the most frequently used operation is updating your application because your have create new receive/send ports, or your BizTalk assemblies need upgrade. Please explain your scenario, and help us to understand why you need an undeployment task in DevOps?
Additional features capabilities in the Azure pipeline deployment task: Deploy BizTalk Application
- Expose Application Stop options so that instead of StopAll you can choose to remove StopReferencedApplications and use value 31 (StopAll minus StopReferencedApplications = 31).
We had to use PowerShell to remove app references prior to this task, and in some cases change pipelines on receive locations and send ports to a default pass-through. That ought not be required. The interim MSI produced becomes useless because these app references and proper pipelines are missing. - Expose Application Start options for the final re-start allowing the selection of all ApplicationStartOption Enum
The implemented usage of StartAll is not appropriate for all deployment situations in environments. - Allow disabling of the creation of the automatic file share for MSI file
- Add support for on-premise Azure DevOps Server, not just Azure DevOps Services
- In an effort to support automated recovery using YAML "on: failure:" when this BizTalkApplicationDeploy@2 task fails, provide a means of securely capturing and storing the original bindings with passwords and other secure values present to be available when restoring under failure. That binding would need to be available only during the YAML deployment job and then automatically be wiped away. Perhaps this can be done with a separate deployment task that is specialized to support roll back.
- Expose Application Stop options so that instead of StopAll you can choose to remove StopReferencedApplications and use value 31 (StopAll minus StopReferencedApplications = 31).
SanjivGupta I have had some integration scenarios with low latency requirements and that would require leveraging orchestrations for synchronous, multi-system, idempotent integrations. In these particular cases, the additional persistence points conducted by the orchestration engine are unnecessary and adds a latency overhead. Even when using an atomic scope to contain multiple logical send ports and other triggering shapes which minimizes the persistence points but does not eliminate it.
I know that this a core feature that is built into the engine and that it is related to dehydration and other state management functionalities; but is it possible to have an orchestration-level setting that would completely prevent the orchestration engine from taking any state persistence points for the above-mentioned scenarios that can tolerate not having orchestration state persistence?
AhmedmmTaha please take a look at my old blog entries for BizTalk Server v2004 - v2009. I believe that they remain relevant for BizTalk Server v2020
https://docs.microsoft.com/en-us/archive/blogs/quocbui/biztalk-patterns-the-parallel-shape
https://docs.microsoft.com/en-us/archive/blogs/appfabriccat/biztalk-patterns-part-2sync-async
SanjivGupta It's not possible to build a Biztalk project within a hosted agent from Azure DevOps pipelines. it will be nice to add Biztalk Build targets in the build VMs.
SanjivGupta It would be nice to have Send Ports retry interval in seconds rather than minutes, which would be suitable for quickly recovering from transient errors in request-response integration scenarios.
Generics support from within the Orchestration engine. Being able to call Function<MyType>() would be extremely helpful.
I wanted to set up App Insights in BizTalk Group Settings.
After logging in I received the following error message.
It happened because the default subscription that got selected was my Visual Studio Professional Subscription.
I did not have an App Insights set up at that time.
After setting one up the error stopped showing up and I was able to select an App Insights from my company's subscription.
SanjivGupta Fix RosettaNet Accelerator. They are still using the old SQL Adapter and we need to manually recreate ports to put it working in BizTalk Server 2020.
SanjivGupta, I've previously posted about setting ContentType for outbound messages using SB-messaging - please consider this for CU1 since the problem remains in BTS2020.
The SB-Messaging adapter does not offer a default value for ContentType to be specified on a send port. If you encode the outbound message using the JsonEncoder pipeline component the adapter will set ContentType to "application/xml; charset=utf-8".
I've tried to add the value via promoting context properties for the adapter schema "http://schemas.microsoft.com/BizTalk/2012/Adapter/BrokeredMessage-properties" but the MessageInspector does not honor the ContentType property - it does handle all other properties offered via the send port configuration.
I've also tried a custom version of the JsonEncoder component with the addition of specifying ContentType and Charset on the body part but that doesn't work either.
Why can't we specify what the ContentType should be for an outbound SB message? This metadata has no impact whatsoever on the BTS send operation but it has an impact for the receivers (fetching messages from a queue) since they have to ignore the standard ContentType value.
As far as I can understand this is either a bug in the implementation where the ContentType value is not assigned according to the context property or it has something to do with the serializer used by the WcfTransmitter.
Looking at the Microsoft.BizTalk.Adapter.SBMessaging.SBMessageInspector.BeforeSendRequest the ContentType is missing both from the default value assignment (which is logical since it's not available on the send port properties) and the iteration of context properties (which I suspect is a bug).
/andreas
And you know what, whilst I'm here posting out-landish ideas.
- An option to allow administrators (maybe via a database level flag) to export bindings with passwords
- A method of overriding/ignoring dependency restrictions when deploying (providing unenlisted). With complex dependencies, it can often be infuriating to have to clear up all instances and remove dozens of applications to release an updated common pipeline.
- An entirely programmatic alternative to an Orchestration (e.g. via a .net interface, like pipelines). Along with my previous comment about testing, this is attractive as it is more modular with conventional development tools.
- I've not even tried to explore this subject, but how well does BTS play with docker and kubernates, something for the future?
ParikshitGuptaAbout overriding dependency restrictions when deploying, please describe few simple examples from your BizTalk environment. Specific details will help us understand your pain point, like what is there in the BizTalk Assembly being redeployed, what artifacts and dependency among them, state of the service instances, what change in the Assembly is being redeployed, and what is stopping (error) the re-deployment.
If you try and overwrite any BizTalk assembly artefact with the same assembly version number that has a reference to it, you will be blocked by the Administration console. This happens both at the code level, and at the configuration level.
Configuration Level
If you create a project with a Pipeline and deploy that into Application1, and then reference that from Application2 and utilise the pipeline in a Receive Location/Send Port in Application2, you will be blocked from updating the assembly in Application1. Even if you, as the administrator, know that there are no (or no breaking) changes to the assembly being updated.
This happens due to a constraint in the database, e.g pipelines are a good example, but not the only cause:
The DELETE statement conflicted with the REFERENCE constraint "bts_sendport_foreign_sendpipelineid". The conflict occurred in database "BizTalkMgmtDb", table "dbo.bts_sendport", column 'nSendPipelineID'.This will happen if you deploy via Visual Studio, btstask, or import via an MSI. The only way to handle this currently is to remove the reference from other applications, either by changing the bindings, or removing the application completely. Whilst this sort-of makes sense when the application is enlisted, it feels unnecessary when unenlisted (and given that assemblies are loaded into an AppDomain, I'm not sure being able to do with when things are enlisted should be blocked either).
Desired behaviour here (for me) would be to have the import process handle the swapping out of components and only present a fatal error and rollback if that configuration would not be applicable after the import is completed, or that a currently active/started component is referencing it.
Development/assembly level
The issue also presents itself with compile-time references between BizTalk assemblies.
If you have a schema in a resource in Application1, and then reference that from another project/assembly (e.g. as you might do with a common schema and map to something more specific elsewhere), then you can no longer deploy Application1 without first completely removing any referencing applications completely from BizTalk (or, deploying all assemblies in the same transaction, which is not easily done if you are talking about multiple applications).
e.g.
Cannot update assembly "BtsDependency1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9143bb74dd62198d" because it is used by assemblies which are not in the set of assemblies to update. To update the assembly, remove the following assemblies: BtsDependency2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9143bb74dd62198d (mscorlib)The desired behaviour here is to only present a fatal error if the assembly is being removed and not overwritten.
I'm not sure the purpose of the existing constraint, as it does not protect against changes in the base assembly breaking any referring assemblies; all it does is add an irritating step which requires shutting down of applications to drop in patches to BizTalk artefacts.
Note on versioned DLLs
In my experience, it's fairly common to stick with a single assembly version for BizTalk assemblies. I appreciate that it is possible to workaround some of the above slightly by having different version numbers and running concurrent versions, this introduces another world of pain, not just in managing binding files, but also in managing class references inside referring applications. Multiple versions of a messagetype can also cause runtime errors.
e.g. If you use Advanced Functoids to reference other assemblies these need to be manually updated to pick up new versions. If you use custom XSLT functions, these need to have the XML files manually updated. None of these steps are build-server/CI friendly making the process of building a new version unfavourable.
Loose coupling
Given that BTS is frequently used to loosely couple services, these constraints are very tight. Being able to late-bind/loosely couple within BizTalk itself is sorely needed.
Thanks,
Alastair
