Skip to main content

CR to TMF Handoff

This page explains the manual caution report dispatch flow into TMF and was checked against the current code, not only the flowchart.

API Endpoints​

  • POST /data/caution-report/trigger/dispatch-tmf

Bottom line​

For manual Dispatch to TMF, the flowchart is mostly correct and closely matches the implementation in mvp2-data-service.

The main thing to understand is that this is an API-triggered handoff, not a background-only process. The user action in portal calls the dispatch endpoint directly, and the backend then creates the TMF work order, updates the local CR state, uploads attachments, and performs source-specific follow-up when needed.

When this flow is used​

  • when a user manually escalates or dispatches a Caution Report from the portal
  • when the CR needs a downstream TMF work order
  • when support or developers need to trace why a TMF work order was or was not created

What starts the handoff​

The handoff starts from the portal CR details page when the user triggers the dispatch action.

From there:

  1. portal calls POST data/caution-report/trigger/dispatch-tmf
  2. data service loads the CR by id
  3. data service prepares TMF access token and target URL
  4. data service sends the TMF create work order request
  5. on success, local CR state is updated to In-Progress

Main business flow​

StepWhat the system does
Load CRFinds the target Caution Report by id
Validate existenceStops immediately if the CR does not exist
Resolve TMF connectionChooses regress or normal TMF mode, gets APIM token, resolves TMF base URL
Retry access token errorsRetries if token generation returns Error, up to the implemented retry limit
Enrich cabinet/FDC dataIf cabinetId is missing, tries to derive it from nearby FDC data
Build dispatch payloadCreates the TMF work order payload from CR fields and LOV values
Create TMF work orderCalls TMF createworkorder endpoint
Retry auth failuresRetries when TMF responds with 401, up to the implemented retry limit
Reject failed dispatchStops and audits failure if TMF returns non-200
Create local CR activitySaves returned TMF ticketId and activityId as local CR activity data
Update CR stateStores TMF ticket info and updates local CR status to In-Progress
Upload attachmentsSends CR attachments to TMF after the work order is created
Update CR LOV statusUpdates the CR status LOV record to In-Progress
Trigger GOTH follow-upIf source is GOTH, also pushes the status update to GOTH
Save audit and APIM logsWrites success logs after the main dispatch flow finishes

What data is used​

The TMF payload is built from the Caution Report and its related LOV and area data. The current implementation pulls values such as:

  • ticket number
  • creation time
  • ETTR
  • requestor name and contact number
  • diagnosis code and impacted symptom
  • severity and urgency reason
  • comment
  • building and zone information
  • latitude and longitude
  • cabinet or nearby FDC-derived cabinet id

Confirmed runtime behavior​

These parts are directly confirmed from code:

  • the portal calls data/caution-report/trigger/dispatch-tmf
  • the backend dispatch method is triggerDispatchTMF(...)
  • token generation failure is retried
  • TMF 401 response is retried
  • successful TMF dispatch creates a local CR activity record
  • successful TMF dispatch updates local CR status to In-Progress
  • attachments are uploaded after the TMF work order is created
  • GOTH-origin CRs trigger an extra downstream status update

Failure points​

The main failure gates in the current implementation are:

  • CR does not exist
  • APIM token cannot be obtained successfully after retry attempts
  • TMF create work order call returns non-200
  • GOTH status update fails for GOTH-sourced CRs

If one of these happens, the backend raises an error and logs the failure through the audit flow.

Important implementation nuance​

One part of the flowchart should be read carefully: attachment handling.

In the current code, attachment upload happens after the TMF work order is already created and after the local CR has already been updated to In-Progress. If an attachment upload fails, the failure is logged and audited, but the code does not clearly roll back the already-created TMF work order or revert the CR status update.

So the safest business reading is:

  • main TMF handoff success is decided by the TMF work order creation response
  • attachment sync problems are follow-up failures, not clearly full-dispatch rollback failures

Flowchart verdict​

The Dispatch to TMF flowchart is reliable for the main dispatch path.

It is accurate on the major decisions:

  • CR must exist
  • APIM access is required
  • TMF create work order is the key success gate
  • success leads to local activity creation and CR status change to In-Progress
  • GOTH source has additional downstream behavior

The only caution is that attachment upload should be treated as a post-create follow-up step, because the implementation does not behave like a single all-or-nothing transaction.

Code references​

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