The two layers
Lesson 4 of 25 7 min read
Every message passes routing first, then module configuration. Learn what each layer decides, the most dangerous mistake, and why a module route is only a default.
This is the most important lesson in the course. If you understand the two layers, every screen that follows makes sense, and you will avoid the one mistake that loses messages silently.
Two questions, two layers
A message has to go through two layers before any work starts:
| Layer | Question it answers | Set on |
|---|---|---|
| Layer 1: routing | Which service gets the messages of this integration type? | The type's Routing tab |
| Layer 2: module configuration | Which module does the service use for the work? | The type's Modules tab, and module groups |
Layer 1: routing
Routing tells Supply Lens which service gets the messages of an integration type. For each message type, two things must be true:
- the integration type must support the message type, and
- a service must be assigned to it.
The most dangerous mistake on these screens
If an integration type supports a message type but has no service, its messages are lost. Supply Lens discards them and shows no error. The screens show this condition as Not routed, with a warning. Treat Not routed as an emergency.
Layer 2: module configuration
A module is the code that does the work, for example shopify-order-create. A module route tells the service which module to use for a message.
How a service finds the module
Here is the part that surprises people. A service doesn't simply read the module route. It looks for the work in this order, and stops at the first one it finds:
- A published map or profile for the organisation: a create map, parse map, send profile or receive profile.
- A module that the service code selects. Some integrations do this, for example EDI, HubSpot, Business Central, Print, Http, some marketplace inventory integrations and the NHS Supply Chain Peppol maps.
- A module route on these screens.
A module route is a default
Because module routes come last, a module route is a default:
- It doesn't replace a published map or profile.
- It doesn't replace a module that the code selects.
Changed a route and nothing happened?
If you change a module route and the behaviour doesn't change, one of the first two steps probably applies. Either the organisation has a published map or profile, or the integration's code chooses its own module. Check those before you change anything else.
Notice the difference between the failures
The two layers fail in different ways, and the difference matters when you troubleshoot:
| Where it goes wrong | What happens |
|---|---|
| Layer 1: supported but no service (Not routed) | The messages are discarded with no error. |
| Layer 2: no map, profile, coded module or matching route | The messages find no module and fail. |
A failure at layer 2 is visible. A loss at layer 1 is silent, which is why the screens warn so loudly about Not routed.
Hilltop Coffee's new module route has no effect
A colleague sets a module route so that Hilltop Coffee's orders use a different Create module for a storefront integration type. Next morning, the output looks exactly the same.
You check the order of the lookup. Hilltop Coffee has a published create map for that integration type and document type. A published map runs before any module route, so the route was never reached. The fix is to change the create map (in Settings → Maps & Profiles), not the module route.
Recap
- Layer 1, routing, picks the service. Layer 2, module configuration, picks the module.
- Supported with no service means Not routed: messages are discarded silently.
- A service looks for work in this order: published map or profile, then a module the code selects, then a module route.
- So a module route is only a default. If changing one has no effect, check the first two steps.
Your progress is saved in this browser. Create a free account to keep it everywhere, take quizzes and earn certificates.