Skip to main content

Managing the Applications Lifecycle

 

OutSystems

Selective Deployment Using Zones

Only available in OutSystems on-premises installations.

Zones allow you to define the distribution of modules, or eSpaces, by front-end servers on a farm environment.

Use zones when you have front-end servers with different purposes (usually called front-ends) — e.g. when some of the front-ends are in a DMZ network — and want to choose which front-ends your modules will be deployed to.

Zones provide isolation to modules by ensuring they are only deployed to the front-ends configured for a given zone. When the zone defined for a module is changed or when the module changes to a different zone, that module is deployed on the front-ends configured for the new zone and is removed from the front-ends that don't belong to that zone.

The "Global" zone is a built-in zone that contains all front-end servers of an OutSystems environment. When a module is published for the first time, it's deployed in the "Global" zone, making it available on every front-end. Unlike other defined zones, when you add a front-end to an environment, the "Global" zone is automatically updated to include the new front-end.

Each zone has one or more front-end. Front-ends can belong to several zones at the same time. However, a module can only be associated with a single zone. All these configurations are defined in Service Center.

In the following example, we define three zones:

  • The "Internal Apps" zone has two associated front-end servers: Front-end 1 and Front-end 2;
  • The "B2E" zone has one associated front-end server: Front-end 2;
  • The "Public" zone has one associated front-end server: Front-end 3.

Then, we configure three modules associating them with a given zone:

  • Module 1 is associated with the "Internal Apps" zone;
  • Module 2 is associated with the "B2E" zone;
  • Module 3 is associated with the "Public" zone.

The modules will be deployed to the three front-end servers according to the following diagram:

Example Use Cases

Internal Web Application

Consider a scenario with two front-ends configured in the environment:

  • One front-end on a DMZ network, to be accessed by external users connected to the Internet;
  • One internal front-end, to be accessed by internal users.

You wish to deploy a web application and make it available to internal users only. By default, your web application modules are deployed to the "Global" zone; however, this would make them available in all front-ends, both the internal and the public-facing one in the DMZ network.

To change the configuration of the web application modules so that they are only deployed to the internal front-end, do the following:

  • Create a new zone (e.g. "Intranet") containing only the internal front-end;
  • Configure all the modules of the web application to use the new zone.

After these steps, the modules you just configured will only be deployed to the internal front-end, and they will be removed from any other front-ends belonging to the previously configured zone. Internal users will access the modules through the internal front-end address.

If at a later stage you add a new module to the web application, it will be deployed to the default zone, i.e. the "Global" zone. You would then need to set the new module's zone to "Intranet" if you wanted to deploy it to the same zone as the other modules.

Load Distribution for a Public Web Application

Consider a scenario with two public front-ends, accessible from the Internet. You wish to deploy a web application for public access and distribute the load between the two available public front-ends. This will require you to set up a load balancer, a 3rd-party component, to split the load between the two.

To correctly deploy a web application to these two public-facing front-ends and do a load distribution between them, do the following:

  • Set up a zone (e.g. "Public") containing the two public-facing front-ends that will handle requests made to the web application;
  • Configure all the modules of the web application to use the new zone;
  • Set up a load balancer that will route the requests to the module URLs in one of the public-facing front-ends that you configured in the zone.

After doing these configurations, the modules of the web application will be deployed in the two public-facing front-ends. Users will access the modules using the address of the load balancer, which will hand over the requests to the configured front-ends in the "Public" zone.

Limitations

Take the following limitations into account when deploying modules to different zones:

  • System Components are always deployed to the "Global" zone and this setting cannot be changed. Use the internal network configuration to limit the access to Service Center and LifeTime (available in Service Center in Administration > Security > Network Security);

  • Timers and Emails of a module are only available in the front-ends of the zone where the module was deployed to;

  • It's not possible to call BPT-related system actions (ActivityClose, ActivityGetUrl, etc.) for activities that belong to modules in a different zone;

  • Images, CSS files and module resource files belonging to a given module should not be accessed from another module unless they are being deployed to the exact same front-ends.

Articles in this Section