Mar 10 2020 12:02 PM
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.
May 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
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
May 06 2020 05:57 PM
Additional features capabilities in the Azure pipeline deployment task: Deploy BizTalk Application
May 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)
May 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.
Thanks, regards
Jörg Fischer
Jun 24 2020 09:27 AM
@SanjivGupta When configuring BizTalk Server 2020 on a named instance with EDI support, the receive locations are not correctly configured on the EDI Application:
This should be mssql://server/instance/biztalkmgmtdb?
Jun 24 2020 09:30 AM
@SanjivGupta When you configure BizTalk Server 2020 with a gMSA for Isolated Host Instance, you cannot use that account when configuring the ESB Toolkit. This seems to be both undocumented and unsupported.
Jul 08 2020 11:01 PM - edited Jul 08 2020 11:02 PM
@SanjivGupta 'Deploy BizTalk Application' task in Azure DevOps is not flexible. It is using variables that need to be in Azure DevOps (in pipeline or remote git repository).
I would like to edit variables as .yml (multiple), build solution, publish .zip + .yml with variables as artifacts to some location and us it later in deploy task.
Please provide field with path to local .yml file with variables.
Jul 09 2020 06:02 AM
@Michał Aniśko I agree, the usage of Variable Groups is cumbersome because the editing experience is awful. They do not even offer and export/import capability.
@SanjivGupta Along these lines, if Azure DevOps offered a convenient easy editing experience with search and replace, I would find that workable. In our current project we will end up with 600 Variable Groups with 15 to 40 variables in each group. We have a Variable Group for each target application and each of 4 environments.
Jul 09 2020 07:23 AM
Hi @SanjivGupta ,
it will helpfull to add a design time property on shapes to enable start/end tracking. Now we can only enable this tracking on orchestration level, so for all the shapes. I was facing a use case with one of my clients to track some services response time (so only the related send/response shapes) from Biztalk Tracking.
many thanks,
Hichamveo
Jul 15 2020 02:53 PM
@SanjivGupta There looks to be a bit of a bug highlighted in this thread SAP / BizTalk 2020 issue
The following stored procedure call failed: " { call [dbo].[bts_FindSubscriptions]( ?)}". SQL Server returned error string: "The statement has been terminated.;The conversion of the nvarchar value '20200714213319' overflowed an int column.".
Jul 15 2020 03:00 PM
@SanjivGupta How about a bug that has been around since BizTalk 2006? If you change the TargetCharset value in a Flat File Assembler pipeline via the BizTalk Administration console it does not change the outgoing payload to that encoding. You have to change it in Visual Studio, compile and re-deploy.
I've listed that an various other bugs on my blog BizTalk 2013 R2 known bugs, issues & quirks, I've noted where these are fixed in 2020 in the blog.
Jul 15 2020 03:28 PM
In Response to:
There looks to be a bit of a bug highlighted in this thread SAP / BizTalk 2020 issue
Yes, we have identified a few miss in SAP adapter in 2020 RTM release. They are on track to make it in soon to be released CU1.
Jul 16 2020 12:50 AM
Support for async Task helper methods. More and more libraries are Async to the bottom, so a supported entry point to these methods would be a help. Could this also provide a throughput advantage?
Jul 16 2020 05:45 AM
Do we know when we should expect CU1 to be released?
This issue is holding our upgrade effort and delaying the project.
Alex.
Jul 19 2020 07:54 PM
@SanjivGupta Apparently it was not a BizTalk SAP bug as such but an issue with CU4 for SQL 2019, which is fixed in CU5
Jul 20 2020 04:32 PM
Thank you all for a great response here.
As you all know, the CU releases are specifically bug fixes that our customers uncover while working with the product. In that light, many of the long pending wish lists and improvements did not meet the bar for a CU. However, we are very happy to note the community interest in those capabilities still.
We have closed the content for CU1 of BizTalk 2020 release and are going through the engineering rigor necessary for the release.
Several items reported here made to CU1 and some are under work for CU2. I will soon publish a list of fixes and improvements that made to CU1. From now onward, we are not taking any more inputs for CU1.
I will open another discussion for CU2 when we are ready. Please keep in mind the bar for something to be addressed in CUs when responding.
Once again, BizTalk Server PG team thank you all for great participation.
Sep 17 2020 12:05 AM
Hi,
We`ve installed the CU1 for BTS2020, after that during uploading Oracle procedure output strong typed cursor as a schema in VS2019 Generated items we received error
An error has occurred while retrieving the properties for the selected operation. Retrieval of Operation Metadata has failed while building WSDL at 'http://Microsoft.LobServices.OracleDB/2007/03/......
Do you know what did go wrong?
We use Oracle Client 18.3, BizTalk 2020 CU1, VS2019 extensions 3.13.2.0
Sep 29 2020 11:18 AM
Oct 22 2020 03:15 PM
About 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.
Oct 23 2020 06:51 AM
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