More on Bindings
Recently I’ve worked on splitting our binding files -
Until now we would normally build our application, deploy it locally, sort out ports and stuff, export binding and package that with our deployment framework; we would typically also create copies of the binding files for the various environment (dev, test, UAT, production) and modify values in there as needed before adding these copies to the framework as well.
The thing is, that half of these binding files were static – the list of schemas, and orchestrations, and the binding of the orchestrations to hosts and ports, did not change from one environment to another; for the most part it is only port properties that change.
And so, from a maintenance point of view, whenever we added an orchestration to an application, we have to edit several binding files, even if we haven’t introduced any new ports.
Looking to improve on this we’ve split the binding file – we have one, mostly shared, file containing the stuff that doesn’t change (modules), and then one file per environment containing the stuff that does change (ports).
Now when we add a new orchestration, we only have to modify one binding file.
The question was – what do we do in our deployment framework!?
When adding a binding file as a resource the UI suggests that by not specifying an environment name for the binding file you will be instructing BizTalk to apply this to all environments, when you go ahead and do that you see that the binding file gets added with ‘ENV:ALL’ as the ‘destination location’ as opposed to ‘ENV:Production’, for example, if you type in ‘Production’ as the environment name.
Easy enough, I thought, but being the pessimistic guy that I am I figured that there’s no chance the API will take an empty environment name, so I’ve decided to put ALL as the environment name; after all – that’s what it stores, isn’t it?
Running my script I could see the binding file being added as a resource, and I could see that the destination location appears as I expected it to in the administration console, so I took the next step of exporting the MSI, deleting the application and trying to import from the MSI.
Here was the sign that something isn’t quite right – when prompted to choose environments ‘ALL’ was listed as one of the possible options; this didn’t seem right, but I carried on regardless with my experiment and selected the ‘Production’ environment.
The MSI was imported successfully, and the ports from the shared binding file were used, despite me not picking the ‘ALL’ environment, which is what I wanted. good. but why did ‘ALL’ appear there?
To start with, I wanted to go back to the ‘standard behaivour’ and see how this looks like if I add the binding file through the UI and not providing an environment name. Could it be that the ‘ALL’ option was always there and I simply never paid attention to that?
As it turns out – no. removing the binding file I added via script, and re-adding it though the UI, not providing any environment name, re-added it with the ENV:ALL as the destination location, but on export MSI and re-import, the list of environments to choose from did not include the name ‘ALL’.
So – clearly there’s a behavioural difference.
I’ve changed our script to add the binding without specifying environment name. despite my unfounded doubts this works like a charm and again in the admin console I could see my binding with the ENV:ALL destination location.
This time, when exporting and importing the MSI, the ‘ALL’ environment did not appear in the list of the import MSI wizard, but when selecting any other environment, the shared binding file did apply to either. Mission accomplished.
Have faith in the API. but also – there is a little bit of magic, and no tall ENV:ALL are alike – it looks as if on the one hand any binding file with the destination location ‘ENV:ALL’ will be applied to all environments, but only if you add it without specifying an environment name will it NOT appear in the environments list. magic!