Skip to the content.

Environment Overrides

Downloads The code samples used in this user guide have been made available in the Be.Stateless.BizTalk.Factory.Samples GitHub repository.

A Microsoft BizTalk Server® application generally targets multiple deployment environments, each with a different configuration. The basic use cases for parameterized deployments is that there usually is a set of properties whose value differs in each environment —e.g. login, passwords, URLs, and so on. This use case is handled and supported via the Environment Dependent Values, as explained in the following section.

Besides supporting different configurations at the property level, BizTalk.Factory’s Binding DSL also recognizes scenarios where one application needs to connect to endpoints varying according to the target deployment environment. For instance, when deployed to the development or build environments, some ports would need to be bound to stub endpoints in order for the application’s flows to be automatically tested, while some other ports —e.g. supplementary receive locations belonging to one receive port— would not need to be deployed at all.

BizTalk.Factory’s Binding DSL supports this overriding mechanisms through the ISupportEnvironmentOverride interface, which provides one single method:

void ApplyEnvironmentOverrides(string environment);

where the environment parameter is a string identifying the target deployment environment, i.e. the environment for which the bindings are currently being generated, thus giving an opportunity to each class that supports this interface to adapt its binding configuration accordingly. To be accurate, all the following base classes support the ISupportEnvironmentOverride interface:

and have been provided with a default implementation similar to what follows:

void ISupportEnvironmentOverride.ApplyEnvironmentOverrides(string environment)
{
   if (!environment.IsNullOrEmpty()) ApplyEnvironmentOverrides(environment);
}

protected virtual void ApplyEnvironmentOverrides(string environment) { }

whose purpose is clearly to free the developer from worrying about nothing else than to provide an ApplyEnvironmentOverrides method override when necessary.

Remark The reason the interface has been implemented explicitly and that it delegates the call to a protected overridable —i.e. virtual— method, with the exact same signature, was not to clutter the Visual Studio® intellisense, which BizTalk.Factory’s Binding DSL embraced as a way to offer a fluent interface —exposing only useful and guiding methods and hiding others.

For the sake of completeness, a few of these base classes actually do more than delegating the call to an empty method, they do forward the call to their constituent parts as well.

While, as we have seen, the endpoints to which to connect could vary with the target deployment environments, a port, on the contrary, should share as much features and configuration as possible across its target deployment environments. Failure to do so so would make an application hardly predictable and seriously reduce the value of the automated tests. What could we conclude from automated tests if a port’s pipelines or adapter were configured differently in each deployment environment? For these reasons, BizTalk.Factory’s Binding DSL does not support ApplyEnvironmentOverrides call forwarding for the following port’s constituent: