Mar 10 2020 12:02 PM
Mar 12 2020 12:18 AM
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/
Mar 12 2020 12:22 AM - edited Mar 12 2020 12:23 AM
Mar 12 2020 03:57 PM
When you do a Test Map, it looks like SAXON error are not being captured and show in the Visual Studio Output Windows:
Mar 23 2020 02:03 AM
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?
Mar 24 2020 02:43 AM
@Sanjiv380, 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).
Apr 15 2020 04:01 PM
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.
Apr 27 2020 08:24 AM
@Sanjiv380 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?