If you didn’t read Understanding Application Deployment, be sure to view the archive. This explains the new features in BizTalk Server 2006 which assist with Application Deployment.
Now that you understand how to get applications deployed and running in production, at some point they’ll probably need to be upgraded. Perhaps a partner’s schema will change so your schema and map will have to be changed accordingly. Or maybe the business will require a new auditing API to be called during one part of the business process’s execution. And for as good as our BizTalk developers are, there are always code defects in application code that will need to be fixed.
So how does BizTalk Server accommodate these upgrades? Well, there are a couple of different ways to upgrade your running applications, and as always, different points to consider.
Simple Upgrade
One scenario we’ll deem the “Simple Upgrade Scenario”. This scenario requires no downtime, requires no code changes, and can be performed by an IT Pro or Business Analyst (BA) single-handedly.
Some examples include:
- An additional partner requests access to all orders of a certain type
- A business rule changes
- A queried web server will be phased out and replaced with a new one
Changes in this scenario are typically as simple as adding an additional send port to a send port group, adding an additional send port with appropriate subscription filters, changing the URI of a send port, updating a rule in the BRE, et cetera.
However, there may be more involved cases of application upgrade.
Patching Scenario
One such scenario is called the “Patching Scenario” in which existing application binaries in production must be edited and swapped with updated ones.
Typical examples include:
- Patching an orchestration with a code change
- Changing a schema
- Updating a map
In this case, the customer scenario must meet the following conditions:
- System downtime can be scheduled for application upgrade
- Customer does not have long-running business processes
- Dehydrated or suspended instances can be quickly resumed and completed, or alternately terminated
If the customer is updating an orchestration, say, and meets these criteria, the following steps might be their typical marching orders. First, the application binaries will be updated and recompiled with name and version unchanged. Then, downtime must be scheduled and new instances should be prevented from starting up. During this period, running instances will have to be stopped and unenlisted, which requires all dehydrated or suspended instances to be either manually resumed and completed, or terminated. After service instances are in the stopped and unenlisted state, the new application binaries can be deployed. First, the group’s MgmtDb should be updated by performing a Deploy operation using the overwrite flag. Second, each and every server in the group must be updated by GAC’ing the changed assembly. Finally, all BizTalk host instances should be restarted. At this point, the new orchestrations can be re-enlisted and started, and message flow can be resumed.
However, some customers may have more stringent requirements for upgrade. For example, they may not be able to schedule downtime or may have very long-running instances which cannot be terminated. In these cases, side-by-side versioning may be required.
Side-by-side (SxS) Versioning
This scenario, “Side-by-side Versioning”, allows two versions of the same application to be running side-by-side. The .NET runtime inherently allows for same-named but different versioned assemblies to be deployed and running. BizTalk also allows for this, although some discretion is advised.
BizTalk artifacts like maps are typically chosen by FQSN (fully-qualified strong name) which means the bindings are mindful of the version used. Making the code change in the map, upping the version number (major and minor builds only), compiling, and deploying the additional assembly to the group (and all machines) would then allow users to simply select the new map for inbound or outbound mapping. However, calling maps from orchestration may require code changes to the orchestration itself if the map reference is hard-coded.
Making changes to orchestrations can be a bit more involved. If you have short-lived orchestrations, then the “Patching Scenario”, previously described, may be sufficient. But if you have long-running orchestrations or cannot terminate existing instances, then side-by-side versioning will be your only alternative. Typically, the SxS story for orchestrations would go something like this.
Mortgage Company X needs to update their orchestration, but has many existing orchestration instances in flight that aren’t expected to terminate for weeks or months. They’d like for their existing instances to culminate on the live DLLs, but have new instances start up on the rev’d assemblies. To do this, they begin by having the developer increase the orchestration’s version number (major and minor builds only) and make the code changes to the orchestration. Next, they’ll deploy this new assembly to the group and GAC it on all runtime machines. Then the customer has the option to create new receive ports and locations for the new version or use existing ports. In the former is chosen, simply binding to the new ports and enlisting/starting the new artifacts will probably be sufficient. If the latter is chosen, some additional steps apply. The customer will have to (a) bind the new version of the orchestration to existing ports, (b) unenlist (but do not stop) the old orchestration version, and (c) enlist and start the new orchestration version. The documentation includes a script which help you to do steps (b) and (c) in one transaction so that messages are not missing subscriptions in between manual clicking.
The end result is that future publications will be directed to the new orchestration version and already running orchestration instances will complete on the older version. The product documentation should be consulted and followed closely for this kind of procedure, or for scenarios that depart from the “norm”, such as orchestration use of role links, direct binding, Specify Now binding, BAM activities, et cetera.
Upgrading pipelines has several alternatives as well. The simple solution is to simply choose the newly deployed pipeline version in the send port or receive location. This will replace the old pipeline with the new one. However, if true side-by-side functionality is required for backwards-compatibility purposes, then new send ports and receive locations will have to be created and bound to with the new pipeline version specified.
Finally, updating schemas also has some peculiarities. Side-by-side versioning is absolutely allowed, but the schema resolution behavior for the XML disassembler should be examined closely (described well in the docs). In certain cases, customers may want to hard-code references in the DASM properties to specific versions of the schemas to avoid dynamic resolution behavior. This will allow for more “pure” side-by-side scenarios.
How can MSIs be leveraged for upgrade scenarios?
Upgrading applications are typically a deliberate and precise operation in production. Because of this, following a manual checklist is advised. However, certain steps may be streamlined by using MSIs.
MSIs are a great way to wrap up your application artifacts into a distributable package. This may help when rolling out updated DLLs to multiple runtime boxes or assist with the group-level deploy. Precaution should be used when creating the MSIs to exclude all other unchanged resources and bindings from the package.
If conducting a “Patching Scenario”, stopping/unenlisting/re-enlisting/starting steps will need to be done manually before and after Importing/Installing the MSI. Similarly, numerous steps outlined above will have to be performed in the “Side-by-side Versioning Scenario” before and after using the MSI.
Still, MSIs can be useful for auditing purposes alone, since they leave a trace of the application’s upgrade installation on the machine in the Add/Remove Programs list.
More Information
In general, application upgrade is a cerebral activity and any change that you’ll ever make to your production environment should always be well tested and practiced in a pre-production environment. Having a non-production environment which mirrors the live environment will allow you to dry-run this and other production changes.
Needless to say, you should also carefully consult the product documentation before making any changes to your production environment, but this is especially true in the case of application upgrading. For more information on this topic, be sure to check out the documentation article entitled “Managing Artifacts”.
HTH,
Doug Girard
Note: This posting is provided “AS IS” with no warranties, and confers no rights.