BizTalk Server 2020 CU1

Microsoft

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

@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 

 

Additional features capabilities in the Azure pipeline deployment task: Deploy BizTalk Application

 

  1. 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.
  2.  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.
  3. Allow disabling of the creation of the automatic file share for MSI file
  4. Add support for on-premise Azure DevOps Server, not just Azure DevOps Services
  5. 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.

@SanjivGupta 

 

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)

@SanjivGupta 

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

@SanjivGupta When configuring BizTalk Server 2020 on a named instance with EDI support, the receive locations are not correctly configured on the EDI Application:

 

EDI Wrong URI.PNG

 

This should be mssql://server/instance/biztalkmgmtdb?

 

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

 

 

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

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

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

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

 

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

 

 

@DijkgraafC 

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. 

@SanjivGupta 

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?

@SanjivGupta 

Do we know when we should expect CU1 to be released?

This issue is holding our upgrade effort and delaying the project.

 

Alex.

@SanjivGupta Apparently it was not a BizTalk SAP bug as such but an issue with CU4 for SQL 2019, which is fixed in CU5

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. 

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

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

@Alastair Grant 

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.

@ParikshitGupta

 

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