Lesson 3 of 6
Joule skills: API calls, destinations and process triggers
10 min
Listen to this lesson
Skills are where the agent touches SAP S/4HANA. They are deterministic, testable and reusable, which makes them the most important part to get right. Elena builds two: Get Fleet Order Status (read) and Request Expedite (starts an SAP Build Process Automation approval).
Step 1: actions and destinations
Skills call APIs through actions. In the SAP Build lobby, under Connectors, Elena creates an action project from the API specifications on the SAP Business Accelerator Hub: the sales order API (API_SALES_ORDER_SRV), the outbound delivery API (API_OUTBOUND_DELIVERY_SRV) and the billing document API (API_BILLING_DOCUMENT_SRV). She keeps only the GET operations and fields the skill needs, tests each action against a destination, and publishes the action project. Check the API names and versions for your release on the Business Accelerator Hub; some have newer OData V4 successors.
The destination is defined in the BTP cockpit (Connectivity > Destinations) and points to SAP S/4HANA through the Cloud Connector for a Private Edition system. Contoso's is CMC_S4HANA in each subaccount, pointing to CMD client 300, CMQ client 100 and CMP respectively. SAP's tutorial adds properties that make a destination usable by process automation and actions, then assigns it to environments in Control Tower. Inside the skill you do not hard-code it: you create a destination variable and bind the real destination at deployment.
- Find the APISAP Business Accelerator Hub: sales order, outbound delivery, billing document APIs for your release
- Create action projectSAP Build lobby, Connectors, Actions: import the API specification
- TrimKeep only the GET operations and fields the skill needs
- TestRun each action against the CMC_S4HANA destination in cmc-ext-dev
- PublishRelease the action project so skills can browse it in Call Action
Trimming matters more than it looks. Every field an action returns is a field the skill can map and the agent may read. Keeping the action to the status fields the use case needs reduces data exposure, makes outputs easier to map, and keeps responses fast. When SAP publishes a newer version of an API, Elena creates a new action project version, retests the skills against it, and releases them together, so a hub update never changes production behavior silently.
Step 2: build the skill
- In the project, choose Create > Joule Skill; write a precise name and description (Joule uses the description to pick the skill).
- Open Parameters and configure Skill Inputs (SalesOrder, CustomerPO, both optional, with clear descriptions) and Skill Outputs (order status, delivery number, goods issue date, billing document, block reason).
- Add Call Action for the sales order GET; create the destination variable; map the input to the filter (order number or PurchaseOrderByCustomer).
- Add a Condition: if no order is found, end with a clear "not found" output instead of an empty answer.
- Add Call Action steps for delivery and billing, mapping the order number from the first output.
- Map the End element to the skill outputs; decide whether Joule may generate the response or whether you use a Send Message template.
- Save, check the Design Console for errors, then Release and Deploy to your private environment and test.
Step 3: trigger a process for anything that changes data
The Request Expedite skill does not change the delivery. It uses a process step to start an SAP Build Process Automation workflow with the order number, requested date and reason; the workflow sends an approval form to the shipping supervisor at shipping point 1710, and only an approved request changes anything in SAP S/4HANA, through the normal delivery transaction. Before the skill triggers the process, it shows the clerk a confirmation with the details. This keeps the agent on the safe side of the matrix from lesson 2 and gives the business an audit trail it already understands.
| Destination authentication | Backend sees | Use for |
|---|---|---|
| Principal propagation (user identity) | The clerk's own user and authorizations | Business data reads and any action that must respect the user's roles |
| Technical user (basic or OAuth client credentials) | One technical user for everyone | Only non-sensitive reference data, with a documented exception |
| No authentication (mock service) | Nothing; test data | Tutorials and early prototypes only |
Authentication is a design decision with security consequences. Contoso uses principal propagation for order data.
What would you do?
The skill works in Elena's private environment but returns "not found" for every order in the test environment. The destination check in the BTP cockpit is green. What is the most likely cause?
- Actions wrap APIs (from the SAP Business Accelerator Hub); destinations connect to SAP S/4HANA through the Cloud Connector.
- Skills use destination variables, inputs, Call Action, Condition, process steps and outputs; release and deploy per environment.
- Anything that changes data goes through a confirmed process with an approver, not a direct write.
- Use principal propagation for business data and test with real roles, including negative tests.
Check your understanding · not graded
Lesson check
1. Why does a skill use a destination variable instead of a fixed destination?
2. Which authentication lets SAP S/4HANA check the clerk's own authorizations?
3. How should the Request Expedite skill change a delivery date?
4. A skill returns a raw OData error to the clerk. What does SAP's guidance recommend?