Workflow Part 2: Building Templates — Steps, Containers and Binding
Build a workflow template in SWDD: activity, user decision, condition, multiple condition, fork, loop and wait steps; the workflow container and task containers; data binding between event, workflow, task and method; start conditions; deadlines; and testing with SWUS and the workflow log.
Explanation
📌 KEY POINTS
✅ Step types: activity (runs a task), user decision (approve/reject buttons), condition/multiple condition (branch on data), fork (parallel), loop (repeat), wait for event, send mail, container operation.
✅ The workflow container holds instance data; binding maps data explicitly between event → workflow, workflow → task, task → method (and back).
✅ Start conditions (SWB_COND) on the event linkage make sure the workflow starts only for relevant cases (e.g. document type, amount).
⚠️ Binding errors are the most common build error: a missing binding silently passes empty values — the step "works" but decisions are based on nothing.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 explained the architecture. Now we build a simple approval template.
━━━━━━━━━━━━━━━━━━━━
▶ 1. STEP TYPES
- Activity: executes a single-step task (method of BOR object or IF_WORKFLOW class) — dialog or background.
- User decision: work item with decision options (Approve/Reject); result branches.
- Condition / multiple condition: branches by container values (e.g. amount > 10,000).
- Fork: parallel branches with "n of m" completion.
- Loop (UNTIL/WHILE): repeat, e.g. rework cycles.
- Wait for event: pause until an event (e.g. document changed).
- Send mail, container operation, process control (cancel work items).
━━━━━━━━━━━━━━━━━━━━
▶ 2. CONTAINERS AND BINDING
- Workflow container elements: e.g. PurchaseOrder (BOR BUS2012 or class reference), Amount, Approver, Decision.
- Event → workflow binding: _EVT_OBJECT → PurchaseOrder.
- Workflow → task binding: PurchaseOrder → _WI_OBJECT_ID; task → method binding: parameters.
- Check binding with the binding editor; the "Check" in SWDD shows missing required bindings.
━━━━━━━━━━━━━━━━━━━━
▶ 3. START CONDITIONS
SWB_COND (or event linkage): e.g. only if PO document type = 'NB' and total value > 5,000 — avoids unnecessary instances.
━━━━━━━━━━━━━━━━━━━━
▶ 4. DEADLINES
Requested/latest start and end per step; missed deadline → notification or modelled escalation branch (Part 5).
━━━━━━━━━━━━━━━━━━━━
▶ 5. TESTING
- SWUS: start the workflow with test container values.
- Workflow log (from SBWP or SWI1/SWIA): technical view shows container, binding, agents per step.
- SWEL: event trace to check whether the event started the workflow.
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- SWDD: create a template with container element PurchaseOrder (BUS2012).
- Add a user decision "Approve PO &PurchaseOrder.PurchaseOrder&" with two outcomes and a condition on the amount before it.
- Link it to the event in SWE2 with a start condition; test with SWUS and check the log.
✅ CHECKPOINT: you can build a template with correct containers, binding and start conditions.
Code example
* ===== Template design (SWDD) =====* Container: PurchaseOrder TYPE BOR BUS2012 (import)* Amount TYPE BAPIEKPOC-NET_VALUE (derived via container operation or method)* Decision TYPE CHAR10* Approver TYPE SWHACTOR* Steps:* 1 Activity "Read PO data" task TS9xxxxxxx method GetDetail (background)* binding PurchaseOrder -> _WI_Object_ID, result -> Amount* 2 Condition Amount > 10000* true -> 3 User decision "Approve PO &PurchaseOrder&" (Approve / Reject)* false -> 4 Activity "Release automatically" (background)* 5 Condition decision = Approve -> release / notify requester * ===== Workflow-enabled class used by activity steps (IF_WORKFLOW) =====CLASS zcl_wf_po DEFINITION PUBLIC FINAL CREATE PUBLIC. PUBLIC SECTION. INTERFACES if_workflow. DATA mv_ebeln TYPE ebeln READ-ONLY. METHODS constructor IMPORTING iv_ebeln TYPE ebeln. METHODS get_amount RETURNING VALUE(rv_amount) TYPE netwr.ENDCLASS. CLASS zcl_wf_po IMPLEMENTATION. METHOD constructor. mv_ebeln = iv_ebeln. ENDMETHOD. METHOD get_amount. SELECT SUM( netwr ) FROM ekpo INTO rv_amount WHERE ebeln = mv_ebeln. ENDMETHOD.* (IF_WORKFLOW methods BI_PERSISTENT~FIND_BY_LPOR / LPOR / REFRESH and* BI_OBJECT~DEFAULT_ATTRIBUTE_VALUE etc. must be implemented - left empty/simple here) METHOD bi_persistent~find_by_lpor. ENDMETHOD. METHOD bi_persistent~lpor. ENDMETHOD. METHOD bi_persistent~refresh. ENDMETHOD. METHOD bi_object~default_attribute_value. ENDMETHOD. METHOD bi_object~execute_default_method. ENDMETHOD. METHOD bi_object~release. ENDMETHOD.ENDCLASS. * ===== Test =====* SWUS : start template with PurchaseOrder = 4500001234* SWI1 : workflow log -> technical view -> container and binding per stepReal project scenario
A PO approval workflow routed every PO to the same fallback approver. The log showed the Amount element was always 0: the binding from the "Read PO data" step result to the workflow container had been deleted during a change, so the condition always took the "small amount" branch — and the approver rule got no cost center.
Restoring the binding and adding a check step ("Amount initial → error branch") made the workflow robust. SWUS tests with real PO numbers became part of every transport.
Common mistakes
- Missing or wrong bindings.
- No start condition (workflows for every event).
- Business logic scattered in container operations.
- Not testing with real data via SWUS.
- Deadlines without escalation handling.
Best practices
- Explicit, checked bindings at each level.
- Start conditions for relevance.
- Logic in class/BOR methods, flow in template.
- Test with SWUS and read logs.
- Model escalation for deadlines.
Interview angle
Questions: "What step types exist in a workflow?", "What is binding?", "How do you prevent a workflow from starting for every event?"
Strong answer: activity, user decision, condition/multiple condition, fork, loop, wait for event, mail, container operation; containers per workflow/task/method with explicit binding (_EVT_OBJECT, _WI_OBJECT_ID); start conditions via SWB_COND/event linkage; deadlines; test SWUS and logs SWI1/SWIA, SWEL.
Practice this lesson
Quick check
1. A workflow step works technically but decisions are based on an empty amount. Most likely cause?
2. A workflow starts for every purchase order change, but should run only for one document type above a value. What should be added?
3. Which step type gives the agent Approve/Reject buttons and branches on the choice?
Interview questions
1. Describe the role of the Workflow Container and Binding in SAP Business Workflow. How do you pass data from a workflow to a task and back?
Answer it in your own words first, then compare.
2. An invoice approval must go to the cost center owner and escalate to the finance controller if not approved within two days. How do you build it in the Workflow Builder?
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.