SAP Build Process Automation - Transition guidelines from Public Environment to Shared Environments

[Alex-Fortin]

Dear Community,

In a previous blog post "How to transition to Shared Environments - getting started" we provided a getting started on how to transition from Public Environment to Shared Environment. Let's discover the "transition guidelines":

Is the project currently deployed on public environment?

• If the project is not currently deployed on a public environment, you can simply create a shared environment and deploy.
• If the project is currently deployed on a public environment and you don't need to keep the past instances (typically in a development tenant) you should consider:
  • Undeploy on public environment
  • Deploy on a shared environment and test the outcome
• If the project is currently deployed on a public environment and you need to keep the past instances (typically in a Test or Production tenant) you should consider:
  
  • Deploy on a shared environment and test the outcome first
  • Stop using on public environment

Are you using "API Trigger" (*)?

Let's see the difference between a Process/Workflow deployed within a Public Environment compared to a Shared Environment:

• When a process is deployed within the Public Environment, you can click on "Start Instance" to test your workflow, and quickly after the process is started
• When the SAME process is deployed within a Shared Environment, clicking on "Start Instance" won't be possible and you'll end up with an error.

How to fix (**)...

1. Open the corresponding process
2. Add a trigger
3. Select API Trigger
4. Provide a name
5. Your process contains now an API Trigger

How to test...

You can now click the "start instance"

How to call an API Trigger with Environment?

Calling an API with an environment means an extra parameter:

Example with an Action Project

Using your favorite API development tool, you'll need:

• Add the environment parameter
• Add an API Key
• Test!

Development Tenant VS. Production Tenant

It's a good practice to create on both tenants the same environment id (identifier). The only difference between the two tenants would be the API Keys.

More information about:

• API Keys - help topic
• Processes and Workflows within Environment - help topic
• Manage Destinations - help topic
• Triggers - help topic
• Add an API trigger to a project - help topic

[jorge_gutirrez]

For proper application lifecycle management, we initially had to create several subaccounts (development, testing, and production). Even today, we continue to use this three-subaccount organization, deploying to the public environment of each of them. We understand that after a transition to shared environments, our organization would become outdated. With the availability of shared environments, it makes no sense to have more than one subaccount with its own BPA service subscription. What makes sense is to have several shared environments within a single subaccount. How do you see this?

[Mell]

Hello Alex,

Thank you for the great and informative blog post!

We have a quick question regarding the recent changes.
How will these updates impact Business Application Studio Workflows?

Currently, in Business Application Studio, we don’t have the option to select the target environment for deployment, it always deploys directly to the Public Environment. With the new changes, what should we expect going forward?

Also, is there now a way to deploy to a shared environment from within Business Application Studio?

Thank you very much in advance for your clarifications!

[Romiek]

Hello Alex,

I also need a solution for Business Application Studio Workflows. Any tips how to handle the shared environment with BAS workflows?

Thank you!