Lesson 4 of 6
Triggering from S/4HANA and managing environments
11 min
Listen to this lesson
Fleet Customer Onboarding should start by itself when a business partner is created in SAP S/4HANA, and it should write the approved credit limit back. That means two connections: S/4HANA to BPA (the trigger) and BPA to S/4HANA (the action). Both must work in three landscapes, DEV, QA and PRD, each pointing at the right S/4HANA system. This lesson covers both directions and the environment variables that keep the landscapes apart.
Three ways to start a process from S/4HANA
| Trigger | How it works | Good for | Watch out for |
|---|---|---|---|
| Event trigger | S/4HANA publishes a business event (for example the business partner Created event) to an event broker; BPA receives it and starts the process | Reacting to standard business events without custom code in S/4HANA | Thin payloads: the event carries keys, so the process reads details with an action; every project subscribed to the event starts a process |
| API trigger | A caller posts to the process's API trigger endpoint with OAuth client credentials and the process inputs | Starting from custom ABAP, from an iFlow, or from another system | The caller needs credentials per environment; input structure must match the trigger |
| Form trigger | A person starts the process by submitting a form | Requests that start with a person, not a system event | No automatic link to the S/4HANA object unless the user enters it |
Trigger options for Contoso's onboarding process.
Contoso chose the event trigger. In SAP S/4HANA Private Edition, business events are published through the enterprise event enablement framework to a broker; Contoso uses the Event Mesh capability of SAP Integration Suite, as described in the business events course. SAP's developer tutorials also show SAP Integration Suite, advanced event mesh forwarding events to BPA with a REST delivery point that posts CloudEvents to BPA's events endpoint with OAuth client credentials from a BPA service key. Which broker and which setup your tenant supports depends on your landscape and entitlements; check the current SAP Help for event triggers.
The event type is the S/4HANA business partner Created event (in SAP's naming, sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1). Its payload carries the business partner key, not the full record, so the first step is an action that reads the partner. In the BPA Monitor, the acquired business events list shows events received in the last few days with their payload, which is the first place to look when a process does not start.
- Does S/4HANA publish a standard business event for the moment you care about?Yes → event trigger, then read details with an action · No → next question
- Does custom code or an integration flow decide when to start?Yes → API trigger with credentials per tenant · No → next question
- Does a person decide when to start?Yes → form trigger, with the S/4HANA key entered and validated · No → reconsider whether BPA is the right place
Actions and destinations
An action calls an API. You create an action project from an API specification (for example the S/4HANA business partner OData API from the SAP Business Accelerator Hub), choose the operations, and use the action in the process. The action does not hold a URL or credentials: at runtime it uses a BTP destination. For BPA to discover a destination, the destination needs the additional property sap.processautomation.enabled set to true, and it must be added to BPA in the Control Tower.
Environment variables
The process must not hard-code which destination it uses, or the QA instance would write to the DEV system. BPA solves this with project environment variables. Contoso's project has one variable, S4_SYSTEM, of type destination. The action is configured to use the variable. When the released version is deployed, BPA asks for a value for each variable, and the deployer picks the destination available in that tenant.
| Landscape | BTP subaccount | Paired S/4HANA | Value of S4_SYSTEM at deploy |
|---|---|---|---|
| DEV | cmc-ext-dev | CMD client 300 | CMC_S4HANA (pointing to CMD 300) |
| QA | cmc-ext-test | CMQ client 100 | CMC_S4HANA (pointing to CMQ 100) |
| PRD | cmc-ext-prod | CMP | CMC_S4HANA (pointing to CMP) |
Contoso keeps the destination name CMC_S4HANA identical in every subaccount; the subaccount decides which S/4HANA system it reaches.
API trigger in practice
Contoso also uses an API trigger for one case: re-onboarding a customer whose credit review expired. A nightly ABAP job in S/4HANA finds the partners and calls the process's API trigger through a destination to the BPA tenant, using OAuth client credentials from a BPA service key. The trigger defines the input structure; the job must send exactly that structure, and the credentials and endpoint differ per tenant, so they belong in the S/4HANA destination configuration for each landscape (CMD to DEV, CMQ to QA, CMP to PRD), never in the code. Test the trigger with a bad payload as well as a good one, to see how the caller learns about a rejected start.
Step by step: wiring the QA landscape
- Sam creates destination
CMC_S4HANAin cmc-ext-test, pointing to CMQ client 100 through the Cloud Connector, with the propertysap.processautomation.enabled = true. - Theo adds the destination in the BPA Control Tower of the QA tenant.
- Theo configures the business partner Created event for CMQ client 100 to reach the QA tenant only.
- The release manager deploys the released project version in QA and sets
S4_SYSTEMtoCMC_S4HANA. - Priya creates a business partner in CMQ and checks the acquired events list, then the new process instance.
What goes wrong in testing
- Cross-wired landscapes. CMQ events reach the DEV tenant, or the QA destination points at CMD. Test instances write credit limits into the wrong system.
- Duplicate starts. Two projects subscribe to the same event; one partner creates two onboarding instances.
- Thin payload assumed rich. The process maps a name from the event that the event never carries.
- Destination invisible. The property is missing, so the destination cannot be selected at deploy.
What would you do?
During QA testing, Priya creates a business partner in CMQ client 100. A new onboarding instance starts in the QA tenant, but after Dan approves, the credit limit appears in CMD, not CMQ. What should Theo check first?
- Processes start from S/4HANA by event trigger, API trigger, or a person's form.
- Business event payloads are thin: read details with an action.
- Actions call APIs through destinations; BPA needs sap.processautomation.enabled = true on the destination.
- Environment variables bind each deployment to its own tenant's destination.
Check your understanding · not graded
Lesson check
1. Why does the onboarding process start with an action that reads the partner?
2. Which destination property makes a destination discoverable for BPA?
3. What does an environment variable of type destination let Contoso do?
4. Two projects subscribe to the same business event. What happens?
5. Where can Theo see which business events reached the tenant?