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
|
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. |
History enabled |
This setting configures the environment to keep instance information after its completion. Either by successfully reaching the end or after being aborted. |
Global access |
Admins can make environments available (none, performer) 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 |
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.