Timing, and config-driven types
Lesson 6 of 25 6 min read
How long each kind of change takes to apply, and exactly which parts of routing and module configuration a config-driven integration type needs.
Two practical questions come up on every job: when will my change take effect? and does this apply to a config-driven type? This lesson answers both, so that you know when to test and which screens to skip.
When a change takes effect
| Change | Time to take effect |
|---|---|
| Routing: support, service, the Enabled switches | About 10 seconds. |
| A module route, for the Integrations service | The next message. |
| A module route, for AS2 or Peppol | Up to one minute. These services keep each answer for one minute. |
After each change, the screen shows: Saved. Takes effect within a minute.
Test after a minute
If you test a change straight away and it hasn't applied, wait a minute before you look for a fault. AS2 and Peppol in particular keep the previous answer for up to a minute.
Config-driven integration types
Some integration types are config-driven. For these types, the work is defined in published maps and profiles (create maps, parse maps, send profiles and receive profiles), not in modules. You learned how to create and publish them in Maps & Profiles in Prism.
The rule to remember:
A published map or profile replaces layer 2 only (module configuration). It doesn't replace layer 1 (routing).
A config-driven type must still support each of its message types and send them to a service. If it doesn't, its messages are lost before any map or profile is used.
Which parts of this course apply
| Topic | Applies to a config-driven type? |
|---|---|
| Message types, services and the two layers | Yes. |
| When a change takes effect | Yes. |
| Which module route applies | No. |
| Module groups | No. Don't add the type to a module group. |
| Find the screens | Yes. |
| Add an integration type with its routing | Yes. Set the routing as for any other type. |
| The integration type page | Yes. |
| The Routing tab | Yes. Routing is still necessary. |
| The Routing Switches page | Yes. The switches stop config-driven types too. |
| The Modules tab | No. Don't add module routes. |
| Set a module route | No. |
| The Modules page | No. |
| The Module Groups pages | No. |
| Tasks | Only pausing one message type, stopping a service, step 1 of "find why a message type does not work", and setting up a config-driven type. |
| Messages and what to do | Yes, for the messages about routing. |
In the guide this course is based on, the sections that don't apply start with a note that says so. This course does the same.
The Preview is misleading for config-driven types
The Preview on the Modules tab shows No route matches for a config-driven type. That's correct for these types: the Preview can't see published maps and profiles. Use What actually runs in the organisation's Settings → Maps & Profiles instead.
A config-driven 3PL type that receives nothing
Northgate Logistics is a fictional 3PL whose integration type is config-driven. The team published a create map and a send profile for each customer, but no warehouse orders arrive at the 3PL.
What actually runs shows the right create map and send profile. So you check layer 1. On the type's Routing tab, the Send row is supported but shows Not routed. The messages were being discarded before the send profile was ever used. Choosing Main integrations service for the Send row fixes it within about 10 seconds.
Recap
- Routing changes take about 10 seconds. Module routes take effect on the next message for Integrations, and up to a minute for AS2 and Peppol.
- A config-driven type uses published maps and profiles instead of module routes.
- It still needs routing: support each message type and assign a service.
- Skip module routes and module groups for config-driven types.
- Use What actually runs, not the Modules tab Preview, to check a config-driven type.
Your progress is saved in this browser. Create a free account to keep it everywhere, take quizzes and earn certificates.