Microservice
The Microservice Registry is a lightweight catalog of services installed in your tSM Platform.
Because many parts of tSM are dynamic and pluggable, the registry provides a single place to:
- see which microservices are present (and their display names),
- record a backend URL used by UIs, jobs, or connectors,
- organize services with tags and free-form config,
This registry holds installation metadata. Low-level deployment settings (replicas, resources, secrets, env vars, ingress) live in your Kubernetes manifests and are not configured here.
Typical Uses
- Ops overview: list all services (DMS, Ticketing, Notifications, Integrations, …) installed in a given environment.
- UI/service routing: store a
backendUrlthat frontends and admin tools can use to reach service endpoints (through gateway/reverse proxy). - Gradual enablement: use
validityFrom/validityTo(and computedvalid) to stage or phase out services without touching deployment YAMLs. - Scoped configuration: put small knobs into
config(feature flags, UI hints) and usedataTagsfor filtering and dashboards.
For API discovery (endpoints, OpenAPI), rely on each service’s own docs/health endpoints or your API gateway catalogue. The registry itself is an inventory—not a full service mesh.
Reference
Microservice (attributes)
| Field | Type | Required | Read-only | Description / Notes |
|---|---|---|---|---|
id | UUID | – | – | Identifier (not intended for end-user display). |
code | String | Yes | – | Unique ASCII code (no spaces). Used by configs, routing, and admin tools. |
name | String | Yes | – | Human-readable name shown in admin UI. |
description | String | – | – | Optional tooltip/long description. |
validityFrom/To | Date | – | – | Optional window during which the service is considered active. |
valid | Bool | – | Yes | Computed from validity; not stored. |
backendUrl | String | – | – | Base path/URL behind the gateway (e.g., tsm-user-management/api). |
config | Map | – | – | Free-form configuration for UI/ops tooling (not a deployment substitute). |
dataTags | List | – | – | Labels for grouping/reporting (e.g., core, billing, external). |
localizationData | Object | – | – | Translations for name/description. |
auditInfo | Object | – | – | Standard audit metadata. |
Good Practices
- Keep
codestable — it becomes a key in scripts, dashboards, and cross-service config. - Use gateway-relative
backendUrl— avoid hardcoding hostnames; let environments swap gateways. - Minimal
config— store only small cross-cutting flags or UI hints. Runtime secrets/URLs belong to Kubernetes. - Tag consistently —
dataTagslikecore,integration,reporting,externalmake ops views and filters useful. - Leverage validity — toggle availability via
validityFrom/Tofor staged rollouts without redeploying. - Document endpoints at the source — link to each service’s OpenAPI/health pages from your ops wiki or gateway UI.
See Also
- System Settings – other platform catalogs and code tables
- Notifications / Logs / Attachments – services that commonly appear in the registry
- Kubernetes deployment – operational configuration, scaling, secrets, and networking