Here’s our complete implementation architecture that solved inventory sync challenges across hybrid cloud environment:
Mobile Scanning Integration:
Deployed ruggedized Android scanners (Zebra TC52) running custom app built on Epicor’s mobile framework. Each scanner maintains local transaction queue in SQLite database with these capabilities:
- Offline operation for up to 8 hours
- Local validation rules (item exists, location valid, quantity reasonable)
- Transaction queuing with UUID and precise timestamp
- Automatic sync when WiFi connectivity detected
- Visual indicators showing sync status (green=synced, yellow=queued, red=error)
Implementation code pattern:
// Pseudocode - Mobile transaction handling:
1. Scan barcode, validate item/location locally
2. Create transaction record with UUID, timestamp
3. Store in local SQLite queue
4. If WiFi available: POST to WMS API immediately
5. If offline: Queue for later, show yellow indicator
6. Background sync service checks queue every 30 seconds
7. On successful POST, mark transaction synced
Event-Driven Sync Architecture:
On-premises WMS publishes inventory events to Azure Service Bus after every transaction (receipt, pick, adjustment, cycle count). Cloud order management subscribes to event stream and updates available-to-promise calculations in real-time.
Event flow:
- Mobile scanner posts transaction to WMS REST API
- WMS updates database and publishes event to Service Bus topic
- Cloud subscribes to topic, receives event within 1-2 seconds
- Cloud updates inventory position and recalculates order allocations
- Reconciliation job runs every 15 minutes comparing WMS vs cloud positions
Event schema example:
{
"eventId": "evt-20241118-000123",
"timestamp": "2024-11-18T14:23:45Z",
"eventType": "InventoryAdjustment",
"itemId": "ITEM-12345",
"warehouseId": "WH-001",
"locationId": "A-05-02",
"lotNumber": "LOT-2024-089",
"quantityChange": -50,
"resultingOnHand": 450,
"transactionId": "TRX-445566",
"scannerId": "SCANNER-08",
"userId": "warehouse_user_23"
}
Conflict Resolution Logic:
Implemented multi-layered conflict prevention and resolution:
Layer 1 - Location Locking:
When scanner begins cycle count in location, it acquires soft lock for 30 minutes. Other scanners receive warning if attempting to adjust same location. Prevents simultaneous adjustments.
Layer 2 - Optimistic Concurrency:
Each inventory record has version number. Updates include expected version. If version mismatch detected (concurrent update), transaction fails with retry prompt.
Layer 3 - 2-Phase Allocation:
Cloud allocations are tentative. Cloud publishes allocation request event, WMS validates and confirms/rejects. Only confirmed allocations are final.
Layer 4 - Reconciliation:
Every 15 minutes, automated job compares inventory positions between WMS and cloud. Discrepancies trigger investigation workflow and WMS position wins as authoritative source.
Results and Metrics:
- Inventory accuracy improved from 94.1% to 99.3% (measured by cycle count variance)
- Sync latency averages 1.8 seconds from scanner scan to cloud visibility
- Order allocation errors reduced by 87% (from 45/day to 6/day)
- Offline scanning capability improved warehouse productivity 12% in WiFi dead zones
- Zero data loss incidents in 12 months of operation
- 99.7% event delivery success rate (Service Bus reliability)
Key Success Factors:
- WMS remains authoritative source for physical inventory - cloud defers to WMS on conflicts
- Event-driven architecture provides near real-time sync without polling overhead
- Mobile offline capability prevents productivity loss in connectivity gaps
- Multi-layered conflict prevention reduces resolution complexity
- Comprehensive monitoring and reconciliation catches edge cases
Lessons Learned:
Initial implementation used REST webhooks instead of message queue. This caused sync failures when cloud experienced brief outages. Switching to Service Bus with retry logic eliminated these failures.
We also learned to include both transaction details AND resulting inventory position in events. This redundancy enables cloud to validate its calculations match WMS reality, catching integration bugs quickly.
The 2-phase allocation pattern was critical for preventing overselling. Initial design had cloud as authoritative for allocations, which caused problems when physical inventory didn’t match system records. Making WMS authoritative for physical inventory while keeping cloud authoritative for demand management created clear responsibility boundaries.