SAP Business Workflow

SAP Business Workflow separates the definition of a process from its execution:

1. A developer creates a workflow definition in the Workflow Builder. The definition is a sequence of steps: some control the flow (conditions, loops, parallel branches, waits), others reference tasks.
2. Each task points to a method of an object type, such as a Business Object Repository (BOR) object or an ABAP class that implements the interface IF_WORKFLOW, and runs either in the background or as a dialog step for a person.
3. Activating the definition generates a runtime version. Instances that are already running keep the version they started with.
4. A triggering event, such as a business document being created or changed, starts the workflow automatically; users can also start workflows manually.
5. At runtime the work item manager creates work items, determines agents from the organizational plan, roles or rules, and monitors deadlines.
6. Agents execute their work items in their inbox, and each step is recorded in the workflow log.

SAP Business Workflow is an event-driven engine that combines existing SAP transactions into a process without changing those transactions.

Day-to-day SAP Business Workflow development and administration happens in these SAP GUI transactions rather than in SAP Fiori apps.

• Modeling depth: conditions, loops, parallel branches, deadlines, escalations and container data cover complex approval and coordination logic.
• Native to the business object: workflows react to events of SAP documents and call SAP transactions and methods directly, with no integration layer between the workflow and the data.
• Built-in operations tooling: event traces, workflow logs, work item selection, administrator processing and workload analysis ship with the engine.
• SAP-delivered templates: SAP ships workflow templates for many processes that need limited implementation effort.
• Foundation for newer tools: flexible workflow extends the engine, and My Inbox and SAP Task Center can consume its tasks.

For processes that live inside one ABAP system, SAP Business Workflow remains the deepest modeling option SAP offers on the ABAP stack.

• Developer-owned. Definitions are built in SAP GUI by workflow developers and moved through transports. Process owners depend on IT for each rule change.
• One ABAP system. A workflow orchestrates objects inside the system it runs in. Steps in other systems need RFC, web services or an integration with a service such as SAP Build Process Automation.
• Knowledge concentration. Custom workflows accumulate over years. When their authors leave, the logic is readable only in the Workflow Builder and in the code behind tasks and rules.
• Custom code to carry. Custom definitions, tasks and agent rules are development objects that every upgrade and conversion must assess.
• Instance-level visibility. The workflow log explains one instance; a business view across many instances and adjacent systems is assembled from reports.

These boundaries follow from the design: SAP Business Workflow is a backend engine for processes inside one ABAP system, built and run by IT.

SAP Business Workflow is part of the ABAP platform, so it runs in SAP ERP, SAP S/4HANA on-premise and SAP S/4HANA Cloud Private Edition, where customers can still model their own workflows in the Workflow Builder. In SAP S/4HANA Cloud Public Edition, customers have no SAP GUI access to the Workflow Builder; SAP-delivered approvals are configured in the flexible workflow apps. SAP documents flexible workflow as the default workflow engine in SAP S/4HANA for a range of approval scenarios. The ABAP platform also integrates with SAP Build Process Automation and SAP Task Center on SAP BTP. The deployment option decides whether SAP Business Workflow is a modeling tool for the customer or an engine running underneath delivered scenarios.

Work from configuration to event to work item to agent:

1. Run SWU3 and confirm the runtime area is free of errors. A missing WF-BATCH user or a broken RFC destination stops background steps.
2. Switch on the event trace with SWE4, repeat the business action and read the trace in SWEL. No event means the application did not raise one; an event without a started workflow points to an inactive or faulty type linkage in SWE2.
3. Find the work item in SWI1 by task, date or status, and read the workflow log to see the last completed step.
4. If the work item has no agent, check the task's possible agents, the organizational plan and any agent determination rule.
5. Only then let a workflow administrator act on the work item, for example from SWIA, with the administrator functions available in the release.

Following this order resolves most SAP Business Workflow incidents without touching the workflow definition.