- SAP Managed Tags:
Dear Community,
Couple of months ago we introduced the Shared Environment for SAP Build Process Automation. We described the main benefits compared to the public Environment here and here. We monitor the usage on a monthly basis and see millions of automation jobs and process instances which are now leveraging the Shared Environments.
Let's recap four important benefits:
- Project-version deployed within a shared environment is always the latest active;
- Dependencies within a specific shared environment are always the latest and consistent;
- A powerful sharing capability and privilege definition;
- Enhanced security with API calls.
Project-version deployed within a shared environment is always the latest active
After deploying a version, the previous version is non-longer "deployed". Previous version non-longer used can then easily deleted from the Lobby.
Let's assume you have a project with 10 versions. The version 1.0.8 is deployed and the version 1.0.9 should be deployed. While deploying this version the previous version 1.0.8 is non-longer activated. Existing tasks - if any - are gracefully finished. If needed (cleaning) you can easily delete the version 1.0.8 which is unused.
| 
| 
|
When undeploying a project within a shared environment, the workflow definition remains deployed... but inactive. Keeping the history of past instances.
Dependencies within a specific shared environment are always the "latest" and consistent
- Typical scenario:
- Let's assume a project A is deployed with a dependent project D1 with version 1.0.40
- Let's assume a project B is deployed with the same dependent project D1 with version 1.0.42
- Project A will automatically leverage the dependent project D1 with the version 1.0.42
- The semantic versioning works for the minor and patch:
- When attempting to deploy a project C with the same dependent project D1 with the version 2.0.0, deployment will be blocked until the project A and B are upgraded with the version 2.X.X
- Deploying this project in another Shared Environment is however doable
A powerful sharing capability and privilege definition
A Shared Environment comes with different privileges. By default, a ProcessAutomationDeveloper CANNOT see a Shared Environment by default. All content deployed are not only isolated, but the user cannot see until the Shared Environment admin enables it:
- Monitor is the minimum right for allowing others to see the content deployed and the jobs
- View logs is the right for allowing users to see the "context", inputs/outputs jobs
- Deploy is the right for allowing users to deploy within a shared environment
- Administrate is the right for allowing users to all tasks mentioned before and the ability to share to others
- Execute - for enabling the execution of workflow or Decision or Form access
- Supervise - for enabling the Process Visibility Scenario Dashboard access
Finally, agents belonging to a shared environment will take care ONLY to the projects deployed in this specific shared environment.
With the ProcessAutomationDelegate, you can have dedicated users focusing on monitoring only for example without the ability to create new project.
Enhanced security with API calls and technical user (API-Key)
For calling a process deployed within a shared environment you'll need to use the extra parameter environmentId (leveraging the environment identifier).
API Key is an extra layer of security. There are different rights to fine tune while creating an API Key. API Key requires ProcessAutomationAdmin for security reasons.
How to deploy a project?
- First thing to do is to create your Shared Environment and add some users within. Choose carefully the identifier: When promoting the content from a development tenant to a production tenant you might want to keep the name identical across tenants.
- From the Studio, click Deploy and you should be able to choose the corresponding Shared Environment
- Once deployed the content is now available and can be called
How to start a workflow definition deployed within a shared environment?
Compared to a process deployed within the public environment, an explicit API trigger is needed. Once created for starting in an instance you will need to provide:
- environmentId as query
- api-key
Once done, calling APIs will be doable.
Can I deploy within a shared environment AND public environment?
Yes, you can deploy a project within a Shared Environment while keeping the public environment.
You can deploy the same project or different project-version:
- Project A with version 1.0.41 is deployed within Shared Environment E1
- Project A with version 1.0.42 is deployed within Shared Environment E2
- Project A with version 1.0.21 is still deployed within Public Environment
Can I undeploy?
Please note that undeploying a project with Process within the Public Environment will still undeploy and remove all past instances. On a development tenant:
- Undeploy the project-version "active" within the public environment first to start "clean"
- All versions will be also undeployed if there is a process
- Deploy the project within a shared environment
How to undeploy inactive project-versions?
Within the Public Environment, activate the switch "Show inactive versions" for displaying all previous and inactive versions:
Why no longer use Public Environment?
- All projects deployed within the Public Environment are accessible for the tenant users. That means a user who knows a form url can trigger it.
- All versions deployed for a given project are deployed "for ever". Cleaning old versions might take more time.
- When using automation and agents, the jobs are assigned with the agent pool. Shared Environment is more efficient for that end and robust compared to agent attributes.
- Public Environment will be deprecated and after a transition period:
- New project won't be allowed to be deployed
- New project-version won't be allowed to be deployed
- New jobs won't be allowed to be launched
1 Comment
