[英]How to Deploy BizTalk Application into production Server?
I have the following doubts in BizTalk
deployment: 我在
BizTalk
部署中存在以下疑问:
BTDF
is the one of the best tools for deploying BizTalk applications and we can deploy BizTalk application to server using it? BTDF
是部署BizTalk应用程序的最佳工具之一,我们可以使用它来将BizTalk应用程序部署到服务器吗? 1. Deployment 1.部署
For deployment you can use the built-in MSI generation wizard. 对于部署,您可以使用内置的MSI生成向导。
It means you deploy the application on a dev environment using Visual Studio, then on the admin console, export the application a MSI using the wizard. 这意味着您可以使用Visual Studio在开发环境中部署应用程序,然后在管理控制台上使用向导将应用程序导出为MSI。 Finally you can use that MSI to deploy the app to the Production server.
最后,您可以使用该MSI将应用程序部署到生产服务器。 That's a two step process (Run MSI, import MSI in Bizalk Admin console).
这是一个两步过程(运行MSI,在Bizalk管理控制台中导入MSI)。
Note that only your Biztalk assemblies are installed by the MSI. 请注意,MSI仅安装您的Biztalk程序集。 If you use .NET assemblies in your solution, they need to be GAC'ed manually.
如果您在解决方案中使用.NET程序集,则需要手动对其进行GAC处理。 You will also need to restart the host instances running your Biztalk application.
您还需要重新启动运行Biztalk应用程序的主机实例。
See details here: https://msdn.microsoft.com/en-ca/library/aa559168.aspx 在此处查看详细信息: https : //msdn.microsoft.com/en-ca/library/aa559168.aspx
That's a few manual steps. 这是一些手动步骤。 Alternatively you can automate some of these steps by using the BTSTask, a command line tool included with Biztalk.
另外,您可以使用Biztalk附带的命令行工具BTSTask自动执行其中一些步骤。
You can script all the manual steps. 您可以编写所有手动步骤的脚本。
Obviously it takes time to write such script, so it's only worth it if you are going to deploy many times in non-dev environments. 显然,编写此类脚本需要花费时间,因此只有在非开发环境中进行多次部署时,才值得这样做。
BTSTask reference: https://msdn.microsoft.com/en-ca/library/aa559686.aspx BTS任务参考: https ://msdn.microsoft.com/en-ca/library/aa559686.aspx
2. Redeployment 2.调动
Usually you completely remove the old version and then install the new one: 通常,您会完全删除旧版本,然后安装新版本:
Delete the application from the Biztalk Administration Console and ungac the assemblies it uses. 从Biztalk管理控制台中删除该应用程序,并取消其使用的程序集。
The whole process would look like: 整个过程如下所示:
1. Make sure there are no running instances in you application. 1.确保应用程序中没有正在运行的实例。 You can always disable your receive location and let the running instances complete
您始终可以禁用接收位置,并让运行中的实例完成
2. Delete Biztalk application 2.删除Biztalk应用程序
3. UnGAC associated assemblies 3. UnGAC关联的程序集
4. Deploy new Biztalk application version and GAC associated assemblies 4.部署新的Biztalk应用程序版本和GAC关联的程序集
5. Restart Host Instances used by your Biztalk application 5.重新启动您的Biztalk应用程序使用的主机实例
EDIT: To address OP's concern about deleting a running application: 编辑:解决OP关于删除正在运行的应用程序的问题:
It is indeed possible to deploy resources independently and never delete your application. 实际上,可以独立部署资源,而永远不会删除您的应用程序。
But it does not mean you will not interrupt the service. 但这并不意味着您不会中断服务。
An orchestration for example, can never be redeployed when it has running instances. 例如,业务流程在具有正在运行的实例时永远无法重新部署。
So assuming that you divided your functionality properly into applications, I find it cleaner and easier to delete the whole application than going after each resource. 因此,假设您将功能正确地划分为多个应用程序,那么与删除每个资源相比,我发现它更干净,更容易删除整个应用程序。
Otherwise, yes you can go and replace your resources separately. 否则,可以,您可以单独替换资源。
But to me it seems like an overhead caused by not having defined applications correctly. 但是在我看来,这似乎是由于未正确定义应用程序而造成的开销。
3. BTDF 3. BTDF
The Biztalk Deployment Framework is a good tool to have some kind of automation in your deployment without having to write the scripts yourself. Biztalk部署框架是一个很好的工具,可以在您的部署中进行某种自动化,而无需自己编写脚本。
Good compromise between customization to your needs and setup time. 在根据您的需求进行定制和设置时间之间做出很好的折衷。
I have used it on a freelance project. 我已经在一个自由项目中使用了它。 It was very helpful because I was able to deliver a package with a only a couple of deployment instructions, and the non-techie client was able to deploy painlessly.
这非常有帮助,因为我能够交付仅包含几个部署说明的软件包,并且非技术人员的客户端能够轻松进行部署。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.