BizTalk Server 2020 CU1

[SanjivGupta]

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. 

[#2]

I was surprised that the application restriction was not removed in this version.

[#3]

Hi

there is some problems where you try to delete a BizTalk Application with reference to another application by BizTalk Administration Console and/or command line . Sometime show an error that is impossible to do that. See my next blog for workaround https://www.enricozerilli.com/l/delete-biztalk-application-frol-biztalk-mng-db/

Best regards

@SanjivGupta 

[#4]

Add polling interval feature on ASB Adapter. On the fly message consumption is risky and can create a high traffic on Biztalk MessageBox

[#5]

Remove the 5 applications limit in Standard Edition, as promised in BizTalk vNext.

[#6]

@leoerlandsson 

This is a business decision, not a bug. We may not be able to handle such a request in a CU scope. Being familiar with BizTalk, I am sure you are aware of the limitations we have for CU. 

I thank you for your response. 

[#7]

@Enrico2103 

We will look into it. 

I thank you for your response.

[#8]

@hichamveo hichamveo 

We will look into it. 

Just to be sure, please clarify ASB for me.

[#9]

ASB: Azure Service Bus (SB-Messaging connector)

[#10]

@SanjivGupta 

When you do a Test Map, it looks like SAXON error are not being captured and show in the Visual Studio Output Windows: 

https://social.msdn.microsoft.com/Forums/en-US/4b901a71-0637-430e

-9be9-2a043c73e0df/biztalk-2020-visual-studio-2019-bug-report-with-xslt-30?forum=biztalkgeneral

Thanks,
Neal Walters 

[#11]

@NealWalters Noted!

Will look into it. 

[#12]

@SanjivGupta 

A little bit large "out there" but a method of unit-testing orchestrations individually from a test-framework etc.

Windows Admin Centre support

[#13]

@SanjivGupta 

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?

[#14]

@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

[#15]

@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.

[#16]

@SanjivGupta 

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.

[#17]

@SanjivGupta 

Generics support from within the Orchestration engine.  Being able to call Function<MyType>() would be extremely helpful.

[#18]

@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. 

[#19]

@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.

[#20]

@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?