Purchase order approval workflow hangs at manager level when processing bulk orders

ERP SAP S/4HANA
, , , , , , , ,
1

Our purchase order approval workflow in SAP S/4HANA 1909 frequently hangs at the manager approval step when we submit bulk PO batches (50+ orders). Using SWWIMADM, we see work items stuck in READY status but not being processed.

Workflow diagnostics show:


Workflow queue: 847 items waiting
Active work items: 12 of 847 processing
Average wait time: 45-90 minutes
Workflow rule evaluation: 8-12 seconds per item

We’ve noticed that parallel approval paths and CDS view queries for manager determination are particularly slow. The workflow queue tuning hasn’t been adjusted since implementation. Is there a way to optimize workflow processing and enable batch approval capabilities?

2

Your workflow background job SWWDHEX might not be scheduled frequently enough. Check transaction SM36 and verify that SWWDHEX runs at least every 5 minutes during business hours. This job processes deadline monitoring and triggers waiting work items. Also review SWU2 to check for any workflow customizing errors that could cause processing delays. Ensure workflow event queue (transaction SWEQADM) isn’t backed up with unprocessed events.

3

Have you considered implementing batch approval functionality? Instead of individual work items for each PO, group related purchase orders and create a single approval work item for the batch. This reduces workflow queue load from 50 individual items to 1 batch item. You can customize workflow template WS20000129 to support mass approval scenarios where managers can approve/reject multiple POs simultaneously through a custom transaction or Fiori app.

4

Comprehensive solution to resolve workflow performance issues:

1. Workflow Queue Tuning:

Increase parallel workflow processing capacity by modifying workflow runtime configuration:

Transaction SWWA (Workflow Runtime Customizing):

  • Enable parallel processing: Set parameter WF_PARALLEL_PROCESSING = ‘X’
  • Increase max parallel work items: WF_MAX_PARALLEL = 20 (from default 5)
  • Configure queue processing interval: WF_QUEUE_INTERVAL = 30 seconds

Instance profile parameters:


rdisp/wp_no_dia = 15
rdisp/wp_no_btc = 8
rdis/max_wf_runtime = 600

This dedicates adequate dialog work processes for workflow execution while preventing single workflow from monopolizing resources.

2. Parallel Approval Paths Implementation:

Redesign workflow to support parallel approval processing:

// Pseudocode - Parallel approval workflow:

  1. On PO submission, split approval requirements by criteria (value, category, plant)
  2. Create parallel workflow branches using FORK activity in workflow builder
  3. Each branch processes subset of approvers simultaneously
  4. Use JOIN activity to synchronize when all parallel approvals complete
  5. Implement timeout handling for non-responsive approvers with escalation // Reference: SAP workflow pattern WS20000129 for parallel approval template

Configure workflow container to track parallel branch status and implement intelligent routing that bypasses unnecessary approval steps based on PO characteristics.

3. CDS View Optimization:

The 8-12 second manager determination is caused by inefficient CDS view queries. Optimize as follows:

Caching Strategy: Implement approval hierarchy caching using ABAP shared memory:


CLASS zcl_approval_cache DEFINITION.
  PUBLIC SECTION.
    CLASS-METHODS get_approver
      IMPORTING iv_plant TYPE werks_d
                iv_amount TYPE wrbtr
      RETURNING VALUE(rv_approver) TYPE syuname.
ENDMETHODS.

Cache stores pre-calculated approval hierarchies refreshed hourly via background job. This reduces CDS view execution from 8-12 seconds to <100ms for cached entries.

CDS View Refactoring: Analyze existing CDS views with ABAP SQL Monitor (transaction SQLM):

  • Identify views with >1000ms execution time
  • Add WHERE clause filters early in view definition
  • Implement association cardinality hints [0..1] or [1..1] where applicable
  • Consider view materialization for complex organizational hierarchies

Example optimized CDS view structure:


@AbapCatalog.sqlViewName: 'ZAPPROVAL_V'
DEFINE VIEW Z_Approval_Hierarchy
  WITH PARAMETERS p_date : abap.dats
  AS SELECT FROM hrp1001 AS rel
    ASSOCIATION [0..1] TO hrp1000 AS org
      ON org.objid = rel.sobid
  WHERE rel.plvar = '01'
    AND rel.rsign = 'A'
    AND rel.relat = '002'
    AND rel.begda <= $parameters.p_date

4. Batch Approval Processing:

Implement batch approval functionality to reduce workflow queue load:

Batch Grouping Logic:

  • Group POs by common approval criteria (plant, purchasing group, value range)
  • Create single work item representing batch instead of individual items
  • Custom approval transaction displays all POs in batch for simultaneous review

Implementation approach:


// Pseudocode - Batch approval workflow:
1. Collect POs submitted within 15-minute window
2. Group by PLANT + PURCH_GROUP + VALUE_RANGE using clustering algorithm
3. Create batch container object with PO list and batch ID
4. Generate single work item with custom method APPROVE_BATCH
5. On approval, iterate through batch and update all PO statuses
6. Handle partial approvals (some POs rejected) with split logic
// See SAP Note 2845123 for batch approval framework

Develop custom Fiori app or modify transaction ME29N to support batch approval interface showing grouped POs with bulk action buttons.

5. Background Job Optimization:

Ensure workflow background jobs run optimally:

SWWDHEX (Deadline Monitoring):

  • Schedule every 3 minutes during business hours (vs. default 15 minutes)
  • Use job class ‘A’ for high priority
  • Monitor in SM37 to ensure no delays

SWEQADM (Event Queue Processing):

  • Verify event queue not backed up (transaction SWEQADM)
  • If queue length >1000, increase processing frequency
  • Configure event linkage in SWETYPV to ensure PO events properly registered

6. Workflow Monitoring & Alerting:

Implement proactive monitoring:

  • Transaction SWWL (workflow log) - monitor for error patterns
  • Custom ABAP report checking SWWWIHEAD table for items in READY status >30 minutes
  • Alert procurement managers when queue length exceeds threshold (500 items)
  • Weekly analysis of workflow statistics (transaction SWI2_FREQ) to identify bottlenecks

Expected Results:

  • Workflow queue processing time: Reduced from 45-90 minutes to 5-10 minutes
  • Manager determination: Reduced from 8-12 seconds to <500ms (with caching)
  • Parallel processing capacity: 20 concurrent work items vs. previous 12
  • Batch approval: 50 POs processed as single work item (98% reduction in queue load)
  • Overall approval cycle time: Improved from 2-3 hours to 15-20 minutes for bulk submissions

Implement in phases: Start with workflow queue tuning and caching (immediate impact), then parallel approval paths, finally batch approval functionality. Test thoroughly in quality system with production-volume data before transport.

5

The 8-12 second rule evaluation time is excessive. Your workflow probably uses complex CDS views or function modules for manager determination. Use transaction SWUD to analyze workflow definition and identify expensive operations. Consider implementing rule caching using shared memory objects (transaction SHMA) to store frequently accessed approval hierarchies. Pre-calculate manager assignments during PO creation rather than dynamically during workflow execution.

6

Analyze your database execution plan for the CDS views used in manager determination. Use transaction SWELS to enable workflow trace, then examine which database queries are slow in ST05. Your CDS views probably join multiple organizational management tables (HRP1000, HRP1001) without proper indexing. Consider materializing these views or implementing a custom Z-table that maintains flattened approval hierarchy data, updated nightly via batch job.

7

Look into SAP’s event-driven workflow architecture improvements in S/4HANA. You might be using legacy workflow technology that doesn’t leverage modern event mesh capabilities. Consider migrating to BRFplus rules for approval determination instead of custom ABAP code - it’s significantly faster and provides better caching mechanisms.