We’re experiencing a critical issue with labor management in AM 2023.1 where timesheet records from our HR system are creating duplicate entries during REST API synchronization. This is causing major labor cost corruption in our reporting.
The problem appears to be related to network timeouts during API calls. When a call times out, our integration retries the request, but MES creates a new timesheet record instead of recognizing it as a duplicate. We don’t have proper idempotency key implementation, and the upsert operation logic seems to be doing INSERT instead of UPDATE.
POST /api/v1/labor/timesheets
Employee: EMP-1234, Date: 2024-11-15
Response timeout after 30s
Retry creates duplicate: TS-001 and TS-002
How should we implement proper request deduplication and conflict resolution for timesheet synchronization?
Beyond idempotency keys, you should be using PUT or PATCH operations instead of POST for timesheet updates. POST always creates new records. Use PUT with a composite key of employeeId and date to ensure upsert behavior. The API endpoint should be /api/v1/labor/timesheets/{employeeId}/{date} for proper upsert semantics.
Also implement client-side deduplication before even calling the API. Maintain a local cache or database table of recently submitted timesheets with their idempotency keys. Check this cache before making API calls to prevent unnecessary network requests for true duplicates. This is especially important if you have multiple integration instances running that might process the same HR feed.
Don’t forget about the deduplication window configuration in MES. By default, idempotency keys are stored for 24 hours. If your integration might retry after longer periods, you need to extend this window in the labor module configuration. Set labor.idempotency.windowHours=72 in your application properties to allow 3-day retry windows. This prevents duplicate creation for delayed retries while still allowing legitimate duplicate entries on different dates.
Good point about PUT vs POST. Our current integration uses POST exclusively. If we switch to PUT, will that automatically handle the duplicate detection, or do we still need idempotency keys? Also, what happens if two systems try to update the same timesheet simultaneously - which conflict resolution strategy does MES use?
This is a classic idempotency problem. The MES labor API supports idempotency keys in the request headers, but you need to explicitly include them. Add an X-Idempotency-Key header with a unique value for each timesheet record. The key should be deterministic based on employee ID and date so retries use the same key.