Test execution results failing to sync with requirements traceability matrix

ALM IBM Engineering Lifecycle Management
, , , , , , , ,
1

We’re running elm-7.0.3 and experiencing critical sync failures between test-execution results and the requirements traceability matrix. When our automated test suite completes, the execution status updates don’t propagate to linked requirements, breaking our compliance-reporting workflow.

I’ve verified the webhook configuration appears correct, but test-case ID mapping seems inconsistent. The sync service logging shows successful POST operations, yet the traceability matrix remains stale. We’ve tried rebuilding the traceability cache multiple times without success.


POST /ccm/oslc/contexts/_project/executionresults
Response: 200 OK
Linked Requirement: REQ-2401 (status: unchanged)

This is blocking our sprint sign-off process. Has anyone encountered similar webhook or mapping issues in elm-7.0.3?

2

That’s likely your issue. The sync service expects consistent identifier formats across the traceability chain. We had a similar problem where test cases used one ID scheme and requirements used another. The linking worked initially but broke during updates because the resolution logic couldn’t match them properly.

3

Let me provide a comprehensive solution addressing all the sync issues you’re experiencing.

Webhook Configuration Fix: First, verify your webhook endpoint is configured with the correct content type and authentication headers. The webhook must include Content-Type: application/json and proper OAuth tokens. Check that the endpoint URL matches your server configuration exactly - any trailing slashes or protocol mismatches will cause silent failures.

Test-Case ID Mapping Resolution: The core issue is mixed identifier schemes. You need to implement a consistent ID resolution strategy:

  1. Navigate to Test Management > Configuration > ID Mapping Rules
  2. Set the primary identifier type to either internal_guid or external_id (choose one)
  3. Configure transformation rules to normalize incoming identifiers
  4. Enable the “Auto-resolve legacy links” option to fix existing mappings

For your specific case with REQ-2401, the mapping likely shows the test case using GUID tc_98a7f3b2 while the requirement expects external ID TC-2401. Create a mapping rule that transforms GUIDs to external IDs during sync operations.

Traceability Cache Rebuild: The stale cache is preventing updates from propagating. Execute these steps in order:

  1. Stop the sync service: `repotools-jts -stopSyncService
  2. Clear the traceability cache: `repotools-jts -clearTraceabilityCache project=YourProject
  3. Rebuild with validation: `repotools-jts -rebuildTraceability validate=true
  4. Restart sync service: `repotools-jts -startSyncService This process typically takes 10-15 minutes for projects with moderate traceability complexity.

Sync Service Logging Enhancement: Enable detailed logging to diagnose future issues:


log4j.logger.com.ibm.team.links.sync=DEBUG
log4j.logger.com.ibm.team.traceability=DEBUG

Add these to your teamserver.properties file and restart. The logs will now show ID resolution attempts, webhook payload processing, and cache update operations. Look for LinkResolutionException or IdentifierMismatchWarning entries - these indicate ongoing mapping problems.

Compliance Reporting Verification: After implementing these fixes, verify the end-to-end flow:

  1. Execute a test case with known requirement links
  2. Check the webhook logs for successful POST with requirementLinks array
  3. Query the traceability matrix API to confirm status update
  4. Validate compliance report shows updated execution status

The 200 OK response you’re seeing doesn’t guarantee the link update succeeded - it only confirms the webhook was received. The actual sync happens asynchronously, and failures occur in the background processing. With proper logging enabled, you’ll see the actual error: likely CannotResolveTestCaseIdentifier or RequirementLinkStale.

This comprehensive approach should resolve your sync failures and restore your compliance reporting workflow.

4

We encountered this in a recent migration project. The problem is the test-case ID mapping layer doesn’t automatically normalize identifiers. You need to configure an ID resolution strategy in your sync service configuration. Check the advanced settings for identifier transformation rules.

5

Thanks Sara. I checked the webhook subscriptions and both events are enabled. However, I noticed the test-case ID mapping uses internal GUIDs while our requirements reference external IDs. Could this be causing the link resolution to fail during sync?