Dear Community,

In the coming weeks we are providing a new governance capability with Environments for SAP Build Process Automation.

What is Environment?

An Environment, and more specifically a Shared Environment, is a virtual location within your SAP Build Process Automation subscription where projects are deployed. In deployed projects you can use artifacts, such as triggers, workflow definitions, API keys… and can assign resources such as Agents. The output of these artifacts are automation jobs and workflow instances.

Build Process Automation Artifacts DT-RT

When a project is deployed in the public or default environment (which belongs to the tenant), users can access all related artifacts, depending on the security level assigned to the users. When a project is deployed within the public or default environment, all agents that have been declared in Agent Management will be involved for taking the job by a process/workflow or by a trigger. Agent Attributes can be used to improve job distribution. The Desktop Agent performs the task (automation job) on behalf of a user.

A shared environment allows you to increase the security of deployed projects and the corresponding artifacts and resources. A shared environment must be created by users with the Process Automation Admin role and shared to users with the Process Automation Developer role.

A shared environment allow to isolate the resources and the project with specific rights associated to a given environment. For instance, two environments can be defined such as one for “Material Management” and one for “Financial Consolidation” and the projects related to the two environments might not use the same settings. For more information, our documentation will be soon available.

Using Environments within the Studio

Access to available environments is made easy while deploying a project. When a project version is deployed in a shared environment, if a previous version exists, this is automatically undeployed behind the scenes. The concept of deployed and active is simplified to deployed in a shared environment.

Differences between Public Environment and Shared Environments

• In a public environment, multiple versions can be deployed but only one is actually active
• In a shared environment, the latest version deployed is implicitly active
• A project-version can be deployed in multiple shared environments side by side

A semantic deployment

The version first time you deploy a project after releasing a version, simply click Deploy and the list of available environments will be available. By selecting the environment, the button will display different meanings:

• Deploy – because it’s the first time you will deploy this project within this environment
• Upgrade – because you will deploy a newer version within this environment
• Redeploy – because you will deploy the same version within this environment
• Downgrade – because you will deploy a lower version within this environment

Because project can be deployed in multiple environments, we’ve updated the Studio:

Where are now the existing settings?

All existing settings are available in the Environment view for a specific environment (including the public environment which will be surfaced):

Control Tower > Environments

Moved entries / views

(*) API Keys is still accessible for cross environments (Control Tower > Others > API Keys)

Available artifacts in Shared Environments

The list of artifacts used when designing projects that are available in shared environments will continue to grow. The following artifacts and resources are currently available (for an accurate list please check our SAP Note 3394899 or the documentation) :

Design-Time artifacts

Run-Time artifacts

Final thoughts

“Rome was not built in a day”… by delivering “now” shared environment with a initial scope targeting SAP Intelligent RPA use cases we are aiming to increase over time the artifacts availability. Stay tuned for more to come!

More information:

• SAP Note 3394899
• Help Portal
• Environment Topic (soon)