Approval workflow delays due to background job bottleneck in change management

PLM SAP PLM
, , , , , , , ,
1

Our engineering change approval workflows in SAP PLM 2020 are experiencing severe delays. Approvals that should trigger immediately are taking 15-30 minutes to reach approvers. I’ve traced this to background job processing bottlenecks.

Looking at SM37, I see the workflow background jobs (SWWDHEX, RSWWERRE) are queuing up during peak hours. The background job queue shows 40-50 jobs waiting while only 3-4 are actively processing. We have workflow runtime monitoring enabled, but I’m not sure how to interpret the data to identify the root cause.

I’ve also noticed that job prioritization doesn’t seem to be working - critical ECO approvals are stuck behind routine notification workflows. How can we optimize this to ensure timely approvals without overwhelming the system?

system 2

I’ll provide a systematic approach to resolve all three bottleneck areas:

Background Job Queue Optimization: Your primary issue is insufficient background processing capacity. Here’s a comprehensive fix:

  1. Increase Background Work Processes: Access transaction RZ10, edit your instance profile, and increase parameter rdisp/wp_no_btc. Current value is likely 3-5; increase to 12-15 for dedicated workflow processing. This requires system restart during maintenance window.

  2. Configure Dedicated Workflow Job Server Group: In transaction RZ12, create a new server group ‘WORKFLOW_PRIORITY’ and assign 4-5 background processes exclusively to it. Then in transaction SM36, configure SWWDHEX and RSWWERRE jobs to run on this dedicated group. This isolates workflow processing from other background jobs.

  3. Optimize Job Scheduling Intervals: Transaction SWWA → Workflow Runtime Configuration → Background Processing. Current setting is probably 5-minute intervals. Reduce to 1-minute intervals for SWWDHEX and 2-minute intervals for RSWWERRE. This ensures faster workflow event processing without overwhelming the system.

  4. Implement Job Parallelization: For SWWDHEX, enable parallel processing by copying the job and scheduling multiple instances with different start times (offset by 30 seconds). Each instance processes a subset of workflows based on workflow type. Configure in transaction SM36 with variant parameters for workflow type filtering.

  5. Monitor Queue Depth: Set up transaction SM37 monitoring alerts when job queue exceeds 20 waiting jobs. Use transaction CCMS (RZ20) to create custom alert for background job queue threshold.

Workflow Runtime Monitoring Analysis: Transaction SWI2_FREQ is your primary diagnostic tool. Here’s how to interpret the data:

  1. Event Queue Analysis: Check ‘Event Queue for Type Linkages’ - if you see >1,000 events queued, your event processing is saturated. Root causes:

    • Too many synchronous event triggers (change to asynchronous)
    • Inefficient event receiver determination
    • Missing event linkage indexes

  2. Workflow Log Analysis: Transaction SWI1 → Select ‘Technical Workflow Log’ → Filter by date range. Look for workflows stuck in ‘Started’ status for >10 minutes. These indicate processing delays. Common patterns:

    • Agent determination taking >5 seconds (optimize organizational structure queries)
    • Custom workflow tasks with long execution times (profile using ST05)
    • Deadlocks on workflow work items (check SM12 for SWWWIHEAD locks)

  3. Performance Statistics: Transaction SWI2_DURA shows workflow task duration statistics. Identify tasks exceeding 10 seconds execution time. For ECO approval workflows, typical tasks should complete in 1-3 seconds.

  4. Deadline Monitoring Performance: If SWWDHEX job runtime exceeds 5 minutes, you have too many active deadlines. Consider:

    • Archiving completed workflows (transaction SARA with object BC_WORKFLOW)
    • Reducing deadline precision from minutes to hours where acceptable
    • Disabling deadline monitoring for non-critical workflows

Job Prioritization Strategy: Implement multi-tier prioritization:

  1. Configure Job Classes: Transaction SM36 → Create job variants for workflow jobs:

    • Class A: Critical ECO approvals (SWWDHEX_ECO variant)
    • Class B: Standard change workflows (SWWDHEX_STD variant)
    • Class C: Notification workflows (SWWDHEX_NOTIF variant)

    Job class A gets 3x priority over class C in job scheduler.

  2. Workflow Priority Configuration: Transaction SWWA → Define priority levels:

    • Priority 1 (Highest): ECO approval workflows - process every 1 minute
    • Priority 2 (Medium): Standard change workflows - process every 3 minutes
    • Priority 3 (Low): Information workflows - process every 10 minutes

  3. Implement Workflow Type Filtering: Modify SWWDHEX job variants to process specific workflow types:

    • Create variant ECO_PRIORITY with workflow type filter for ECO approvals
    • Schedule this variant every 1 minute in class A
    • Create variant STANDARD with exclusion filter for ECOs
    • Schedule this variant every 5 minutes in class B

  4. Event Prioritization: Transaction SWETYPV → Configure event type linkages:

    • Set ECO creation events to ‘Background task - High priority’
    • Set approval events to ‘Background task - High priority’
    • Set notification events to ‘Background task - Standard priority’

  5. Real-time Processing for Critical Workflows: For truly urgent ECO approvals, implement synchronous processing:

    • Transaction SWWA → Enable ‘Start workflows synchronously’
    • Apply only to specific workflow types (ECO approvals)
    • This bypasses background job queue entirely but consumes dialog work processes

Additional Optimization Steps:

  1. Archive Old Workflows: Transaction SARA → Object BC_WORKFLOW Archive workflows older than 90 days to reduce SWWWIHEAD table size

    This improves query performance by 40-50%

  2. Optimize Agent Determination: If using organizational management for approvers:

    • Buffer organizational structure data (transaction OOAC)
    • Use direct database reads instead of API calls where possible
    • Cache agent determination results within workflow session

  3. Database Tuning: Ensure these tables have proper indexes:

    • SWWWIHEAD (workflow work items) - index on WI_STAT, WI_CD
    • SWWUSERWI (user work items) - index on WI_ID, WI_STAT
    • SWWEVENTQ (event queue) - index on EVENT_ID, CREATION_DATE

  4. Monitor and Alert: Set up transaction RZ20 alerts for:

    • Background job queue >25 waiting jobs
    • SWWDHEX runtime >10 minutes
    • Event queue depth >2,000 events

Expected Results After Implementation:

  • Approval notification delivery: 15-30 minutes → 1-2 minutes
  • Background job queue: 40-50 waiting → 5-10 waiting
  • ECO approval cycle time: Reduced by 70%
  • System scalability: Support 3x more concurrent workflows

Implement in phases: Week 1 (work process increase), Week 2 (job prioritization), Week 3 (workflow optimization), Week 4 (monitoring and fine-tuning).

This draft is based on general SAP PLM knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Your background work process configuration is likely the issue. Check SM50 during peak hours to see if all background processes are busy. You probably need to increase the number of background work processes in transaction RZ10. We increased from 5 to 10 and it eliminated most queuing.

4

The SWWDHEX job (workflow deadline monitoring) can become a bottleneck if you have many active workflows with deadlines. Check transaction SWI2_FREQ to see workflow event queue statistics. If you have thousands of events queued, consider splitting your workflow processing across multiple job servers or increasing the package size in SWWDHEX job parameters.

5

For job prioritization, you need to configure job classes properly. In SM36, check if your workflow jobs are assigned appropriate job classes (A, B, or C). Class A gets highest priority. Also look at transaction SWWA for workflow runtime configuration - you can define separate job queues for critical vs. routine workflows. We created a dedicated high-priority queue for ECO approvals.

6

Use transaction ST03N to analyze background job resource consumption. Look at the ‘Task Type Analysis’ for background processing. You might find that certain workflow tasks are consuming disproportionate CPU or database time. We discovered a custom workflow task that was doing full table scans, causing 80% of our delays.

9

Check the workflow event queue configuration in transaction SWETYPV. If event coupling is set to ‘wait’, events will queue up. Change to ‘background task’ with appropriate priority settings. Also verify in transaction SWU3 that your workflow customizing is complete - incomplete configuration can cause unexpected background processing delays.