Execution

This page allows to manage the Digital Automation Suite settings that are deployed in the Digital Enterprise Suite.

Deployment Environments

Environment are named using lowercase names and can’t contain spaces.

It is possible to delete ( ), edit ( ) or manage who has access ( ) to each environment.

To create a New Environment by clicking on the button at the top right, you need to provide a name and a few attributes.

Access rights

Performer

A user can execute services from this environment such as starting instances, performing tasks, etc.

Admin

A user can manage long running instances of services in this environment.

Deployer

A user can deploy and delete services from this environment.

Builder

A user is allowed to download an offline version of this service (in a container for instance) or build a container image of the service. Granting this access to a user could expose secrets for external system access because the containers could contain the credentials required to access external services.

In DES versions prior to 12, access right has been based on read, write and download. These access rights are automatically migrated with following rules:

  • read is migrated to Performer

  • write is migrated to Admin and Deployer

  • download is migrated to Builder

Attributes

Production

A production environment guarantee that published services are immutable once published. This means that they can’t be deleted or overwritten (with the same version) but new services can be published. To delete a service in a production environment, the admin has to turn off the production flag, delete the service, then turn back the flag on.

Triggers activated

This setting configures the environment to never register triggers for services. This would mean that active triggers to start or continue a process (Kafka, RabbitMQ, REST messages, …​) are not activated on deployment. This attribute is immutable and can’t be changed after an environment was created.

Global access

Admins can make environments available (read, write, download) to all users of the instance without having to assign access to them. This is the equivalent of sharing with the virtual All users group.

Digital Distributed Containers Strategy

When subscribing to the Digital Distributed Containers optional subscription, an option allows to control how containers are built for this environment.
Not activating triggers for an environment is useful if you are using active triggers bound to message queues (such as Kafka and RabbitMQ) and do not want your service to connect to that environment on deployment but instead to run it in a Digital Distributed Container.

Digital distributed containers strategies

Require a Single Service Digital Distributed Container subscription.

Do not build containers.

No containers are built for this environment.

Build containers locally.

A Single Service new container is built for each deployment and stored locally. The Digital Enterprise Suite then acts as a container registry to allow pulling containers with a standard docker pull <image-name> command.

Push containers to an external registry.

A Single Service new container is built for each deployment and pushed to a remote registry. The registry needs to be visible from the Digital Entreprise Suite. A pattern can be provided to automatically determine the container name from the repository name, the deployed group/artifact and version.

Automation Service API

This section allows to set the default JSON output format when invoking the service API with a generic application/json Accept header for the REST. More details about the format are found in the Service Library documentation of the REST_API.