Administration

The administration entry opens when you click the configuration icon in the blue header bar of the application.

The following screen has 4 entries:

User Management
API Tokens
License
Agents

User Management

The user management screen allows administrators and users with the proper permissions to govern all users, user groups, roles & permissions. On top of this, LDAP functionality is contained within this menu. Because the user permission system is quite complex, we’ve dedicated an entire chapter of the documentation under this one to it. Therefore, please refer to the Configuring Runtime Permissions sub-chapter to learn how our user permission system is designed. Likewise, for LDAP we’ve included a separate sub-chapter as well titled LDAP Configuration.

Upon a fresh installation of Runtime without an existing DATA folder, Runtime automatically creates an administrator account to allow the installer to access the interface. This is a user who is assigned the standard role of Administrator. Functionally, this means that this account is able to configure all aspects of Runtime, and allows the user to modify the existing rights from the start. Changes to this account can be made, but care should be taken that it is not deleted, unless other users exist who function as a de facto administrator account. Not taking care to do this can lead to a permissions configuration where the user locks himself out of certain system functionality.

The administrator account is created with the following default log-in credentials:

Username: admin
Password: admin

For security reasons the admin password should be changed to a more secure password after installation.

API Tokens

In order to send API calls a valid API token is required. Currently, API tokens are always tied to a user, and all rights assigned to the user are matched when interacting with the Runtime API. This means that when an API key is created care must be taken to ensure that the user under which the key is registered has the correct rights, otherwise when executing any API calls a 401 – Unauthorized response will be automatically generated.

There are two views which include information about API tokens, one tied to the user's profile, and a universal API key administration screen.

User-specific API Token menu

Because all API tokens are bound to a user, users have the ability to create and manage their own API keys. In order to access the user API tokens menu, and create a personal key a user should have the Manage User API Tokens permission assigned to them.

In order to create a new API key, follow these steps:

Select the user profile in the top-right corner of the Runtime interface
Select API Tokens
A new view will open, which includes an overview of all API keys registered under this user
Press Generate API Token in the top-right corner of this view.
In the dialog screen that opens, specify a name for the token, and press Save Changes.

Don't forget to copy your key!

Once an API key has been saved, it's no longer possible to see what the actual key is. Therefore, the user only has one opportunity to copy the key and store it somewhere secure.

You should now see your created in the API Tokens overview under your user-profile.

Demo: creating an API key

API key permissions

API keys are generated by users and tied to their account. This has a few implications. Firstly, all API keys have a set of permissions, which are identical to the user to which the key is attached. In order to edit the rights of the key, the user to which the key is attached must be modified. This allows administrators to give keys specific rights, and is a deliberate security feature to help the user identify which key was used to execute a specific script if separate keys exist per group/environment/template. Additionally, this can prevent malicious usage of keys.

If a user is deleted from Runtime, all API keys attached to that user are also automatically removed!

Universal API Token menu

The universal API tokens menu, situated on the left-hand side of the Runtime main page menu describes all existing API Tokens, and gives the user the possibility to revoke keys by pressing the Revoke button on the left-hand side on any given key entry. This menu is not suitable for creating new tokens however. In order to access this view, the user trying to access it must have the Manage API Tokens permission assigned to them.

Adding the API token into scripts

We authenticate API tokens by checking whether it is included in the header of any call. To do this, a user can make use of the following syntax:

POWERSHELL

--header "X-auth-token:<TOKEN>"

License

The license is entered during installation.

In this screen you can check and update the license if the license is about to expire.

You can clearly see if the license is Valid , Almost expired or Expired.

Almost Expired:
As of 30 days before expiring a yellow notification bar is shown on top of the application telling you the license will expire within a certain amount of days. You are able to hide this notification bar.
Expired:
After expiring a red notification bar is shown on top of the application telling you the license has expired.

Once the expiration date has passed it is not possible to upload, install or uninstall applications .
You can still run applications, you cannot hide the notification bar.

30 Days after expiring you can no longer run applications. In order to be able to continue working with the software, a valid license code has to be supplied.

In this screen you can also see the type of license used and the properties of this licences:

- Number of parallel processes.

- Number of allowed users.

- Number of allowed environments.

- Number of allowed applications.

- Number of allowed agents.

- Use of API allowance.

Agents

Agents reworked in 4.4

How we handle agents has been fundamentally changed in Runtime 4.4! If you're still using older versions of DATPROF Runtime, please navigate to an older version of this documentation in the top right corner of the website.

Agents are vital for Runtime. Every agent is a Java process that is started by Runtime to execute database tasks. Therefore an agent is both required to install an application (in the database) and to run the application. You may have multiple agents.

Agents belong to DATPROF Runtime and will be used by different applications. In other words, applications share Agents.

Note:
An application requires only one available agent. The parallel setting you enter has nothing to do with the number of agents but applies to the threads within an agent.

Agents are automatically created when a run is started, and dropped when a run is completed.

This will immediately create an entry on the screen and an entry in the Runtime Meta Data Service database.

Every agent has three attributes, ID, Status

ID: This is a unique number identifying the agent.
Status of the Agent
- UNAVAILABLE: The Agent is created but not running.
- AVAILABLE: The Agent is started and a java process is waiting to execute a task.
- RUNNING: The Agent is executing a task.
- PAUSED: The Agent is paused on user request by pausing the application.

The Agents use the UUID as their name. On the filesystem in the Runtime Data folder you have an agents folder. In this agents folder a subfolder is created for every agent using the UUID as its name. In this folder you’ll find both the code to run and the agent's logfiles.

Managing agents can be done with the buttons at the right side, the action depends on the current status.

STATUS ACTIONS

UNAVAILABLE: Start and Delete
AVAILABLE: Stop and Delete
PAUSED: -
RUNNING: Stop

Deleting a Paused or Running agent is not possible.

Note: An application in Error will keep an agent in a Running state.