Skip to end of metadata
Go to start of metadata

Introduction

The Environments page of the Management Console allows you to set up one or more environments within an organization in order to define and manage the integration project lifecycle.

All integration projects deployed from Cloud Studio or Design Studio to Harmony are deployed to various environments, which can represent a given state of an integration project. For example, a common project lifecycle configuration might have three environments: development, test, and production. You must set up at least one environment in order to create projects within Jitterbit Harmony.

NOTE: When you're ready to move between environments, such as from test to production, you migrate the project from within Cloud Studio (see Project Migration) or Design Studio under File > Migrate Project.

When you create environments, you also need to grant roles access to the environment, and can further limit what those roles can do within the environment by defining access levels.

TIP: Before granting role access to environments, the role must already be defined from the Organizations page.

To access the Environments page, log in to the Jitterbit Harmony Portal, then click the orange hamburger menu in the top left:

From the menu, hover over Management Console and select Environments:

NOTE: Make sure you are accessing the desired organization. In the top navigation bar, use the dropdown that appears between your name and Help to switch between organizations.


Managing Environments

Administrators of the organization manage the basic information and associated Agent Groups that apply to the environment.

View Environments

The top section of the Environments page contains a table that shows all the environments that you have access to within the selected organization:

The table displays information for each environment. Some of this information is configurable as explained in the next sections, including these fields:

  • Environment
  • Agent Group
  • URL prefix
  • Hit limit

Other fields in the table contain automatically populated statistics about your environment, including a count of these items:

  • Projects
  • Operations
  • Connections
  • Hosted endpoints
  • File formats
  • Scripts

You can sort the table by clicking on any of the column headers, or search by field using the syntax shown in the search box.

Add Environments

At least one environment must be defined for each organization. You may be limited to the number of environments you can create based on your subscription plan. If you require more environments, please contact your Customer Success Manager.

To add an environment, click the  button. Fill out the fields as follows:

  • Name: Name of your new environment (for example, Development, Test, or Production). Name is a required field.

    WARNING: These special characters are not allowed: < > # % { } | \ / ^ ~ [ ] ` ; , : ? @ = &.
  • Organization Name: This field defaults to the organization you are currently working in and is not editable.
  • URL Prefix: This is the URL prefix that will be used if you have API endpoints. By default, the name of the environment is used, replacing <API-URL-Prefix> in this example format:

    https://<OrgName&ID>.jitterbit.org/<API-URL-Prefix>/API-Version/API-Public-Name

    Whether you use the environment default or enter a custom name, the URL Prefix becomes an integral part of all API endpoint URLs and should be relatively short. The URL Prefix is limited to a maximum of 48 characters. 

    WARNING: These special characters are not allowed: < > # % { } | \ / ^ ~ [ ] ` ; , : ? @ = &In addition, spaces are not allowed.
  • Associate Group: This is the Agent Group you want to service the new environment. You must select only one Agent Group per environment, choosing from either a Private Agent Group set up from the Agents Groups page (see Agents > Agent Groups) or one of the two Jitterbit Cloud Agent Groups (available by default).

  • Hit Limit: This field provides the option to limit the number of API hits per minute on the environment level. Left blank, there is no limit to the number of API hits within the environment. The limit of hits per minute defaults to the org limit across all APIs in all environments.

  • Description: Optionally enter a description of your new environment.

Your new environment should now appear in the table of environments.

Edit or Remove Environments

If you need to change any information about your environment after it is created, or remove it, you can do so using the Action dropdown on the far right.

  • Choose Edit Environment to change the NameURL PrefixHit Limit, or Description.
  • Choose Associate Agent Group to change the Agent Group associated with the environment.
  • Choose Remove Environment to remove the environment from your organization.

Managing Role Access to Environments

TIP: Before granting role access to environments, the role must already be defined from the Organizations page.

Access to environments is based on roles. The individual membership for those roles is defined at the organization level. For more information on roles and members please see the Organizations page.

View Roles with Access to the Environment

The bottom section of the environments page contains a tab for Roles. This table will display all roles that have access to the selected environment. In the right column, you can see the exact access levels associated with each role. 

Access levels are defined at the environment level, and are a way to further control the abilities that members of a certain role have in certain environments. For example, users in a developer role may have Read, Execute, and Write privileges in the development environment, but only Read access to a test environment, and no access to the production environment.

The access levels available in an environment are as follows:

  • View Logs: View Logs access allows a user only to read logs from a given environment.
  • Read: Read access provides View Logs access and allows a user to read a project from a given environment. Use this option to share project templates with various users, or to allow them to view but not affect projects deployed to critical environments such as test or production.
  • Execute: Execute access provides Read access and allows users to run operations within a given environment. This is a common access control for test environments and is often granted to users who need to support an integration, as they will need to test, run, and view operation logs.
  • Write: Write access provides full control to a given environment. Users belonging to a role with Write access can read, test, run, and change projects within an environment.

NOTE: External API App developers will need to be members of a role which is assigned the ApiConsumer permission. See the steps to set up the role in the Organizations page. In addition, the role needs to be assigned View Logs and Read permissions in the environment hosting the public facing developer Portal. Follow the steps in the next section to Grant Role Access to the Environment , providing developers access to the APIs available within the Portal, access to view API Logs, and view Analytics.

Grant Role Access to the Environment

Click the  button to grant an existing role access to the selected environment. In the popup, select the role you want to add.

Next use the checkboxes to define the access levels that you want members of the role to have within the given environment. These include the ability to View Logs, Read, Execute, or Write to the environment.

Edit Role Access to the Environment

In the Roles tab, click on the access level for each role to toggle access on and off.

NOTE: Internal API App developers may need Execute and Write permissions assigned to the API environment in addition to View Logs and Read permissions. These permissions will allow members to access API Manager directly, create and edit security profiles, create and edit APIs, and access to some functionality in Management Console. We suggest creating separate roles for internal and external API App developers to accommodate the different levels of security and access required.

On This Page

Last updated:  Nov 08, 2019