Skip to main content

CR TMF Workorder Lookup

This page explains how CR-related workorder lookup works after a Caution Report has already been dispatched to TMF.

This flow was checked against the current code in mvp2-data-service and intt-portal.

API Endpoints​

  • GET /data/caution-report/tmf/work-order/get
  • GET /data/caution-report/tmf-work-order/find

Purpose​

Readers use this page to understand the difference between:

  • reading a live TMF workorder from TMF itself
  • reading locally stored CR workorder and activity history inside Antrix

These are related, but they are not the same flow.

Bottom line​

There are two different read paths:

  1. tmf/work-order/get This calls TMF directly and returns live TMF workorder status details for a ticketId and activityId.

  2. tmf-work-order/find This does not call TMF. It reads locally stored CR activity records and groups them into workorder-style history for the CR detail page.

When this flow is used​

  • when a CR already has a TMF ticket and users want to inspect its progress
  • when the CR detail page needs to show grouped TMF activity history
  • when support needs to compare local CR activity records with TMF-side state

Flow A: Get live TMF workorder​

This is the direct TMF lookup path.

What it needs​

  • ticketId
  • activityId

If either field is missing or invalid, the backend returns a 400-style response payload with an error message instead of calling TMF.

Main runtime flow​

StepWhat the system does
Validate inputchecks that ticketId and activityId are present strings
Resolve TMF connectionchooses regress or normal TMF mode
Generate APIM tokengets the TMF access token
Retry token failuresretries if token generation returns Error
Call TMFsends GET /eai/intt/workorder/queryworkorderstatus
Retry 401 responsesretries when TMF responds with 401
Return TMF payloadreturns TMF ticket status and activity list
Save APIM logstores request and response log data locally

Business meaning​

This flow is the nearest thing to a live TMF status check for CR.

Use it when the question is:

  • what does TMF currently say about this workorder
  • what activity status did TMF return
  • is TMF returning expected activity data for this ticket

Flow B: Find CR workorder history​

This is the local CR lookup path used to build the workorder section in CR detail.

What it needs​

  • crId

Optional paging values are also supported.

Main runtime flow​

StepWhat the system does
Read CR activity rowsloads CautionReportActivity rows for the CR
Sort newest firstorders the rows by createdAt descending before mapping
Group by TMF ticketgroups rows into workorders using ticketId
Group by activity idgroups each workorder into activities using activityId
Attach notes and attachmentslinks CR notes and attachments by activityId
Return paged responsereturns grouped workorders for the UI

Business meaning​

This flow answers a different question:

  • what workorder and activity history has Antrix already stored for this CR
  • which activity has notes
  • which activity has attachments
  • what is the latest locally known status shown in the CR detail screen

Important difference between the two flows​

QuestionUse this flow
I want the live TMF-side workorder statetmf/work-order/get
I want the CR detail page history and grouped local activity recordstmf-work-order/find

This distinction matters because a local CR history view may still be available even when a fresh TMF read is not being performed at that moment.

Confirmed portal behavior​

The current CR detail page explicitly calls the local lookup endpoint:

  • data/caution-report/tmf-work-order/find

That endpoint returns grouped workorders, grouped activities, and linked notes and attachments so the detail page can render a richer history view.

What the live TMF response contains​

The TMF workorder response includes:

  • ticketId
  • ticketStatus
  • activityList
  • errorCode
  • errorMessage

Each activity includes fields such as:

  • activityId
  • activityType
  • activityDescription
  • status
  • statusDatetime
  • buildingId
  • finalSymptom
  • ETTA
  • ETTR
  • delayReason
  • causeCode
  • causeCodeCat
  • resolutionCode
  • staffId
  • name

Flowchart verdict​

The Get TMF Workorder and Find CR Workorder flowcharts are directionally correct for the two different responsibilities they represent:

  • one is a TMF read
  • one is a local Antrix grouping and lookup flow

The most important thing for readers is not to treat them as a single step. They serve different purposes and use different sources of truth.

Code references​

  • mvp2-data-service/src/modules/caution-report/caution-report.controller.ts
  • mvp2-data-service/src/modules/caution-report/caution-report.service.ts
  • mvp2-data-service/src/modules/caution-report/caution-report-response.model.ts
  • intt-portal/src/app/components/pages/main-modules/cr/cr-details/cr-details.component.ts