Understanding Environment Libraries

The Management Console in K2 Workspace is superseded by the K2 Management Site and you should use the K2 Management Site to administer your K2 environment, rather than Management Console in K2 Workspace. (In certain cases you may need to use the Management Console in K2 Workspace to perform tasks that are not exposed in the K2 Management Site.)

Many organizations have multiple K2 environments, for example Development, Test, QA and Production. These environments usually have different server names, URL’s settings and so on. K2 makes provision for multiple environments with the Environment Library, which is essentially a repository of environment-specific values or "placeholders" for each of your K2 environments. Consider the table below:

When building workflows, designers may need to interact with the SharePoint or Email servers. Here is an example: perhaps the developer will use a SharePoint document event to copy a document from one document library to another. Part of that event wizard needs the URL of the SharePoint site where the document libraries exist. It would be tedious (not to mention hazardous) to develop the solution for the Dev environment using the hard-coded URL for the development SharePoint server and then have to go through the event wizard again to replace the URL with the production SharePoint server before deploying the solution to the production environment. This is where the environment library comes into play.

Consider the screenshot below, which is one of the screens for the document move wizard. Instead of hard-coding the URL of the SharePoint site into the wizard, the developer can browse through the values stored in the environment library, and then drag and drop the “placeholder” for the SharePoint site URL into the wizard. (The actual value of the SharePoint server is not resolved until runtime.) The designers will deploy the workflow with the [Portal] placeholder. When the workflow executes at runtime, K2 will replace the URL of the SharePoint server for the current environment (in other words, the Development SharePoint server URL if the workflow is running in Development, and the production SharePoint server URL if the workflow is running in Production)

Using an environment field in the K2 designer

Using an environment library field in the K2 SmartForms design tool

Environment fields are stored on a K2 server, and K2 is “context-aware” at runtime. This means that even if one K2 environment contains multiple copies of the same placeholder for each environment, when the workflow retrieves a environment field at runtime, K2 will know which values to use for the placeholder for the current environment. The currently-active environment is defined by the "Default setting for the environment.

The default values in the environment library are set up when K2 is installed, but it may be necessary to update these values from time to time. This can be done either through the K2 Studio environment or by the K2 administrator using the K2 workspace. Regardless of the approach used, the values are centrally stored on the K2 server.

By default K2 is installed with two Environments listed in the Default Template group. (It is possible to add or remove environments from the Environment Library). When a developer deploys a K2 project, they will target a specific environment. The project will then retrieve the values for the specified environment from the K2 server and publish the project to the relevant K2 server

Selecting the target environment when deploying a K2 project

Templates

Think of "Templates" as a collection of pre-defined fields without values. A Template is just another collection of Environments and Environment Fields. Remember that K2 is installed with a Default template containing two environments (Development and Production), and you can add or remove environment from that template quite easily. If necessary, you can add additional Templates, each with its own set of Environments. This allows you to define isolated environment-settings based on some boundary, like business unit. In a large, shared K2 environment where many teams are building and deploying solutions, it might be a good idea to define additional Templates so that teams do not impact each other's environment settings.

Consider the screenshot below. Here we have defined two new templates: one for the Finance development team and another for the HR development team. Each Template, in turn, contains a Development Environment and a Production Environment.

Multiple Templates in a K2 server, each with their own Environments

In the design tools, developers can switch between the Templates and then create a deployment package for the target environment. When the developer deploys their solution, they will select from the environments defined for the currently-selected template.

Switching to a different template with the category browser

Environment Libraries - Setup Options

To help you decide on an appropriate approach for managing and maintaining your environment libraries, let's look at some common approaches used to define and separate Environment Libraries. We will discuss three common options.

Each approach has its benefits and drawbacks, and there are many factors that may determine whether you chose one over the other. If you are unsure which to use, the recommended approach is to the use Single model. This way, you only need to maintain Environment Library settings in one K2 server and it is easier to create deployment packages. You should set up server-level rights to restrict deployment to specific environments to prevent developers from mistakenly deploying to the wrong environment.

For larger environments, shared development environments or environments with strict change control policies we recommend that you make use of K2's consulting services to select am approach for your Environment Library, Templates and Security that will work well with the way your organization plans to use K2

Single

With the Single approach, a single K2 environment stores the Environment Libraries for all the other environments. This approach is the simplest to use and is used most often.

Consider the diagram below, where we have three separate K2 environments: Dev, QA and Production. In the Single model, the Development K2 environment stores the Environment Library for Development, QA and Production. When a developer wishes to deploy a solution (or create a deployment package), they will always connect to the Development K2 server and then select the target environment that they want to deploy to

Environment Library Setup - Single

Although this Single approach is the simplest to use and maintain, there is a risk because a developer may inadvertently select the wrong environment to deploy to. You can mitigate this risk by setting up Server Rights for the Workflow Server in the Production environment, and only allowing Administrators to deploy to the Production environment. This way, even if a developer mistakenly selects Production, they won't be able to deploy the solution

Isolated

With the isolated approach, each K2 environment has a separate and dedicated Environment Library that only contains the environment settings for itself. This is probably the most secure option, since the developer would physically need to change the connection string in their development workstation before they will be able to deploy to the selected environment.

Consider the diagram below. Here, we have the same three K2 environments (Dev, QA and Production), but each one only knows about itself

Environment Library Setup - Isolated

At design time, the developer would have to physically change the connection before they will be able to deploy to the target environment, as shown below. This adds some additional overhead to the developer and they need to be very careful to connect to the correct K2 server, but it makes it very difficult to mistakenly deploy to the wrong environment because the developer would only have one option in the Environment drop-down box when they deploy. If you couple this with server-level rights on each K2 environment, you can harden the deployment security even more.

Changing the connection to the Environment Server

Self + 1

Another Environment Library setup approach is where each environment only knows about itself and the environment immediately following.

Consider the example below with the Dev, QA and Production environments. In this setup, the Development K2 server only knows about itself and the QA environment. This means that developers can deploy to both Development and QA, but not to Production, because the Development server doesn’t even know about Production

Environment Library Setup – Self + 1

To deploy a solution to Production, the person creating the deployment package would need to physically connect to the QA server and select the Production environment (or target the production environment in their deployment package).

This approach combines the Single and Isolated models to make it easier for developers to move between Development and QA, but harder to inadvertently deploy to production. The drawback of this approach is that the Environment Library settings are maintained separately, so it adds workload to the K2 administrators to maintain settings across multiple servers.