View Run Environment

this view can be found in the Viewgroup Environment

The conceptual overview of working with different environments can be found in Run Environment

Find a detailed description of the Run Environment View here

List of Run Environments

screenshot Run Environment Overview
  • list of environments displays all environments. Environments allow a service related configuration for URLs and authentication information
  • new Environment creates a new entry
  • delete removes an environment
  • rename lets you change the list display name, which also affects the Run Environment picker text in the Viewgroup Testdefinition
  • move up the position of the selected entries
  • move down the position of the selected entries
  • copy an existing entry to create a new entry

Run Environment configurations for a Service Definition

When you select en entry you can configure Run Environment specific settings, either empty

screenshot Run Environment with empty Service Configuration
  • Add will create a new configuration for the
  • selected Run Environment time travel
  • on the Service Definition My HTTP Service two

When you click Add you will see a configuration dialog, outlined with screenshot for an existing configuration on another Service Definition:

screenshot Run Environment Service Definition

This is a screenshot from a Manual HTTP Service Definition Run Environment configuration for an environment time travel. The SOAP definition differs only in the URL input, which is described below.

Settings for Run Environment Service Definitions

  • On the top, you see the currently seelcted run environment name
  • You enter the host url and the port for a Manual HTTP Service Definition or a complete URL for SOAP Service. We expect non-SOAP Service to use routes and query parameters added to the host url that will not differ between environments but teststep specific, where soap service have just different URLs without route and query parameters
  • Authentication has three options:
    • Basic HTTP Authentication, you provide a username and a password which will be used to create the HTTP Header Authorization Basic. See the example configuration in the screenshot above
    • Bearer HTTP Authentication, you provide a token information which will be used to create a HTTP Header Authorization Bearer
    • NO HTTP Authentication, you may provide a payload username a payload password, a payload OTP and/or a payload token that may be static or be variable

Resolution process for Run Environment settings

See Run Environment for the conceptual overview. In the case of basic and bearer authentication, APIJockey Test handles adding the Headers for you. It will resolve the information entered in this configuration screenshot.

You can access the authentication information in your payload by using variables, in the case you need to authentication against an Identity Service to get authorized for a business service

You can use variables in the configuration, if you need to run an authentication call and want to store a token in a repository variable.

For convenience, find all EnvironmentConfig Variables here with the notation to use in your Test Definition

Authentication type Textfield name Variable notation in Test definition
HTTP basic Authentication HTTP username $(EnvironmentConfig.httpUsername)
HTTP basic Authentication HTTP password $(EnvironmentConfig.httpPassword)
HTTP bearer Authentication HTTP bearer token $(EnvironmentConfig.bearerToken)
None (No HTTP authentication) Payload username $(EnvironmentConfig.payloadUsername)
None (No HTTP authentication) Payload username $(EnvironmentConfig.payloadPassword)
None (No HTTP authentication) Payload OTP $(EnvironmentConfig.payloadOTP)
None (No HTTP authentication) Payload Token $(EnvironmentConfig.payloadToken)