This project has moved and is read-only. For the latest updates, please go here.

Redeploy without undeploy to avoid changing BatchID number

Topics: Server Deployment
Mar 12, 2014 at 9:28 PM
Is there a way to use a BTDF msi to deploy (redeploy?) an application without undeploying it first?

The problem I'm running into is in an application I inherited that uses parties and an agreement to do EDI batching. The application won't undeploy without removing the parties first. Removing the parties is easy enough to do, but when it is redeployed, the BatchID number in the agreement is incremented. This BatchID is used in an orchestration and in a trigger file, so it would be best if it stayed the same.

I think I have a way to get around both problems if there is no way to keep BatchID the same, but it will take a good chunk of effort, and I want to make sure I'm not over looking a simpler solution.

Mar 12, 2014 at 10:17 PM
Is it failing to undeploy because the agreement references one or more send ports in the application? If so, as a workaround I wonder if you could add another BizTalk app that holds only the send port(s), have the agreement(s) point there, and just add an app reference from your existing app to the new ports-only app. The ports-only app would stay there all the time. I suppose you'd have to leave the parties out of your existing app's bindings XML too.

As an alternative workaround, the Deployment Framework has a property named SkipUndeploy, and when you use the Redeploy Start menu command, the difference from regular Deploy is that SkipUndeploy=true. That mode doesn't remove the BizTalk app. You'd have to uninstall/install your MSI without running the undeploy step, and always use redeploy. It seems like you could run into some trouble if you made significant changes to the app between versions, although I don't have an example off the top of my head.

Mar 13, 2014 at 2:49 PM
Yes, the failure is because of a port reference in the agreement.

The first suggestion sounds like it would work, but it is a little late in the process to do that much reengineering.

I tried the approach of installing the new msi and running Redeploy with Skipundeploy = true, and I got an "application name already exists" error. I was trying some other things at the same time, so I will try a more focused test.

My fallback plan is to remove the BatchID use from the orchestration, and when deploying remove the parties first , then do a regular BTDF undeploy/deploy, query the management database to get the new Batch ID, and finally add the new ID to the trigger file. I know how to do all the deployment steps with powershell.