Additional Create TaaS Case
This page explains focused CTT flow where system creates additional TaaS case.
API Endpoints
POST /ticket/ctt/create-case
Purpose
This flow exists for TaaS-integrated case creation, not normal local-only CTT editing.
It is used when CTT-side process must open downstream TaaS case and persist returned case metadata.
Business meaning
Additional TaaS case flow is integration-heavy.
Main business value:
- build valid TaaS create payload
- send create request to downstream TaaS
- retry for token or auth failures
- log APIM request and response
- persist created case only when downstream create succeeds
Flow summary
| Step | Business meaning |
|---|---|
| receive create-case request | TaaS case creation starts |
| generate APIM token | downstream auth is prepared |
| token error and retry budget left? | auth can retry before hard fail |
| build request id and TaaS payload | downstream request is normalized |
send CreateCase to TaaS | external case create happens |
| HTTP error? | failed response shape is normalized |
auth error 401 or 403? | request can retry |
| write APIM log | integration trace is preserved |
| persist returned case if success | local repo keeps created-case reference |
| return TaaS response | caller gets final downstream result |
Implementation note
Current repo confirms backend path:
- backend exposes
POST /ticket/ctt/create-case - service sends request to
/v3/sba/sync/taas/CreateCase - service retries on token failure and on
401/403 - service persists returned case only after successful response handling
Code refs:
mvp3-ticket-service/src/modules/ctt/ctt.controller.ts:408mvp3-ticket-service/src/modules/ctt/ctt.service.ts:4750
Important behavior
- this flow is TaaS-specific, not generic CTT create
- APIM logging is part of expected behavior
- retry logic exists for auth-related failure, not unlimited generic retry
- local persistence follows downstream success path