Workflow
ABAP Developmentintermediate

Workflow Part 2: Building Templates — Steps, Containers and Binding

Key takeaway

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

  1. SWDD: create a template with container element PurchaseOrder (BUS2012).
  2. Add a user decision "Approve PO &PurchaseOrder.PurchaseOrder&" with two outcomes and a condition on the amount before it.
  3. 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

ABAP Code
* ===== 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 step

Real 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.

Practice more with Interview AI →

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.

More lessons in this topic

Interview questions on this topic

Related SAP topics