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: Greenchoice module

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

This is a description of the Greenchoice 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: Model Executor module

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

This is a description of the Model Executor 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: CBP Messagebox module

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

This is a description of the CBP Messagebox 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.

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: Dexter module

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

Docs: Document Generation module

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

Docs: eBase interfacing module

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

Docs: MessageBox EDSN ARG module

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

Docs: MessageBox Tennet module

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

Docs: National Transport Costs Calculation module

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

Docs: Pricing Data Brokers module

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

Docs: Process module

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

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: Spectral module

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

Docs: Tennet interface module

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

Docs: TRMTracker interface module

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

Docs: Workflow engine module

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

The Vertex Workflow Engine is used to handle temporal workflows.

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.