Automated work order dispatch from SAP to shop floor using REST API

I wanted to share our successful implementation of automated work order dispatch between SAP ERP and Aveva MES shop floor control (AM 2022.1). Before this project, production supervisors manually entered work orders from printed SAP reports into MES - a process taking 45-60 minutes per shift and prone to data entry errors.

We built a REST API integration that polls SAP for released production orders every 5 minutes and automatically creates corresponding work orders in MES with full routing, material requirements, and resource assignments. The implementation achieved 85% reduction in manual data entry time and virtually eliminated transcription errors.

The integration handles status synchronization bidirectionally - when operators start/complete operations in MES, status updates flow back to SAP in real-time. This has dramatically improved our production visibility and planning accuracy. Happy to discuss technical details for anyone considering similar automation.

We’re integrating with SAP PP module specifically. For the data mapping, we created a comprehensive mapping document covering about 35 key fields. The trickiest part was operation sequencing - SAP uses operation numbers like 0010, 0020, 0030 while MES expects sequential integers. We implemented a transformation layer that renumbers operations while preserving dependencies. Material assignments were relatively straightforward using SAP component numbers mapped to MES material master records.

How are you handling status synchronization back to SAP? That’s always the challenging direction. Do you update SAP operation confirmations (CO11N transactions) via API, or are you using a different mechanism? Also, what’s your approach when operators split or combine operations in MES - does that cause conflicts in SAP?

Great questions from both of you. Let me provide comprehensive details on our implementation:

SAP-to-MES API Mapping:

We created a detailed mapping specification covering these key areas:

Production Order Header:


SAP Field → MES Field
AUFNR (Order Number) → workOrderNumber
MATNR (Material) → productCode
GAMNG (Order Quantity) → targetQuantity
GSTRPGLTRP (Dates) → scheduledStartDate, scheduledEndDate
WERKS (Plant) → facilityCode

Operation Details: SAP operations (AFVC table) map to MES routing steps. Key transformation:

  • SAP operation number (0010, 0020) → MES sequence (1, 2, 3)
  • ARBPL (Work Center) → MES resourceCode
  • VORNR (Operation) → operationCode
  • VGW01-VGW06 (Standard values) → setupTime, runTime, teardownTime

Material Components: SAP BOM components (RESB table) → MES material requirements:

  • MATNR → materialCode
  • BDMNG → requiredQuantity
  • LGORT → storageLocation
  • RSPOS → bomPosition (for sequencing)

Automated Polling Mechanism:

Our integration service architecture:

  1. Polling Schedule: Runs every 5 minutes via scheduled task
  2. SAP Query: OData service call to retrieve orders:

GET /sap/opu/odata/sap/API_PROD_ORDER_SRV/
ProductionOrder?
$filter=ReleasedDate ge '2024-12-16T13:00:00'
and Status eq 'REL'
$expand=Operation,Component
  1. Change Detection: Maintains state table tracking last processed timestamp and order versions
  2. Batch Processing: Groups orders into batches of 20 for efficient MES API calls
  3. Connection Pooling: Maintains 5 persistent SAP OData connections to avoid overhead

Performance metrics:

  • Average SAP query time: 800ms for 10 orders
  • MES work order creation: 200ms per order
  • Total cycle time: 2-3 seconds for typical batch

Status Synchronization:

Bidirectional status flow implementation:

MES → SAP (Operation Confirmations): When operators perform actions in MES:

  • Start operation → POST to SAP BAPI_PRODORDCONF_CREATE_HDR
  • Complete operation → Confirmation with actual quantities/times
  • Report scrap → Confirmation with scrap quantity and reason code

Pseudocode for status sync:


// Pseudocode - MES to SAP status synchronization:
1. MES triggers operation status change event
2. Integration service listens to MES event queue
3. Transform MES operation data to SAP confirmation format:
   - Map MES operationId to SAP order/operation numbers
   - Convert quantities and timestamps
   - Add confirmation type (START/FINISH/SCRAP)
4. Call SAP BAPI with confirmation data
5. Handle SAP response and update MES with confirmation number
6. Log transaction for audit trail
// Retry logic: 3 attempts with exponential backoff

Handling Operation Splits/Combines: We prevent this issue by configuration:

  • MES operations are locked once dispatched (no split/combine allowed)
  • If operational changes needed, supervisor cancels MES work order and requests SAP change
  • SAP engineering change triggers new dispatch cycle
  • This maintains single source of truth in SAP

Error Handling and Retry Logic:

Multi-tier error handling strategy:

Tier 1 - Transient Errors:

  • Network timeouts, temporary API unavailability
  • Retry: 3 attempts with delays of 30s, 2min, 5min
  • Success rate: 95% resolve within retries

Tier 2 - Persistent Queue:

  • Failed orders move to persistent queue (PostgreSQL)
  • Background process retries every 10 minutes
  • Alerts triggered if queue depth >50 or age >2 hours

Tier 3 - Manual Intervention Queue:

  • Data validation failures (missing materials, invalid work centers)
  • Orders flagged for supervisor review in dashboard
  • Supervisor can correct data and re-dispatch

Edge Case Handling:

Rush Orders:

  • SAP priority field maps to MES priority
  • High-priority orders (priority <10) polled every 2 minutes instead of 5
  • MES scheduling algorithm automatically prioritizes

Engineering Changes:

  • SAP change number (AENNR) tracked in integration state
  • If change detected on existing order, MES work order marked obsolete
  • New work order created with revised routing/BOM
  • In-progress operations allowed to complete before transition

Material Shortages:

  • Integration queries SAP material availability (BAPI_MATERIAL_AVAILABILITY)
  • If shortage detected, work order dispatched but flagged “Material Hold”
  • MES displays material shortage alert to supervisors
  • Automatic re-check every 30 minutes until materials available

Implementation Results:

Quantitative Benefits:

  • Manual data entry time: 45-60 min/shift → 5-8 min/shift (85% reduction)
  • Transcription errors: 12-15 per week → 0-1 per week
  • Work order dispatch delay: 2-4 hours → 5-10 minutes
  • Production visibility: End-of-shift → Real-time

Operational Improvements:

  • Supervisors focus on exception management vs. data entry
  • Real-time SAP updates enable better production scheduling
  • Reduced phone calls between planning and production (70% reduction)
  • Material staging accuracy improved (advance notice of requirements)

Technical Stack:

  • Integration Service: Java Spring Boot application
  • SAP Connectivity: OData v2 client library
  • MES Connectivity: REST client with connection pooling
  • Message Queue: RabbitMQ for event handling
  • State Database: PostgreSQL for tracking and retry queue
  • Monitoring: Prometheus + Grafana dashboards
  • Deployment: Docker containers on Kubernetes

Lessons Learned:

  1. Invest heavily in data mapping documentation upfront
  2. Implement comprehensive logging for troubleshooting
  3. Build monitoring dashboards before go-live
  4. Plan for gradual rollout (we did 1 production line at a time)
  5. Train supervisors on exception handling before automation

The key to success was treating this as a business process transformation, not just a technical integration. We involved operations, planning, IT, and quality teams throughout the design phase to ensure the automation truly addressed their pain points.

Good questions. We’re using SAP’s OData services rather than direct RFC calls, which has better performance characteristics. The 5-minute polling interval works for us because we filter by release date - only orders released in the last 10 minutes are retrieved, so the result set is typically small (5-15 orders). For error handling, we implemented a retry queue with exponential backoff. If MES API is down, orders are queued locally and retried every 2, 5, 10 minutes until successful. We also have monitoring alerts if the queue depth exceeds 50 orders.

What’s your polling mechanism? Every 5 minutes seems frequent - are you hitting performance issues with SAP? We tried something similar and ran into RFC connection pool exhaustion. Also curious about your error handling strategy when the MES API is temporarily unavailable.