Seed profiles and topologies

The platform is installed in different shapes: with or without ministry modules, as one installation or as a national hub with ministry nodes. A service must work in each shape it can meet. The kit covers this with two switches: the seed profile and the topology.

Seed profiles

E2E_SEED_PROFILE chooses what the seeded installation looks like.

Profile	Modules	Data	Stands for
mihud (default)	estate, rentals, valuation and shop switched on and assigned to one ministry	two properties and a tenant with a lease	an installation that already runs ministry modules
neutral	every module off	no estate or rentals data	a new installation, or any other ministry's node

Both profiles also import one service from the legacy catalogue with the backend's own importer, and seed two ministries with their officers.

Every service's journey must pass on both profiles. The reason is the platform's modularity rule: core stays neutral, and ministry functionality is in modules that are off by default. A journey that passes only with modules on may be relying on something the next ministry does not have.

Run both:

npm run e2e -- tests/<your-service>.spec.js
E2E_SEED_PROFILE=neutral npm run e2e -- tests/<your-service>.spec.js

The database is re-created between the runs.

Module journeys on either profile

A service that needs a module does not depend on the profile having it. Its journey switches the module on itself, for the owning ministry only, the way an administrator would: one administrator proposes the change under System administration → Modules, and a second administrator approves it (maker-checker). The journey then runs the module's service set-up, if it has one, and continues. This also proves the switch-on path works.

Expected differences are explicit. On neutral, steps that need a module the journey does not switch on are skipped with a reason, and a few checks run only there (for example that every module is off).

Topologies

E2E_TOPOLOGY chooses the shape of the platform.

Combined (default)

One installation: one API, one database, the portal and the back office. Every journey runs here, including the cross-instance journeys, for which the "hub" and the "node" are simply the same installation.

Federated

A national hub and a ministry node, two instances of the same backend:

	Hub	Node
Serves	API, citizen portal, hub back office	API, the ministry's back office
Database	its own	its own
Seed	a ministry the hub hosts, the citizens, every module off	the ministry's staff and services, its modules on, no citizens
ZamPay double	its own	its own, which calls the node back when an invoice is paid

When the stack starts in this topology it also:

• makes a fresh federation signing key for each instance (test-only, new at every start);
• registers the node on the hub through the hub's administration API, as an operator would: one administrator proposes,

  the proposer's own approval is refused, a second administrator approves;

• exchanges a signed ping each way;
• has the node push its catalogue, and waits until the hub's public listing shows the node's services.

Start it with:

E2E_TOPOLOGY=federated npm run e2e -- tests/<your-service>.spec.js

When a journey must run federated

A journey runs in the federated topology when its service can live on a node. That is the normal case for a ministry service. In the federated run:

• the citizen stays on the hub: finds the service, applies on the hub's page for the node's service, pays the

  node's invoice from My payments on the hub, downloads the sealed document through the hub, and verifies it on the hub's verification page;

• the officers work in the node's back office and API;
• the case itself, its answers and documents exist only on the node. The hub keeps index data only.

The kit's helper tests/support/home.js says where a service lives, so the same spec runs in both topologies. Which specs run in the federated topology is listed in playwright.config.js.

Cross-instance journeys

The fed-* specs test federation itself: the node's catalogue on the hub; apply on the hub, process on the node, see the status on the hub; pay on the hub for a node invoice; a node outage while the citizen applies (the hub queues the application and delivers it exactly once when the node is back); and ZamPay callbacks reaching the right instance.

When a federation operation is not yet offered by an instance, these specs skip themselves and the skip reason names the evidence, for example that the node answered 501 FED_NOT_IMPLEMENTED.

Choosing the runs for your service

Your service	Runs
Core only, cannot live on a node	combined on mihud, combined on neutral
Can live on a ministry node	the above, plus federated
Needs a module	the above; the journey switches the module on itself

Check your understanding

• What is the difference between the mihud and neutral seed profiles?
• Why must a service's journey pass on both profiles?
• How does a module journey get its module switched on, and why that way?
• In the federated topology, where does the citizen apply and pay, and where do the officers work?
• Which data about a node's case does the hub keep?
• What does a fed-* spec do when an instance does not offer an operation yet?