03-10-2020 12:02 PM
03-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/
03-12-2020 12:22 AM - edited 03-12-2020 12:23 AM
03-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:
03-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?
03-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).
04-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.
04-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?
05-02-2020 01:07 AM
@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
05-06-2020 05:57 PM
Additional features capabilities in the Azure pipeline deployment task: Deploy BizTalk Application
05-08-2020 02:04 AM
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)
05-11-2020 01:47 AM
A bugfix for the mapper: when mapper extensions (aka functoids) got loaded, the mapper inspects the assemblies present in the Mapper Extensions directory. Upon loading an assembly, it tries to instantiate all classes which are derived from BaseFunctoid.
If there are intermediate classes which are not to be loaded as functoids an do not register themselves correctly, the mapper seizes to load any other class after that without showing any error message. This is an error situation difficult to analyze and solve. It would be advisable to have a proper error message here.
by WenJun_Zhang on April 10, 2020
by WenJun_Zhang on April 10, 2020
by ParikshitGupta on March 12, 2020
by ParikshitGupta on March 04, 2020