Vertex Documentation – Vertex Modules

Docs: CRM module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the CRM module

Docs: Pricing module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the Pricing module

Docs: Portfolio Management module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the Portfolio Management module

Docs: Price Forward Curve module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the Price Forward Curve module

Docs: Aggregate module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the Aggregate module

Docs: Vattenfall module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the Vattenfall module

Docs: Documents module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the document module

Docs: EnergyModel module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the EnergyModel module

Docs: TimeSeries module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the TimeSeries module

Docs: EDP notifications

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the EDP Notifications module

Docs: Core module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the Core module

Docs: CQRS Coordinator module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the CQRS Coordinator module

Docs: Gateway module

Mon, 01 Jan 0001 00:00:00 +0000

The gateway is the entry point for all external REST requests to Vertex.

Partner transport TLS

A dedicated partner Gateway can terminate TLS before applying its HTTP routing and rate limits. Configure one optional GatewayModuleConfig.TransportEndpoint per instance. Route the partner’s hostname through cluster ingress with TLS passthrough, not HTTPS termination or re-encryption. The downstream module continues to receive HTTP on its interconnect port.

GatewayModuleConfig:
  Url: ''
  EnableModuleDiscovery: false
  EnableSwagger: false
  EnableGraphQL: false
  EnableUserSessions: false
  TransportEndpoint:
    Port: 8443
    CertificateBase64: '${TennetMessageClientCertificateBase64}'
    CertificatePassword: '${TennetMessageClientCertificatePassword}'

An empty Url leaves the dedicated Gateway without a plaintext HTTP listener. The shared user-facing Gateway can retain its existing Url and omit TransportEndpoint. The PFX must contain a private key, permit server authentication, and cover the public hostname. Certificates and pins are loaded at startup; restart the Gateway after changing them.

TransportEndpoint.ClientCertificateSha256Pins is an optional array of SHA-256 fingerprints of complete client certificates:

Omitted or empty: server-only TLS; no client certificate is requested.
Non-empty: a client certificate is required and must match a pin and pass normal certificate-chain, validity and revocation checks. Pins do not bypass CA trust.
Each entry is 64 hexadecimal characters; colon separators and spaces are accepted. Windows’ usual SHA-1 thumbprint is not accepted.
Include both current and next fingerprints during rotation. Full public leaf certificates are unnecessary for pinning; private issuing CAs must still be trusted by the Gateway pod.
Malformed pins or an invalid PFX abort startup rather than falling back to unauthenticated TLS.

Obtain a fingerprint with openssl x509 -in client.pem -noout -fingerprint -sha256. The pod needs access to the certificate issuer’s CRL/OCSP endpoints when mTLS is enabled.

Use one Gateway deployment per partner to enforce backend isolation with Kubernetes NetworkPolicy. NetworkPolicy identifies pods and destination ports, not HTTP routes or the source listener.

Optional Gateway capabilities

Each capability defaults to true for existing user-facing deployments. Disable them explicitly on a partner Gateway; TLS configuration is independent of these switches.

Setting	Behavior when disabled
`EnableModuleDiscovery`	Does not load or periodically refresh module `gateway-routes.yaml` files. Configured `BackendConfigs` and `RedirectConfigs` still apply.
`EnableSwagger`	Does not expose Swagger UI or document endpoints.
`EnableGraphQL`	Does not register or expose the GraphQL gateway.
`EnableUserSessions`	Does not register cookie/OIDC login, Redis-backed user sessions, token exchange/refresh, or `/gateway/action/*` endpoints. Skips startup OIDC discovery and session-based token injection. Stateless JWT bearer authentication remains available.

Selecting an instance’s configuration section

By default, the Gateway binds GatewayModuleConfig. Set the deployment environment variable ConfigSections__GatewayModuleConfig=TennetGatewayModuleConfig to bind another section instead. Colon-delimited nested paths are also supported. ModuleId remains the instance identity and does not determine the selected section.

The legacy configuration loader binds only the selected section, after normal Config Server, vault, environment-variable and placeholder processing. It does not overlay that section onto GatewayModuleConfig; shared routes, user-session settings and credentials are not inherited. An explicitly selected missing or blank section fails startup instead of falling back. Class-level defaults still apply to properties omitted from the selected section.

Both sections can live beside each other in config.yaml, with their environment overrides in config-acc.yaml. Maintainers can organize files later using the existing Config Server layers. Disabling module discovery alone does not remove explicitly configured routes.

Request tracing and caller attribution

Trace context

Send a W3C traceparent header to link the handling of a request in Vertex to a trace in your own tooling. B3 and Jaeger trace headers are also accepted; when several are present, traceparent takes precedence. A missing or malformed trace header never causes a request to be rejected; Vertex then starts a new trace for that request.

Caller headers

Identify your application and job with the following optional headers. They allow traffic and issues to be traced back to a specific caller and run, without requiring any tracing tooling on your side.

Header	Purpose	Example
`X-EE-Application`	Name of the calling application	`PyVertexImporter`
`X-EE-Job`	Short logical name of the job or script	`daily-import`
`X-EE-Run-Id`	Identifier shared by all calls made in one run	`8f14e45f-ceea-467f-a8f5-3c3b6c0e5a01`

Use stable application and job names, and generate a new run identifier for every execution.
These headers are diagnostic labels only: they do not authenticate the caller, grant permissions, or change rate limits.
Never put credentials, tokens, personal data, or request content in these headers.

Header value rules

Allowed characters are ASCII letters, digits, spaces, ., _, and -; other characters are removed.
Values are trimmed and truncated to 128 characters.
Empty values, repeated headers, comma-separated lists, and values longer than 1,024 characters are ignored.
An invalid caller header never causes the request itself to be rejected.

Docs: Identity Access Management module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the Identity Access Management module

Docs: Jobs module

Mon, 01 Jan 0001 00:00:00 +0000

This is a description of the Jobs module

Docs: JsonBroker module

Mon, 01 Jan 0001 00:00:00 +0000

Document uploads

/api/document/new accepts resumable tus uploads from callers with document-create permission. Creating, inspecting, resuming, deleting, and concatenating an upload require the same authenticated user and selected tenant; the upload URL alone does not grant access. Completed uploads are stored as temporary documents for that tenant.

Uploads created before this ownership isolation cannot be resumed and must be restarted. Incomplete uploads expire after one day of inactivity.

Docs: Rule engine module

Mon, 01 Jan 0001 00:00:00 +0000

The Vertex Rule Engine is used to run the specific BRE script language. The hosted rule engine has a set of plugins that are provided by other modules that enables calling methods that leverage specific features of those modules to extend the BRE script language with the modules that are deployed on an environment.

Docs: Migration Controller module

Mon, 01 Jan 0001 00:00:00 +0000

The Migration Controller runs event store V1 to V2 migration through distributed background workers. It provides operations to start migration, retry faulty aggregates, and inspect migration status.

Migration requires both SystemTextJsonSerializerEnabled and WriteToEventStoreV2Enabled to be enabled. The controller rejects a new migration request while another migration run holds the migration lock.

The runtime project is EE.Modules.Infrastructure.MigrationController. Its deployment and documentation component name is vertex-infra-migrationcontroller.

Docs: Notification Center module

Mon, 01 Jan 0001 00:00:00 +0000

The Notification Center keeps the latest errors and warnings of entities that other modules report, per entity type and tenant, for a rolling retention period (NotificationCenterModuleConfig.RetentionPeriodInHours, one week by default). The front end reads the overview and the tables of statuses through the GraphQL gateway.

Entity modules publish through providers. A provider derives from NotificationCenterProviderBase, names its recurring job with a DistributedWorkSchedule attribute, and publishes the statuses that changed in a recent lookback period on every run. The Notification Center tracks which period it holds statuses for. When it misses a period, it answers with that period, and the provider publishes a snapshot of it. A snapshot holds only the warnings and errors of that period: the provider queries them separately and leaves out successes, so a large period stays cheap. Snapshots merge by period, so smaller snapshots add up. A published status older than the stored status of the same entity is ignored, so a delayed or replayed publish never overwrites a newer status. NotificationCenterProvidersConfig.Providers configures individual providers, keyed by source module and then by entity type. Each entry can set IsEnabled, Schedule (a cron expression), and ChangesLookbackInMinutes. A setting that is not set follows the default of the provider. The lookback must be longer than the interval of the schedule, so consecutive runs overlap:

NotificationCenterProvidersConfig:
  Providers:
    Aggregate:
      IngestionBatch:
        IsEnabled: true
        Schedule: '*/5 * * * *'
        ChangesLookbackInMinutes: 15

A module built with VertexModuleBuilder adds NotificationCenterProvidersComponent. A manually composed module (one deriving from BaseModule) uses NotificationCenterManuallyComposedModuleExtensions: it calls AddNotificationCenterProviders in ConfigureModuleServices with its shutdown token and the assemblies to scan, and ScheduleNotificationCenterProviders on its module service provider in StartModule. AddNotificationCenterProviders loads the NotificationCenterProvidersConfig section itself.

Providers publish through INotificationCenterServiceClient, which the module registers as a remote gRPC client from EE.Modules.Infrastructure.NotificationCenter.GrpcClient. A module built with VertexModuleBuilder adds it to its GrpcServicesComponent:

.AddRemoteGrpcClient<NotificationCenterService.NotificationCenterServiceClient, INotificationCenterServiceClientFactory, INotificationCenterServiceClient>(
    GrpcServiceAddresses.NotificationCenter,
    stub => new NotificationCenterServiceClientFactory(stub),
    factory => factory.GetClient()
)

A manually composed module calls services.AddRemoteGrpcClient with the same arguments in ConfigureModuleServices. The Notification Center serves gRPC on port 7103. The Aspire AppHost and the vertex Helm chart inject its address as services__vertex-infra-notificationcenter__grpc__0.

The runtime project is EE.Modules.Infrastructure.NotificationCenter. Its deployment and documentation component name is vertex-infra-notificationcenter.