that thing

we do

frends has more features than any other integration software out there. Explore, ideate, and if anything is unclear - hit us up at any time. This library is bound to grow over time.

Central Variable Management

frends has a centralized variable storage and management system called Enviornment Variables, which can be used to securely store usernames, passwords, keys, server addresses and so on.

The aim of the central variable management system is twofold; to enable a secure storage for different variables used commonly in the integration processes and to enable seamless DevOps pipelines by providing differing values depending on the execution enviornment.

1. To Manage Common Variables

The first use case for the central variable management system is to store commonly used variables from a single central location instead of "hard-coding" them in the actual integration processes.

Consider the following scenario where frends connects to an SQL server and the frends Task requires a Connection String to establish the connection to the SQL server.

You can either "hard-code" the connection string by simply providing the actual value:

Server=mysql.server.com;Database=MyDataBase;User Id=UserName;Password=Password;

or you can add references to the Enviornment Variables functionality, where the values will be managed separately for all solutions and processes using said database:

Server={{#env.SQL.Server}};Database={{#env.SQL.Database}};User Id={{#env.SQL.Username}};Password={{#env.SQL.Password}};

This means that now you can update for example the password once and all solutions using these Enviornment Variable references will be updated automatically to utilize the new password.

2. To Enable DevOps Pipeline Automation

The second use case for the central variable management system is to utilize the functionality of the Enviornment Variables to set different values dynamically depending on the enviornment the integration flow is executing in.

This means that you could set the variables so that:

Enviornment #env.SQL.Server value
Development mysqldev.server.com
Test mysqltest.server.com
Production mysqlprod.server.com

This way while you are moving the integration process through the development pipeline it can target a different database depending on the enviornment it's executing in.

Central Variable Management

frends has a centralized variable storage and management system called Enviornment Variables, which can be used to securely store usernames, passwords, keys, server addresses and so on.

The aim of the central variable management system is twofold; to enable a secure storage for different variables used commonly in the integration processes and to enable seamless DevOps pipelines by providing differing values depending on the execution enviornment.

1. To Manage Common Variables

The first use case for the central variable management system is to store commonly used variables from a single central location instead of "hard-coding" them in the actual integration processes.

Consider the following scenario where frends connects to an SQL server and the frends Task requires a Connection String to establish the connection to the SQL server.

You can either "hard-code" the connection string by simply providing the actual value:

Server=mysql.server.com;Database=MyDataBase;User Id=UserName;Password=Password;

or you can add references to the Enviornment Variables functionality, where the values will be managed separately for all solutions and processes using said database:

Server={{#env.SQL.Server}};Database={{#env.SQL.Database}};User Id={{#env.SQL.Username}};Password={{#env.SQL.Password}};

This means that now you can update for example the password once and all solutions using these Enviornment Variable references will be updated automatically to utilize the new password.

2. To Enable DevOps Pipeline Automation

The second use case for the central variable management system is to utilize the functionality of the Enviornment Variables to set different values dynamically depending on the enviornment the integration flow is executing in.

This means that you could set the variables so that:

Enviornment #env.SQL.Server value
Development mysqldev.server.com
Test mysqltest.server.com
Production mysqlprod.server.com

This way while you are moving the integration process through the development pipeline it can target a different database depending on the enviornment it's executing in.