Micro Services

Micro Services is the platform-level registry where system administrators register, configure, and monitor micro-frontend services. Each micro-service entry controls how the shell loads the service — including its remote URL for module federation, menu path, dashboard metadata, event registry configuration, and active status. The page is visible to superusers (platform operators) in multi-tenant mode; in single-tenant mode it shows the My Applications view instead.

Accessing the Page

• Route: /microservices
• Menu Path: Settings → System → Micro Services
• Primary audience: System administrators only. Accessed via the system admin login at system.portal.net — not the tenant portal.

What you can do here

• View all registered micro-services with their name, display name, active status, live health badge, menu path, and creation date.
• Filter the list to show only active services or include inactive ones using the Show Inactive toggle.
• Search services by name, display name, or menu path.
• Click a row or the Edit action to open the full service configuration form.
• Monitor the health of each service — clicking a health badge opens the service’s /health endpoint in a new tab.

Common tasks

1. Open Settings → System → Micro Services at system.portal.net.
2. Use the Search field to locate a service by name or menu path.
3. Toggle Show Inactive if you need to view or re-enable a deactivated service.
4. Click a service row to open its configuration form and review remote URL, menu metadata, dashboard config, and event settings.
5. Update the necessary fields and save. Verify the health badge turns green after the service restarts.

Notes

• Services are loaded in menu order — the menuOrder field controls their position in the navigation sidebar.
• A service with isActive set to false is hidden from the navigation and excluded from tenant access but its registration record is preserved.
• The Health badge polls the service’s configured API base URL at <apiBaseUrl>/health. A badge showing Checking means the poll is in progress; Unhealthy means the endpoint returned an error — hover over the badge to see the error message.
• Sorting and filtering are performed client-side — all services are fetched in a single request.
• Only superusers (isSuperuser) can access this page. Non-superusers see an access-denied message.
• When System Settings → Microservice Access Mode is set to All active services for all tenants, every active microservice is exposed to every tenant automatically — the per-tenant grant table is bypassed and the Micro-Service Access tab on the tenant edit page is hidden. Switching back to Per tenant restores the prior grants.

Service registration

Micro-services are not created from this page — each service registers itself with the platform when it starts up by calling the platform registration endpoint. The list on this page reflects whatever services have successfully registered. Service-declared properties are read-only here; tenant-facing controls (active/inactive, tenant access) are editable.

Service-declared fields (read-only)

Field	Description
Name	Internal identifier the service registered with (e.g., inventory). Used as the registry key.
Display Name	Human-readable label shown in the UI.
Menu Path	Navigation path the service contributes (e.g., /inventory). Empty for backend-only services.
Menu Order	Position in the sidebar navigation; lower numbers appear first.
API Base URL	Base URL for the service’s API, used for health checks.
Remote Entry URL	Module federation remote URL for the micro-frontend bundle. Empty for backend-only services.
Registration Mode	with-frontend — the service ships a micro-frontend bundle loaded via module federation and registers menus/routes (the default). backend-only — API-only service with no remote URL, no menu entry, and no routes; used for services that only contribute backend endpoints.
Required Core Settings	List of core settings (e.g., document numbering, document print layout, fiscal periods, allowed reports) that must be configured before the service can be used. Endpoints return guard errors when a required core setting is missing.

Editing a Micro Service

Click a row in the list to open the service detail page. The page shows the service-declared fields above as read-only data, plus editable controls for global activation and (when the platform is in per-tenant access mode) per-tenant access.

• Enable Globally — toggles the service’s isActive flag. When OFF, the service is hidden from every tenant’s navigation and excluded from access regardless of grants. The service’s registration record is preserved so it can be re-enabled later.
• Tenant Configuration (per-tenant access mode only) — grant or revoke individual tenants from accessing the service. Hidden when Microservice Access Mode is set to All active services for all tenants.

To change a service-declared field (name, menu path, remote URL, registration mode, required core settings), redeploy the service with the updated registration call — the platform updates the record on the next successful registration.

Related Pages

• System Settings — switch between per-tenant and global microservice access modes.
• Tenant Management — tenant detail pages show which micro-services are enabled per tenant when in per-tenant mode.
• Service API Keys — platform-level API keys used by service-to-service calls.