by community-syndication | Jun 29, 2004 | BizTalk Community Blogs via Syndication
(Update: See the latest on the Deployment Framework here.)
Addressing a few comments/questions that have appeared –
-
Bootstrapping your binding file: It was pointed out that a bootstrapping process is
required for your initial BizTalk Orchestration binding file. This is quite
true – you either need to manually deploy your orchestration(s) and associated assemblies,
and use the BizTalk Deployment Wizard to create a binding file, or you need to create
a binding file by hand (using a previous file as an example…)
-
Automatic maintenance of your binding file: Hermo Terblanche would like the binding
file to be maintained automatically (as part of the build process.) One could
imagine automatically “refreshing” this file using BTSDeploy at build
time. However, there is a question of what the source of truth should be for
your bindings – I would argue it should be the binding file, not the current configuration
of the server. Others might disagree, at least during development.
-
Rule deployment: Chris Delaney is looking for a method of deploying rules.
There doesn’t appear to be a command line tool for this (that you could call from
NAnt), but it looks somewhat trivial to write. See \program files\microsoft
biztalk server 2004\sdk\samples\business rules\business rules hello world2\HelloWorld2.cs
– specifically the LoadFromFile and DeployRuleSet methods.
by community-syndication | Jun 15, 2004 | BizTalk Community Blogs via Syndication
(Update: See the latest on the Deployment Framework here.)
I realized today that in the “deploy.orchestrations” target of the NAnt build file
(discussed here)
there is a bug in the ordering of operations. The original file imported the
binding file prior to deploying the orchestration – which doesn’t work for a “first
time” deployment.
In addition, Hermo Terblanche made a good point (in comments) regarding piplines which
are used by Send/Receive ports – i.e. the ports need to be removed prior to removing/updating
the corresponding pipeline assembly.
Therefore, an additional dependency has been added to the “undeploy.piplines” target
– namely, “remove.ports”. This target will remove exactly one Send and one Receive
port, the names of which are derived from the binding file. This section of
the build file will have to be customized for your purposes, just like the names and
ordering of orchestrations. Note that in my sample, the orchestration uses “Specify
Now” ports, and removing the Send/Receive ports is probably not necessary.
However, for “Specify Later” ports (the more typical case) that use custom
pipelines, you will get the error referenced in Hermo’s comment if you do not remove
the ports prior to updating the pipeline assembly.
The zip file with a new build file is still located here.
Current NAnt output from the sample will look like this.
Enjoy!
