Mobile asset lifecycle app fails to sync asset status update

PLM Teamcenter
, , , , , , , ,
1

We’re experiencing critical sync failures with our Teamcenter Mobile deployment for asset lifecycle management. Field technicians update asset statuses offline (inspection complete, maintenance required, operational), but when they reconnect, the sync fails with data mismatch errors.

The error log shows:


SyncError: Conflict detected - Asset A-2847
Local status: MAINT_REQUIRED
Server status: OPERATIONAL
Timestamp mismatch: 2025-03-13 14:22 vs 14:18

Our offline data queue configuration seems standard, but we’re not sure about the conflict resolution policy settings. We also suspect issues with how asset revisions are being handled during the sync process. The mobile app version is 12.3.0.4 connecting to TC 12.3 Active Workspace. This is blocking our field operations team from completing their daily inspections. Has anyone dealt with similar mobile sync conflicts in asset lifecycle scenarios?

system 2

Let me provide a comprehensive solution addressing all three critical areas you’re facing.

Offline Data Queue Configuration: First, update your mobile server configuration (mobileserver.properties):


offline.queue.retention.days=7
offline.queue.maxSize=5000
offline.sync.retryAttempts=5

This ensures field updates are retained long enough for remote workers to sync and provides automatic retry logic.

Conflict Resolution Policy: Change your conflict resolution strategy to handle asset lifecycle scenarios properly. In your mobile server config:


conflictResolutionStrategy=TIMESTAMP_PRIORITY
asset.conflict.notifyUser=true
asset.conflict.createAuditLog=true

The TIMESTAMP_PRIORITY mode compares the actual modification time of the change (when the field tech made the update) versus when it was applied on the server. This is more accurate than simple SERVER_WINS/CLIENT_WINS for offline scenarios. Enable user notification so field techs can review conflicts through the mobile UI, and audit logging helps track resolution patterns.

Asset Revision Handling: The core issue is that your ITK extensions aren’t properly capturing revision context during offline updates. Modify your custom asset status change handler to include revision validation:

// Pseudocode - Asset revision-aware status update:
1. Retrieve asset object with AOM_refresh(assetTag, &assetObj)
2. Get current revision: AOM_ask_value_string(assetObj, "revision_id")
3. Compare with mobile client's cached revision_id
4. If mismatch detected, flag CONFLICT_DETECTED status
5. If match, proceed with status update and capture new revision
6. Store sync metadata: timestamp, user, device_id for audit
// Reference: Teamcenter ITK Programmer's Guide Section 8.4

In your mobile app’s sync handler, ensure you’re passing the revision context:

// Pseudocode - Mobile sync with revision context:
1. Build sync payload with: assetId, newStatus, revisionId, offlineTimestamp
2. Send POST to /tc/mobile/api/assets/syncStatus endpoint
3. Parse response for conflict flags or validation errors
4. If conflict, present resolution UI to user with both versions
5. On user choice, resubmit with conflict_resolution_mode parameter
// Mobile API Documentation: Asset Lifecycle Sync Protocol v2.1

Additional Recommendations:

  1. Implement optimistic locking: Add a version token to your asset objects that increments with each change. The mobile client includes this token in update requests, and the server rejects updates if the token doesn’t match current state.

  2. Enhanced logging: Enable detailed sync logging in your mobile server to track exactly where conflicts occur:

    • Set `mobile.sync.logging.level=DEBUG
    • Monitor mobileserver_sync.log for conflict patterns
    • Look for repeated conflicts on specific assets (might indicate workflow issues)

  3. Conflict resolution dashboard: Build a simple admin dashboard showing pending conflicts, resolution rates, and common conflict types. This helps identify systemic issues versus one-off problems.

  4. Field testing protocol: Before rolling this to production, test with your field ops team using this scenario:

    • Tech A updates asset status offline
    • Tech B updates same asset on server
    • Tech A syncs and verifies conflict is properly detected
    • Verify resolution UI shows both changes clearly
    • Confirm audit log captures the full conflict resolution history

The combination of extended queue retention, timestamp-based conflict resolution, and proper revision handling should eliminate your sync failures. The key is ensuring your mobile client captures complete context (revision, timestamp, user) during offline changes, and your server-side handlers validate this context before applying updates.

Monitor your sync success rate after implementing these changes - you should see conflicts drop significantly, and remaining conflicts should be legitimate concurrent modifications that require manual resolution rather than technical failures.

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

3

I’ve seen this exact pattern before. The timestamp mismatch is a red flag that your conflict resolution policy isn’t configured correctly. Check your mobile server configuration file for the conflictResolutionStrategy parameter. It should be set to either SERVER_WINS, CLIENT_WINS, or MANUAL_REVIEW. For asset lifecycle, I’d recommend MANUAL_REVIEW to avoid data loss during field operations.

krish_verma 4

“Confirmed this resolves our offline sync failures — setting conflictResolutionStrategy in mobileserver.properties with a 7-day retention queue eliminated lost asset status updates for our remote field technicians.”

5

Also verify your offline queue retention settings. If the queue is configured with too short a retention window, pending updates might be getting purged before sync completes. We had a similar issue where field techs in remote areas couldn’t sync for 48+ hours, and their updates were lost. Increasing the queue retention to 7 days and implementing a sync retry mechanism with exponential backoff resolved it for us. The asset revision handling is tricky too - make sure your mobile app is capturing the correct revision context when the status change is made offline.

7

The asset revision handling is probably your main issue here. When an asset status update happens offline, the mobile client needs to store not just the new status but also the revision identifier and the change context. If someone else modified the asset on the server while your field tech was offline, you get exactly this conflict. Check if your mobile customization is properly implementing the revision-aware update pattern. The standard mobile framework should handle this, but custom asset lifecycle workflows sometimes bypass the proper revision checks.

8

Thanks for the insights. I checked our mobile server config and found conflictResolutionStrategy was set to SERVER_WINS by default. That explains why field updates were being discarded. I’m also seeing that our queue retention is only 24 hours, which is definitely too short for our remote sites. One more question - where exactly should I look for the revision context handling in the mobile customization? We have some custom ITK extensions for asset status workflows.

9

For the ITK extensions, you need to ensure your custom code is calling AOM_refresh on the asset object before applying status changes, and then checking the modification timestamp. The mobile framework passes a lastSyncTimestamp parameter that your ITK handler should validate against the server object’s last modified date. If there’s a mismatch, your code should flag it for conflict resolution rather than silently failing or overwriting.

10

I’d also recommend implementing a pre-sync validation step in your mobile app. Before attempting the full sync, query the server for the current state of all modified assets and compare timestamps. This gives you a chance to present conflicts to the user proactively rather than failing during sync. We built a conflict resolution UI that shows both the local and server values side-by-side, letting field techs choose which update to keep or merge them manually. It added complexity but dramatically reduced sync failures and data loss complaints from field operations.

megan_dev 11

Increasing the queue retention to 7 days and implementing a sync retry mechanism with exponential backoff resolved it for us.