3. How the Services Talk¶
Three things connect the fleet: an async message bus, a sync API gateway, and a central config server. Learn these three and the architecture opens up.
1. Async — Azure Service Bus¶
The backbone. Services publish messages to topics/queues; other services subscribe and react. (Think Salesforce Platform Events, but external and durable.)
- Subscriptions filter on an
event_typeheader — one topic can carry several message kinds, and each subscriber grabs only the kinds it cares about. - Nonprod bus:
int-nonprod-psb-1.servicebus.windows.net. (The dev profile talks to the real nonprod bus — you are on shared infrastructure locally.)
Most queues have DLQ max-delivery = 1 — no automatic retries
One failure sends the message straight to the dead-letter queue. This is deliberate: failures become visible fast instead of silently looping. When you own a consumer, you own what happens on failure.
2. Sync — APIM (Azure API Management)¶
The front door for all synchronous HTTP between services and from outside callers (OMS, webhooks). Nothing calls a service's pod directly; it goes through APIM.
Calls carry an APIM subscription key header plus basic auth. APIM handles routing, auth, and rate limiting — a new endpoint has to be registered in APIM before the outside world can reach it.
Want the real per-env addresses?
The Endpoint & Environment Map has the actual APIM base URLs, Service Bus namespaces, and target hosts for every environment — dev/qa/stage/prod — for OMS, NAV, Cirro, and the internal routes.
3. Config — Spring Cloud Config Server¶
Central per-environment configuration (think Custom Metadata / Custom Settings,
org-wide). Services read values with @Value("${some.key}") at startup.
Consequence: most config changes need no code deploy — change the value in the Config Server, restart the pod, done. This is why a lot of "changes" here are config edits, not releases.
The exp / prc / sys layering¶
Services come in three flavors — the same three-layer API-led model as MuleSoft, so this should ring a bell. Data flows experience → process → system and back:
| Layer | Suffix | Job | Examples |
|---|---|---|---|
| Experience | -exp |
REST APIs that face callers (OMS, webhooks). Speak the caller's language. | cm-fulfill-exp, cm-int-service-exp, cm-ext-service-exp |
| Process | -prc |
Orchestration & business logic. Own a domain (order, EDI, fulfillment). | cm-order-prc, cm-edi-prc, cm-fulfill-prc |
| System | -sys |
Thin adapters to one external system. Add auth, translate, forward. No business logic. | cm-cirro-sys, cm-osor-sys, cm-int-service-sys |
A -sys service should stay dumb: for example cm-cirro-sys is a pure pass-through
that only adds a Cirro auth token. Keeping business logic out of the system layer
is a design rule, not an accident.
Deployment status lives in the topology page
These examples are the shape of each layer, not a live-service list. For which services are actually deployed where — and which are retiring — see Camel Topology and page 7.
Controlling routes at runtime¶
Every service exposes actuator endpoints to list and control its Camel routes without a redeploy — handy for pausing a poller or forcing a retry: