Velox Domain Model

Summary

This document describes the Velox product domain as represented by the velox repository. It is part of the internal Velox Product Knowledge Base (PKB), not end-user documentation.

Velox is an integration product for designing, executing, monitoring, and exposing business data flows. The source code models the product around persisted modules such as flows, folders, data connections, data definitions, maps, reports, scripts, variables, transports, APIs, setup, and logs. Velox Designer creates and maintains those modules. VeloxService runs background integration work. VeloxAPIService hosts REST/API-triggered flows.

The source code is the authority for this document. Where the code exposes a concept but the inspected source does not make behaviour clear, this document says that explicitly.

Related PKB Documents

• Architecture
• Developer Guide
• Knowledge Map
• Technical Review TODO

Source Basis

Primary source locations used for this domain model:

• Classes\Tools\vxTypes.pas - product enumerations for module types, file types, transports, execution types, action item types, logging states, authentication, database connection types, report output, schedule periods, and related domain lists.
• Classes\vxModule.pas - base module model, module persistence, relations, templates, logging classes, log files, transport logs, and system logs.
• Classes\vxFolder.pas - folder module and folder reparenting behaviour across module tables.
• Classes\vxSetup.pas - General Setup module and global gSetup.
• Classes\vxCon.pas, Classes\dmSystemDB.pas, Classes\vxSQLConnection.pas, Classes\vxSQLConPool.pas - system database connection, test/prod connection contexts, SQL connection class, and SQL connection pool.
• Classes\vxDBCon.pas, Classes\vxFileCon.pas - database and file connection modules.
• Classes\vxDataDef.pas, Classes\vxDBDef.pas, Classes\vxFileDef.pas, Classes\vxFileDefFlat.pas, Classes\vxFileDefXML.pas, Classes\vxFileDefJSON.pas, Classes\vxFileDefEDI.pas, Classes\vxFileDefExcel.pas - data definition concepts and file/database definition specialisations.
• Classes\vxActionMan.pas, Classes\vxActionPool.pas, Classes\Service\vxManagerExecution.pas, Classes\Service\vxManagerScheduler.pas, Classes\Service\vxManagerMonitor.pas, Classes\Service\vxManagerTransportIn.pas, Classes\Service\vxManagerTransportOut.pas, Classes\Service\vxManagerREST.pas - flows, action items, action pools, schedules, monitors, transport execution, and REST execution.
• Classes\Transports\*.pas - transport module base class and concrete transport classes for FTP, SFTP, LAN, HTTP, MSMQ, IBM MQ, IMAP, POP, and SMTP.
• Classes\vxMap.pas, Classes\vxReport.pas, Classes\vxSQLScript.pas, Classes\vxScriptlet.pas, Classes\vxScriptItem.pas, Classes\vxRouteItem.pas, Classes\vxVariables.pas, Classes\vxVariableGroup.pas, Classes\Tools\vxTags.pas - maps, reports, SQL scripts, scriptlets, script items, route items, variables, variable groups, and variable tag substitution.
• Classes\vxAPI.pas, VeloxAPIService\vxWebModule.pas - API modules, OpenAPI schema generation, API-action links, and WebBroker request dispatch.
• Classes\GUI\vxTreeNodes.pas - Designer navigation tree and module group concepts.
• Forms\*.pas, Forms\*.dfm, Forms\Transports\*.pas - Designer forms used to configure domain concepts.
• Velox.dpr, VeloxService.dpr, VeloxAPIService.dpr, VeloxService\classMain.pas, VeloxAPIService\classMain.pas - executable startup and runtime services.

Business Concept Overview

Product-Level Concepts

Velox

Purpose: Velox is the core integration product represented by this repository. It lets users configure connections, define data structures, transform and move data, run repeatable flows, expose selected flows as APIs, and inspect logs.

Relationships: Velox is composed of Velox Designer, VeloxService, VeloxAPIService, shared module classes, persisted configuration, and runtime logs. It also references concepts stored in sibling repositories, such as the VxData database and web portals, but those repositories are outside the source of truth for this document.

Lifecycle: A Velox environment is loaded when the executables start by loading the system connection, creating system logging, loading setup, and then creating the relevant UI or service runtime.

Configuration: Product-level configuration is stored through the system connection and TvxSetup. Module configuration is persisted by TvxModule descendants.

Where Used: All major source areas participate in the product model.

Related UI: The main Designer shell is Forms\frmMain.pas. The navigation model is built in Classes\GUI\vxTreeNodes.pas.

Related Runtime Behaviour: Designer edits configuration. VeloxService runs schedule, monitor, inbound transport, and outbound transport work. VeloxAPIService routes HTTP/API requests to configured REST flows.

Source: Velox.dpr, VeloxService.dpr, VeloxAPIService.dpr, Forms\frmMain.pas, Classes\GUI\vxTreeNodes.pas.

Velox Designer

Purpose: Velox Designer is the Windows GUI used to create, edit, test, export, import, inspect, and manage Velox configuration.

Relationships: Designer edits persisted TvxModule descendants. It can send service control and synchronization requests to VeloxService and VeloxAPIService through the service IPC paths shown in the service main classes.

Lifecycle: Designer startup loads the system connection, creates a system log, loads setup, and creates TMain. Mode changes reload scriptlets, variable groups, and system logging.

Configuration: Designer reads and writes module configuration through the same persistence classes used by services.

Where Used: Users use Designer for setup, folders, connections, definitions, transports, maps, reports, SQL scripts, scriptlets, variables, flows, APIs, logs, and module management.

Related UI: Forms\frmMain.pas, Classes\GUI\vxTreeNodes.pas, and setup forms under Forms\ and Forms\Transports\.

Related Runtime Behaviour: Designer can execute selected manual or test flows and can manage service state. The exact boundaries between Designer-run work and service-run work vary by action path; inspect the relevant form and action manager code before changing behaviour.

Source: Velox.dpr, Forms\frmMain.pas, Classes\GUI\vxTreeNodes.pas.

VeloxService

Purpose: VeloxService is the Windows background service for non-API runtime work.

Relationships: The service loads setup and variable groups, then creates managers for schedules, file monitors, inbound transports, and outbound transport queues. It uses action pools and flow execution classes to run configured flows.

Lifecycle: Service startup loads the system connection, creates system logging, creates TVeloxWorker, loads setup, loads variable groups, starts execution managers, synchronizes active work, and handles service IPC. Shutdown disables managers and releases runtime resources.

Configuration: Service behaviour is governed by General Setup and active flow/transport module configuration.

Where Used: Scheduled flows, monitored file flows, inbound transport polling, outbound transport sending/retry, service status reporting, and service control.

Related UI: Forms\frmSetupGeneral.pas and Forms\frmSetupGeneral.dfm expose service install/start/stop/uninstall controls and service settings. Flow setup forms expose execution and scheduling settings.

Related Runtime Behaviour: TvxScheduleManager, TvxMonitorManager, TvxTransportManagerIn, and TvxTransportManagerOut synchronize active configuration and create runtime work.

Source: VeloxService.dpr, VeloxService\classMain.pas, Classes\Service\vxManagerScheduler.pas, Classes\Service\vxManagerMonitor.pas, Classes\Service\vxManagerTransportIn.pas, Classes\Service\vxManagerTransportOut.pas.

VeloxAPIService

Purpose: VeloxAPIService is the Windows API service that hosts REST/API-triggered Velox flows.

Relationships: The API service loads setup and variable groups, creates TvxRESTManager, creates a web server, and dispatches WebBroker requests to matching REST flow endpoints.

Lifecycle: API service startup loads the system connection, creates system logging, creates TVeloxAPIWorker, loads setup, loads variable groups, creates the REST manager, and starts the web server. Runtime requests are dispatched through TRESTModule.WebModuleBeforeDispatch.

Configuration: API service host, port, SSL, certificate, and web-related values are in General Setup. API flow endpoint settings are on TvxActionMan flow modules. API grouping and OpenAPI metadata are stored on TvxAPI modules.

Where Used: REST/API-triggered flow execution and API service status/control.

Related UI: Forms\frmSetupGeneral.pas for API service settings and control; Forms\frmSetupActions.pas for REST execution properties; Forms\frmSetupAPI.pas for API/OpenAPI module configuration.

Related Runtime Behaviour: TvxRESTManager.Synchronise loads active REST flows, maps endpoints to TvxRESTItem, and ExecuteAPIForEndpoint dispatches GET/POST work from request threads. Behaviour for other HTTP methods is represented in enums and flow settings, but the inspected REST manager source clearly exposes GET and POST execution methods.

Source: VeloxAPIService.dpr, VeloxAPIService\classMain.pas, VeloxAPIService\vxWebModule.pas, Classes\Service\vxManagerREST.pas, Classes\vxAPI.pas.

Velox Environment

Purpose: A Velox environment is the configured runtime context that points executables at configuration, logging, and data databases.

Relationships: TvxConnection owns active and inactive config, log, and data connection contexts. Executables call gSystemConnection.Load during startup. Setup and modules are then loaded through those connections.

Lifecycle: The environment is loaded at process startup. Designer mode changes can switch active/inactive contexts and reload global state. Services load their runtime environment when the service worker starts.

Configuration: The system connection includes config, log, and data database concepts, test/prod labels, key fields, connection display names, and active/inactive connection accessors.

Where Used: All executables need the system connection before loading setup or modules.

Related UI: Environment/mode details appear in the Designer shell. Exact UI ownership for all system connection fields is not fully clear from the inspected source.

Related Runtime Behaviour: SQL accessors such as SQLC, SQLL, and SQLD route work to config, log, and data database connections.

Source: Classes\vxCon.pas, Classes\dmSystemDB.pas, Velox.dpr, VeloxService.dpr, VeloxAPIService.dpr.

General Setup

Purpose: General Setup stores product-wide configuration for email, service operation, API service operation, proxy settings, default file paths, runtime flags, and selected diagnostics.

Relationships: General Setup is a TvxSetup module and is loaded into global gSetup. Services and many modules read values from it.

Lifecycle: A setup module can be created and loaded through TvxSetup.CreateAndLoad. TvxSetup.New applies defaults. TvxSetup.Reload refreshes runtime values.

Configuration: Setup contains SMTP/email values, Azure/key vault values, API domain/port/SSL/certificate values, web domain/port/install path, service users, proxy settings, default file path, transport retry settings, debug and memory-check flags, safe report processing, reload-on-error, cache-manual-actions, SQL 2014 support, and service state.

Where Used: Startup, logging notification, transport/API communication, report processing options, service configuration, and Designer setup UI.

Related UI: Forms\frmSetupGeneral.pas and Forms\frmSetupGeneral.dfm.

Related Runtime Behaviour: Services read setup at startup. Email/log notification and proxy-enabled communication depend on setup values. API service host settings are sourced from setup.

Source: Classes\vxSetup.pas, Forms\frmSetupGeneral.pas, Forms\frmSetupGeneral.dfm.

Module and Configuration Concepts

Module

Purpose: A module is the persisted unit of Velox configuration. Most user-visible business objects are TvxModule descendants.

Relationships: Folders organize modules. Module relations record dependencies between modules. Modules can be imported/exported through module template behaviour.

Lifecycle: Modules are created with New, loaded with LoadModule, saved with SaveModule, archived/deleted through module code paths, and related through SaveModuleRelations.

Configuration: Base module fields include module id, module name, folder id/name, module type, active flag, archive state, description, and relation data. Descendants add concept-specific fields.

Where Used: Setup, folders, DB connections, file connections, DB definitions, file definitions, inbound and outbound transports, reports, SQL scripts, scriptlets, maps, flows, APIs, and variable groups.

Related UI: All module setup forms and the Designer tree.

Related Runtime Behaviour: Runtime services load active module records from the configuration database and execute or reference them by module id.

Source: Classes\vxModule.pas, Classes\Tools\vxTypes.pas.

Module Type

Purpose: Module type is the product taxonomy for persisted configuration objects.

Relationships: TvxModuleType maps module classes to user-facing module categories.

Lifecycle: Module type is assigned when a module class is created or loaded. It is persisted with modules.

Configuration: The source defines these module names: Module, Setup, Folder, DB Connection, File Connection, DB Definition, File Definition, Inbound Transport, Outbound Transport, Report, SQL Script, Scriptlet, Map, Flow, API, and Variable.

Where Used: Module persistence, Designer tree grouping, imports/exports, relation tracking, and type-specific setup forms.

Related UI: Designer tree group nodes in Classes\GUI\vxTreeNodes.pas.

Related Runtime Behaviour: Services filter and load active modules by module type and execution role.

Source: Classes\Tools\vxTypes.pas, Classes\vxModule.pas, Classes\GUI\vxTreeNodes.pas.

Folder

Purpose: Folders organize Velox modules in the Designer tree and persisted configuration.

Relationships: Folders are modules. Other modules hold a folder id. Deleting or moving a folder can update folder references across many module tables.

Lifecycle: Folders are created, saved, renamed, archived, deleted, and used to reparent contained modules.

Configuration: Folder configuration is persisted in VX_FOLDER and the base module fields.

Where Used: All module categories can be grouped under folders.

Related UI: Forms\frmSetupFolder.pas, folder tree nodes in Classes\GUI\vxTreeNodes.pas.

Related Runtime Behaviour: Folders are organizational. The inspected source does not show folders directly changing execution behaviour, except through module organization and dependency/reference maintenance.

Source: Classes\vxFolder.pas, Classes\GUI\vxTreeNodes.pas.

Module Relation

Purpose: Module relations record dependencies between modules so Velox can track usage and synchronize references.

Relationships: Relations connect parent modules to child modules and are persisted in VX_RELATION.

Lifecycle: Relations are saved when modules save their references. Usage checking and synchronization forms read these relations.

Configuration: Relation records are derived from module references rather than configured as a standalone business object in the UI.

Where Used: Dependency tracking, check usage, delete safety, module synchronization, and module import/export.

Related UI: Forms\frmCheckUsage.pas, Forms\frmModuleSync.pas.

Related Runtime Behaviour: Runtime execution relies on module references; relation records support maintenance and synchronization rather than being the runtime dispatcher themselves.

Source: Classes\vxModule.pas, Forms\frmCheckUsage.pas, Forms\frmModuleSync.pas.

Configuration Template

Purpose: A configuration template is an import/export package for module configuration.

Relationships: Templates package modules and related references. They are connected to module template logic and the config template importer.

Lifecycle: Templates can be exported to and imported from .cfg files. Import decisions include creating, updating, ignoring, or treating modules as same, based on importer code.

Configuration: Template contents are serialized by module template/config template classes. Exact full serialization structure should be checked before changing compatibility.

Where Used: Moving configuration between Velox environments and comparing/importing module sets.

Related UI: Forms\frmConfigTemplateImporter.pas.

Related Runtime Behaviour: Templates are maintenance/configuration artifacts. They do not appear to execute at runtime.

Source: Classes\vxConfigTemplate.pas, Classes\vxModule.pas, Forms\frmConfigTemplateImporter.pas.

Data Connection Concepts

Data Connection

Purpose: Data connections describe how Velox reaches external data locations used by data definitions, flows, maps, reports, scripts, and transports.

Relationships: The code has two main module concepts: DB Connection (TvxDBCon) and File Connection (TvxFileCon). Data definitions reference these connections.

Lifecycle: Connections are created in Designer, saved as modules, loaded by definitions and actions, and used at runtime during flow execution.

Configuration: Connection-specific settings are split between DB connection fields and file connection fields.

Where Used: DB definitions, file definitions, maps, reports, scripts, flows, and transports.

Related UI: Forms\frmSetupDBCon.pas, Forms\frmSetupFileCon.pas.

Related Runtime Behaviour: Runtime actions open database connections or file streams/directories through these modules.

Source: Classes\vxDBCon.pas, Classes\vxFileCon.pas, Classes\vxDataDef.pas.

DB Connection

Purpose: A DB Connection defines how Velox connects to a database.

Relationships: DB Definitions, SQL Scripts, and flow data source items can reference DB Connections through TvxDBLink and related fields.

Lifecycle: DB Connections are designed and tested in Designer, persisted in VX_DBCON, loaded at runtime, connected/disconnected, and optionally pooled/persistent depending on configuration.

Configuration: Key configuration includes connection type, host name, database, authentication type, username/password, provider name, ADO/ODBC search options, SQL dialect/type options, date quoting, alias/backquote options, SSL key/certificate, persistence, min/max connections, transactions, transaction isolation, trust certificate, and related driver/provider settings.

Where Used: DB Definitions, SQL Scripts, custom SQL action items, maps/reports using DB-backed definitions, and internal config/log/data database access.

Related UI: Forms\frmSetupDBCon.pas, database explorer forms.

Related Runtime Behaviour: Runtime can connect, disconnect, test connections, begin/commit/rollback transactions, and use pooled SQL connections. Some default/special DB connection module ids are present for _Data and _Config.

Source: Classes\vxDBCon.pas, Classes\vxSQLConnection.pas, Classes\vxSQLConPool.pas.

Supported Database Connection Types

Purpose: Supported database connection types define the external database platforms that DB Connection configuration can target.

Relationships: TRegConType is used by TvxSQLConnection and DB Connection configuration.

Lifecycle: The selected type is stored as DB Connection configuration and interpreted when connecting.

Configuration: The enum lists Microsoft SQL Server, Oracle, MySQL, PostgreSQL, IBM DB2, ADO, and ODBC. SQL authentication enum values include Windows Authentication, SQL Server Authentication, Entra MFA, Entra Password, Entra Integrated, Entra Service Principal, and Entra Managed Identity.

Where Used: DB Connection setup and runtime database connection creation.

Related UI: Forms\frmSetupDBCon.pas.

Related Runtime Behaviour: The actual driver behaviour depends on TvxSQLConnection, provider settings, and installed client drivers. The source confirms enum support; it does not prove every platform is valid in every deployed environment.

Source: Classes\Tools\vxTypes.pas, Classes\vxDBCon.pas, Classes\vxSQLConnection.pas.

File Connection

Purpose: A File Connection defines where Velox reads, writes, audits, moves, errors, issues, duplicates, or transports files.

Relationships: File Definitions and transports reference File Connections. File Router action items route files between File Connections.

Lifecycle: File Connections are created in Designer, persisted in VX_FILECON, checked for required directories, and used at runtime to locate, copy, move, or name files.

Configuration: Key configuration includes file name, search pattern, source directory, audit directory, transport directory, error directory, issue directory, duplicate directory, temp directory, counter/unique-name options, safe-name option, wait-for setting, and inbound file naming behaviour.

Where Used: File Definitions, inbound/outbound transports, file monitor flows, file router actions, maps/reports that use file-backed definitions, and log file records.

Related UI: Forms\frmSetupFileCon.pas.

Related Runtime Behaviour: Runtime code can match search patterns, check directories, copy/move/delete files, process file paths and names, move files to audit/transport/error/issue/duplicate/temp paths, and create file log events.

Source: Classes\vxFileCon.pas, Classes\vxActionMan.pas, Classes\Transports\vxTransport.pas.

File Event

Purpose: File events describe business states for files handled by Velox.

Relationships: File events are tied to File Connections, flow logs, and log file records.

Lifecycle: File events are created during runtime file handling and stored with log file records.

Configuration: The enum includes None, Read, Write, Downloaded, Audited, Errored, Issue, Moved Temp, Transporting, and Deleted.

Where Used: File handling, logging, and transport processing.

Related UI: Log detail and file/log management forms.

Related Runtime Behaviour: File events are emitted when files are moved or processed by file connections, transports, and flow actions.

Source: Classes\Tools\vxTypes.pas, Classes\vxFileCon.pas, Classes\vxModule.pas.

Data Definition Concepts

Data Definition

Purpose: A Data Definition describes the structure and access rules for business data used by Velox.

Relationships: The code has DB Definitions and File Definitions as specialisations of TvxDataDef. Maps and reports derive from TvxDefModule and reference data definitions. Flows use source/destination definition managers.

Lifecycle: Data Definitions are designed in Designer, saved as modules, loaded by maps/reports/flows/transports, opened/closed at runtime, and can save data.

Configuration: Common settings include source definition items, source/file connection references, runtime popup behaviour, DB change allowance, unique transaction, auto-search entries, disable string trim, truncate strings, and data module/runtime state.

Where Used: Maps, reports, flows, transports, file monitor work, and runtime data processing.

Related UI: DB Definition and File Definition setup forms.

Related Runtime Behaviour: Definitions open and close data, create data views, save data, copy views, and connect to file or database modules depending on definition type.

Source: Classes\vxDataDef.pas, Classes\vxDBDef.pas, Classes\vxFileDef.pas, Classes\vxMap.pas, Classes\vxReport.pas.

Data Definition Item

Purpose: A definition item represents a specific source/view/table/file structure within a data definition.

Relationships: Definition items connect data definitions to sources, file connections, database connections, auto-search entries, and runtime data views.

Lifecycle: Definition items are created when designing definitions, then loaded as part of the definition at runtime.

Configuration: Item settings include source name/id, source type, file connection, runtime popup flag, allow DB change flag, unique transaction flag, DB connection list, and auto-search items.

Where Used: DB Definitions, File Definitions, maps, reports, and flow source managers.

Related UI: Definition setup forms and map/report data selection UI.

Related Runtime Behaviour: Definition items drive which source data is opened, searched, and passed through execution.

Source: Classes\vxDataDef.pas.

Auto Search

Purpose: Auto Search defines automatic lookup/search values associated with data definition items.

Relationships: Auto Search items belong to TvxDefItem.

Lifecycle: Auto Search entries are configured with definitions and used when opening/searching data. The exact user workflow is not fully clear from the inspected source.

Configuration: Auto Search fields include source field/value concepts exposed by TvxAutoSearchItem.

Where Used: Data definitions and data opening/searching.

Related UI: Definition setup forms. Specific controls were not exhaustively traced.

Related Runtime Behaviour: Used by data definition runtime search/open paths. Exact business rules need source-level inspection before changing.

Source: Classes\vxDataDef.pas.

DB Definition

Purpose: A DB Definition describes database-backed business data.

Relationships: DB Definitions reference DB Connections and are used by maps, reports, flows, SQL/scripted work, and data views.

Lifecycle: DB Definitions can be created blank, designed, opened, saved, and used to update/customise id fields.

Configuration: DB Definition configuration includes source items, DB connection references, update-id-fields options, custom id field/value, and inherited Data Definition settings.

Where Used: Database-backed maps, reports, flow source/destination data, and SQL-related workflows.

Related UI: Forms\frmSetupDBDefs.pas.

Related Runtime Behaviour: Runtime opens data through DB connections, saves data, checks primary key fields, creates/clears primary keys, and updates custom id fields.

Source: Classes\vxDBDef.pas, Classes\vxDataDef.pas.

File Definition

Purpose: A File Definition describes file-backed business data and how Velox reads or writes that file format.

Relationships: File Definitions reference File Connections and use file engines for flat, XML, JSON, EDI, and Excel data. Transports can use file definitions to interpret payloads.

Lifecycle: File Definitions can be created blank, auto-designed, designed, load files, open data, save data, generate blank XML/JSON documents, and process schemas/templates.

Configuration: Common configuration includes file type, file connection, encoding, line breaks, schema/template settings, XML namespace and validation settings, JSON schema settings, EDI delimiters, flat file delimiter settings, Excel format/template/password settings, and inherited Data Definition settings.

Where Used: File-backed maps, reports, flows, transports, file monitors, and file router processing.

Related UI: Forms\frmSetupFileDefFlat.pas, Forms\frmSetupFileDefXML.pas, Forms\frmSetupFileDefJSON.pas, Forms\frmSetupFileDefExcel.pas, Forms\frmSetupFileDefEDI.pas.

Related Runtime Behaviour: Runtime selects the appropriate file engine, loads/saves file data, determines MIME type, processes XML/JSON schemas or Excel templates, and can convert DB sources to file definitions.

Source: Classes\vxFileDef.pas, Classes\vxFileDefFlat.pas, Classes\vxFileDefXML.pas, Classes\vxFileDefJSON.pas, Classes\vxFileDefEDI.pas, Classes\vxFileDefExcel.pas.

Supported File Types

Purpose: Supported file types describe the file formats Velox models through File Definitions.

Relationships: TvxFileType selects the file definition/file engine behaviour.

Lifecycle: File type is selected when a File Definition is designed and is then used whenever that definition opens or saves data.

Configuration: The enum lists Flat File, XML File, EDI File, Excel File, JSON File, and an OLD value. Related configuration includes file encoding values ASCII, ANSI, UTF-8, UTF-16, and UTF-16 BE; line break values Segment Terminator Only, LF, CRLF, and Custom; and Excel formats XLS and XLSX.

Where Used: File Definition design, file engines, transport payload handling, file import/export, and MIME type behaviour.

Related UI: File Definition setup forms.

Related Runtime Behaviour: Each file type uses a dedicated file definition/engine path. The meaning of the OLD value is not clear from the inspected source and should be treated as legacy unless proven otherwise.

Source: Classes\Tools\vxTypes.pas, Classes\vxFileDef.pas.

Flow and Orchestration Concepts

Flow

Purpose: A Flow is the primary business process orchestration concept in Velox. The code still uses the class name TvxActionMan and database table VX_ACTION, reflecting that flows were previously called actions.

Relationships: A Flow contains ordered action items, references source and destination data, can use maps, reports, scripts, SQL, transports, linked flows, variables, APIs, logs, schedules, monitors, and REST endpoints.

Lifecycle: Flows are created in Designer, configured with execution type and action items, saved as modules, loaded by services or Designer, synchronized into execution managers, executed manually/scheduled/monitored/API/linked, logged, retried depending on settings, and disabled/archived/deleted through module management.

Configuration: Flow configuration includes execution type, schedule settings, file monitor settings, max threads, linked action references, retry settings, REST method/endpoint/groups/summary/description/documentation/params/result definitions, request and response definitions, log status sets, notification settings, default email usage, admin/notify email, SQL logging, HTTP communication logging, file data logging, and transport communication logging.

Where Used: Designer flow setup, VeloxService schedule/monitor/transport runtime, VeloxAPIService REST runtime, API module publishing, logs, and action pool execution.

Related UI: Forms\frmSetupActions.pas, flow tree nodes in Classes\GUI\vxTreeNodes.pas, Designer run/test/status actions in Forms\frmMain.pas.

Related Runtime Behaviour: Flows execute through TvxActionMan.Execute, ExecuteOnce, ExecuteLinkedAction, and ExecuteFlow. Runtime execution can be pooled through TvxActionPool and managed by schedule, monitor, transport, and REST managers.

Source: Classes\vxActionMan.pas, Classes\vxActionPool.pas, Classes\Service\*.pas, Forms\frmSetupActions.pas.

Flow Execution Type

Purpose: Execution type defines how a Flow is triggered.

Relationships: A Flow has an execution type that determines whether the service managers, REST manager, or manual execution paths use it.

Lifecycle: Execution type is configured in the flow setup and read during synchronization/execution.

Configuration: The enum lists Manual, Scheduled, Monitor, REST API Call, Linked Flow, and Old.

Where Used: Flow setup, service synchronization, REST synchronization, linked flow execution, and Designer/manual execution.

Related UI: Flow setup forms.

Related Runtime Behaviour: Scheduled flows are synchronized by TvxScheduleManager; monitor flows by TvxMonitorManager; REST flows by TvxRESTManager; linked flows can be invoked by another flow. The Old enum value is not clear from inspected source.

Source: Classes\Tools\vxTypes.pas, Classes\vxActionMan.pas, Classes\Service\vxManagerScheduler.pas, Classes\Service\vxManagerMonitor.pas, Classes\Service\vxManagerREST.pas.

Action Item

Purpose: An Action Item is a step inside a Flow.

Relationships: Action Items belong to a Flow and can reference maps, reports, transports, APIs, file routes, shell commands, SQL commands, custom scripts, or linked flows.

Lifecycle: Action Items are created in flow setup, saved under the Flow, loaded at runtime, and executed in flow order.

Configuration: Common settings include action id/name/type, active flag, source, destination, and ignore-empty-source-data option. Each subtype adds its own configuration.

Where Used: Every Flow execution.

Related UI: Flow setup forms and action step panels.

Related Runtime Behaviour: TvxActionMan dispatches action items as part of flow execution. The enum also lists historical or less-traced types such as Call Plugin, Transaction Commit, DB Disconnect, and Wait for File; dedicated current classes for every enum value were not confirmed in the inspected class list.

Source: Classes\vxActionMan.pas, Classes\Tools\vxTypes.pas, Forms\frmSetupActions.pas.

Map Action Item

Purpose: A Map action applies a configured map inside a Flow.

Relationships: It references a TvxMap module and flow source/destination data.

Lifecycle: Created as a flow step, loaded with its map reference, executed during flow execution, and logged through the parent flow.

Configuration: Map action configuration includes the selected map plus common action item fields.

Where Used: Data transformation flows.

Related UI: Flow setup map action panel; map setup forms.

Related Runtime Behaviour: Runtime invokes map execution from the action item.

Source: Classes\vxActionMan.pas, Classes\vxMap.pas.

Report Action Item

Purpose: A Report action produces report output inside a Flow.

Relationships: It references a TvxReport module and can use flow data and email/file output settings.

Lifecycle: Created as a flow step, loaded with report/output settings, executed during flow execution, and logged.

Configuration: Report action configuration includes output destination, output type, output details, file details, attachment, miscellaneous options, and BCC email.

Where Used: Reporting and document generation flows.

Related UI: Flow setup report action panel; report setup forms.

Related Runtime Behaviour: Runtime invokes report execution and output handling.

Source: Classes\vxActionMan.pas, Classes\vxReport.pas.

Custom Script Action Item

Purpose: A Custom Script action evaluates scripted logic inside a Flow.

Relationships: It owns script item children and may reference flow data, variables, scriptlets, and runtime context.

Lifecycle: Script items are configured with the action item, compiled/checked, then executed during flow execution.

Configuration: Formula/script text and compiled status are managed by TvxScriptItem.

Where Used: Custom business rules and conditional processing.

Related UI: Flow setup script action panel and script editors.

Related Runtime Behaviour: Runtime executes script formulas through script item logic. The exact scripting language/runtime should be checked in the scripting classes before changing formulas or compatibility.

Source: Classes\vxActionMan.pas, Classes\vxScriptItem.pas, Classes\vxScriptlet.pas.

Transport Action Item

Purpose: A Transport action sends or receives data through a configured transport module.

Relationships: It references a transport module and transport class. API actions inherit from the transport action class in the code.

Lifecycle: Created as a flow step, saved with transport reference, loaded at runtime, and executed as part of flow execution.

Configuration: Common action item settings plus transport id/name/class reference.

Where Used: Flows that perform inbound or outbound communication.

Related UI: Flow setup transport action panel and transport setup forms.

Related Runtime Behaviour: Runtime executes transport send/download logic through TvxTransport descendants.

Source: Classes\vxActionMan.pas, Classes\Transports\vxTransport.pas.

API Action Item

Purpose: TvxActionAPI is a source-visible transport-derived action item class intended for HTTP outbound/API calls.

Relationships: It inherits from TvxActionTransport.

Lifecycle: The inspected source confirms the class relationship and constructor default to HTTP outbound transport, but TvxActionAPI is not registered in the current Classes\vxActionMan.pas initialization block and no main flow setup creation path was found. Treat it as source-visible or incomplete rather than a confirmed current Designer action step.

Configuration: Uses inherited transport action configuration.

Where Used: No active runtime or setup creation path was confirmed in this review.

Related UI: No current main flow setup label or add-action command was confirmed.

Related Runtime Behaviour: Runtime behaviour follows transport action inheritance unless overridden elsewhere; no distinct behaviour was confirmed in the inspected snippet.

Source: Classes\vxActionMan.pas.

File Router Action Item

Purpose: A File Router action routes files to configured File Connections based on route items/events.

Relationships: It owns route items (TvxRouteItem) that link to File Connections and inherit script item behaviour.

Lifecycle: Routes are configured under the action item, loaded during flow execution, evaluated, and files are moved/routed through File Connection logic.

Configuration: Route items include file connection reference and script/formula fields.

Where Used: File-based integration flows.

Related UI: Flow setup routing event panels.

Related Runtime Behaviour: Runtime evaluates route conditions and moves/copies files through File Connection operations. Exact route evaluation order should be checked before changing behaviour.

Source: Classes\vxActionMan.pas, Classes\vxRouteItem.pas, Classes\vxFileCon.pas.

Shell Execute Action Item

Purpose: A Shell Execute action runs an external command line process.

Relationships: It is an action item inside a Flow and can use configured credentials/parameters.

Lifecycle: Created as a flow step, loaded with command settings, executed during flow runtime.

Configuration: Command line, username, password, domain, parameters, delay, use-shell-execute flag, and wait-for-process flag.

Where Used: Flows that need to call external processes.

Related UI: Flow setup command line action panel.

Related Runtime Behaviour: Runtime starts external processes. Process execution security and 32-bit/64-bit behaviour should be reviewed carefully before changes.

Source: Classes\vxActionMan.pas.

SQL Action Item

Purpose: A SQL action runs a configured SQL command inside a Flow.

Relationships: It is an action item and can reference DB connection context through source/destination data or SQL command settings.

Lifecycle: Created as a flow step, loaded with SQL command, executed during flow runtime.

Configuration: SQL command text plus common action item settings.

Where Used: Flows needing custom SQL work.

Related UI: Flow setup SQL command panel.

Related Runtime Behaviour: Runtime executes SQL against configured database context. Transaction behaviour depends on flow, DB connection, and action-specific implementation.

Source: Classes\vxActionMan.pas, Classes\vxDBCon.pas.

Linked Flow Action Item

Purpose: A Sub Action / linked-flow step calls another Flow from the current Flow.

Relationships: The current action-step class is TvxActionSubAction, using the legacy enum display value Call Action. This is separate from a Flow configured with execution type fstLinkedAction, which runs after another parent Flow.

Lifecycle: Configured as a flow step, saved with the target flow id/name, loaded at runtime, and executed through TvxActionSubAction.Execute. Linked Flow execution through LinkedActionFID/LinkedActionOrder is a related but distinct post-success flow chaining path.

Configuration: Linked action reference plus common action item settings.

Where Used: Flow composition and reuse.

Related UI: Main Flow setup exposes Add Action > Sub Action and Linked Flow execution settings.

Related Runtime Behaviour: Sub-action runtime uses TvxActionSubAction.Execute; post-success linked-flow runtime uses ExecuteLinkedAction and linked-action loading paths. Ordering is influenced by LinkedActionOrder and related flow settings.

Source: Classes\vxActionMan.pas, Forms\frmSetupActions.pas.

Schedule

Purpose: A Schedule triggers a Flow at configured times or intervals.

Relationships: Scheduled flows are managed by TvxScheduleManager and schedule item classes.

Lifecycle: Schedule settings are configured on a Flow, synchronized by VeloxService, timers are created/updated, and actions execute when timers fire.

Configuration: Schedule period, run-once-immediately, repeat interval/period, day interval, month day, recurrence flag, start/end time, week days, and schedule type.

Where Used: VeloxService scheduled execution.

Related UI: Flow setup schedule/execution settings.

Related Runtime Behaviour: TvxScheduleManager creates schedule items and timer handlers that call action execution.

Source: Classes\vxActionMan.pas, Classes\Service\vxManagerScheduler.pas, Classes\Tools\vxTypes.pas.

File Monitor

Purpose: A File Monitor triggers a Flow when matching files appear in a monitored directory.

Relationships: Monitor flows reference File Connections and file patterns. TvxMonitorManager owns monitor items and a monitor file queue thread.

Lifecycle: Monitor settings are configured on a Flow, synchronized by VeloxService, monitored files are queued, and the flow executes when work is detected.

Configuration: File monitor flag, file connection id, file pattern, directory, and inherited execution item fields.

Where Used: File-based inbound integrations.

Related UI: Flow setup monitor/execution settings.

Related Runtime Behaviour: TvxMonitorFileQueue processes queued file work. Exact filesystem event/debounce semantics should be checked in monitor manager code before changing behaviour.

Source: Classes\vxActionMan.pas, Classes\Service\vxManagerMonitor.pas, Classes\vxFileCon.pas.

Retry and Reprocessing

Purpose: Retry and reprocessing settings control how a Flow reacts to execution failure or repeat processing needs.

Relationships: These settings live on Flow configuration and influence runtime execution managers/action execution.

Lifecycle: Configured in Designer, persisted on the Flow, read during runtime execution.

Configuration: AutoRetry, AutoRetryCount, AutoRetryWaitSeconds, ReprocessUntilError, IgnoreCancel, and related status/log settings.

Where Used: Flow execution paths and service-managed work.

Related UI: Flow setup forms.

Related Runtime Behaviour: The code contains DoReprocessUntilError and retry-related properties. Exact retry timing and status transition rules should be verified in TvxActionMan before changing behaviour.

Source: Classes\vxActionMan.pas.

Transport Concepts

Transport

Purpose: A Transport defines a channel for receiving or sending files/messages/data between Velox and external systems.

Relationships: Transports are modules. A transport has a direction, protocol-specific subclass, optional file definition/file connection, script items, log settings, authentication, certificates/keys, and runtime log links. Flows use transport action items or service transport managers to execute transport work.

Lifecycle: Transports are configured in Designer as inbound or outbound modules, saved as configuration, loaded by flows/services, executed for download/send, finalized, and logged.

Configuration: Base configuration includes host, port, authentication type, username/password, OAuth client/tenant/scope/auth/token URL fields, direction, SSL certificate/key/root certificate settings, private key, timeouts, and protocol-specific properties.

Where Used: Inbound transport polling, outbound transport queues, transport action items, file-based flows, and logs.

Related UI: Transport forms under Forms\Transports\.

Related Runtime Behaviour: TvxTransport.StartDownload, StartSend, Execute, and Finalise define base lifecycle hooks; subclasses implement protocol-specific behaviour.

Source: Classes\Transports\vxTransport.pas, Classes\Transports\*.pas, Classes\Service\vxManagerTransportIn.pas, Classes\Service\vxManagerTransportOut.pas.

Transport Direction

Purpose: Direction describes whether a transport is inbound, outbound, or supports both.

Relationships: Direction is part of transport configuration and supported-transport metadata.

Lifecycle: Direction is selected by module type or transport class and read when service managers decide how to execute transport work.

Configuration: The direction enum lists Inbound, Outbound, and Inbound & Outbound.

Where Used: Transport setup, inbound manager, outbound manager, flow transport action setup.

Related UI: Inbound and outbound transport tree groups and setup forms.

Related Runtime Behaviour: Inbound transports are managed by inbound transport manager/polling. Outbound transports are managed by outbound queue/send logic.

Source: Classes\Tools\vxTypes.pas, Classes\Transports\vxTransport.pas, Classes\Service\vxManagerTransportIn.pas, Classes\Service\vxManagerTransportOut.pas.

Supported Transport Types

Purpose: Supported transport types define the communication protocols exposed by the Velox transport domain.

Relationships: TvxTransportType lists FTP, SFTP, LAN, HTTP, MSMQ, IBM MQ, IMAP, POP3, Email, and AS2. Concrete classes were found for FTP, SFTP, LAN, HTTP, MSMQ, IBM MQ, IMAP, POP, and SMTP/email.

Lifecycle: Transport type/class is selected when configuring a transport and then used during runtime execution.

Configuration: Transport-specific configuration is stored on each subclass and edited through corresponding forms.

Where Used: Transport setup, flow transport action items, inbound/outbound service managers, logs.

Related UI: Forms\Transports\frmTransportFTPIn.pas, frmTransportFTPOut.pas, frmTransportSFTPIn.pas, frmTransportSFTPOut.pas, frmTransportLANIn.pas, frmTransportLANOut.pas, frmTransportHTTPIn.pas, frmTransportHTTPOut.pas, frmTransportMSMQIn.pas, frmTransportMSMQOut.pas, frmTransportIBMMQIn.pas, frmTransportIBMMQOut.pas, frmTransportIMAP.pas, frmTransportPOP.pas, and frmTransportSMTP.pas.

Related Runtime Behaviour: Runtime dispatches to concrete transport classes. AS2 is listed in the enum, but a concrete AS2 transport class was not found in the inspected source; AS2 runtime support is therefore unclear from this repository snapshot.

Source: Classes\Tools\vxTypes.pas, Classes\Transports\*.pas, Forms\Transports\*.pas.

FTP Transport

Purpose: FTP transports move files through FTP.

Relationships: FTP has inbound and outbound classes and inherits base transport behaviour.

Lifecycle: Configured as inbound or outbound, loaded by transport managers or flow actions, sends/downloads files, and logs transport/file events.

Configuration: FTP-specific settings include path, transfer type, protected data port, CCC usage, passive mode, move-to-folder name, control timeout, and transfer timeout.

Where Used: File transfer integrations using FTP.

Related UI: Forms\Transports\frmTransportFTPIn.pas, Forms\Transports\frmTransportFTPOut.pas.

Related Runtime Behaviour: Inbound and outbound FTP classes perform protocol-specific receiving/sending. Exact server command sequencing should be checked in the FTP transport source.

Source: Classes\Transports\vxTransportFTP.pas, Classes\Transports\vxTransportFTPIn.pas, Classes\Transports\vxTransportFTPOut.pas.

SFTP Transport

Purpose: SFTP transports move files through SFTP.

Relationships: SFTP has inbound and outbound classes and inherits base transport behaviour.

Lifecycle: Configured as inbound or outbound, loaded by transport managers or flow actions, sends/downloads files, and logs transport/file events.

Configuration: SFTP-specific settings include path, move-to-folder name, SFTP version, SFTP authentication type, control timeout, and transfer timeout.

Where Used: Secure file transfer integrations using SFTP.

Related UI: Forms\Transports\frmTransportSFTPIn.pas, Forms\Transports\frmTransportSFTPOut.pas.

Related Runtime Behaviour: Inbound and outbound SFTP classes perform protocol-specific receiving/sending.

Source: Classes\Transports\vxTransportSFTP.pas, Classes\Transports\vxTransportSFTPIn.pas, Classes\Transports\vxTransportSFTPOut.pas.

LAN Transport

Purpose: LAN transports move files through local or network file system locations.

Relationships: LAN has inbound and outbound classes and uses File Connection/file system concepts.

Lifecycle: Configured as inbound or outbound, loaded by transport managers or flow actions, copies/moves files, and logs events.

Configuration: LAN-specific configuration includes inbound after-receiving and wait-for behaviour plus inherited transport settings.

Where Used: File share integrations.

Related UI: Forms\Transports\frmTransportLANIn.pas, Forms\Transports\frmTransportLANOut.pas.

Related Runtime Behaviour: Runtime performs filesystem-based send/receive work. Exact locking/wait semantics should be checked in LAN transport code before changing behaviour.

Source: Classes\Transports\vxTransportLAN.pas, Classes\Transports\vxTransportLANIn.pas, Classes\Transports\vxTransportLANOut.pas.

HTTP Transport

Purpose: HTTP transports send or receive payloads through HTTP.

Relationships: HTTP has inbound and outbound classes and uses base transport authentication, proxy, SSL, and logging concepts.

Lifecycle: Configured as inbound or outbound, loaded by runtime, performs HTTP requests or receives HTTP-triggered transport work, and logs communication.

Configuration: HTTP-specific settings include headers, follow-location, handle-redirects, protocol version, inbound receive method, and outbound send method.

Where Used: HTTP integrations and API-like transport workflows.

Related UI: Forms\Transports\frmTransportHTTPIn.pas, Forms\Transports\frmTransportHTTPOut.pas.

Related Runtime Behaviour: Runtime can log HTTP communications when enabled. Method support is represented by HTTP method enums and transport settings.

Source: Classes\Transports\vxTransportHTTP.pas, Classes\Transports\vxTransportHTTPIn.pas, Classes\Transports\vxTransportHTTPOut.pas, Classes\Tools\vxTypes.pas.

MSMQ Transport

Purpose: MSMQ transports exchange messages through Microsoft Message Queuing.

Relationships: MSMQ has inbound and outbound classes and inherits base transport behaviour.

Lifecycle: Configured as inbound or outbound, loaded by transport runtime, reads/writes messages, and logs execution.

Configuration: MSMQ-specific settings include visibility, queue name, delivery type, transaction usage, direct format name usage, direct format type, and authenticate flag.

Where Used: Queue-based integrations using MSMQ.

Related UI: Forms\Transports\frmTransportMSMQIn.pas, Forms\Transports\frmTransportMSMQOut.pas.

Related Runtime Behaviour: Runtime uses MSMQ-specific classes to read/write queue messages. Queue transaction behaviour depends on MSMQ settings.

Source: Classes\Transports\vxTransportMSMQ.pas, Classes\Transports\vxTransportMSMQIn.pas, Classes\Transports\vxTransportMSMQOut.pas.

IBM MQ Transport

Purpose: IBM MQ transports exchange messages through IBM MQ.

Relationships: IBM MQ has inbound and outbound classes and uses connection manager, queue, and channel concepts.

Lifecycle: Configured as inbound or outbound, loaded by transport runtime, exchanges MQ messages, and logs execution.

Configuration: IBM MQ-specific settings include connection manager, queue name, and channel name.

Where Used: Queue-based integrations using IBM MQ.

Related UI: Forms\Transports\frmTransportIBMMQIn.pas, Forms\Transports\frmTransportIBMMQOut.pas.

Related Runtime Behaviour: Runtime uses IBM MQ-specific classes to send/receive messages. Exact IBM MQ library/runtime dependency should be checked in source and deployment files.

Source: Classes\Transports\vxTransportIBMMQ.pas, Classes\Transports\vxTransportIBMMQIn.pas, Classes\Transports\vxTransportIBMMQOut.pas.

IMAP Transport

Purpose: IMAP transport receives email/messages through IMAP.

Relationships: IMAP is inbound and inherits base transport authentication/SSL behaviour.

Lifecycle: Configured as an inbound transport, loaded by inbound manager or flow action, receives messages, handles after-receiving behaviour, and logs results.

Configuration: IMAP-specific settings include mailbox, after-receiving, move-to-mailbox, SASL usage, from email, and to email.

Where Used: Email inbound integrations.

Related UI: Forms\Transports\frmTransportIMAP.pas.

Related Runtime Behaviour: Runtime downloads/reads mail and can move or process messages according to configuration.

Source: Classes\Transports\vxTransportIMAP.pas.

POP Transport

Purpose: POP transport receives email/messages through POP3.

Relationships: POP is inbound and inherits base transport authentication/SSL behaviour.

Lifecycle: Configured as an inbound transport, loaded by inbound manager or flow action, receives messages, applies after-receiving behaviour, and logs results.

Configuration: POP-specific settings include after-receiving and SASL usage.

Where Used: Email inbound integrations.

Related UI: Forms\Transports\frmTransportPOP.pas.

Related Runtime Behaviour: Runtime downloads/reads messages through POP-specific classes.

Source: Classes\Transports\vxTransportPOP.pas.

SMTP / Email Transport

Purpose: SMTP transport sends email and email attachments.

Relationships: SMTP is outbound and inherits base transport authentication/SSL behaviour. It also relates to General Setup email defaults.

Lifecycle: Configured as an outbound transport, loaded by outbound manager or flow action, sends email, and logs results.

Configuration: SMTP-specific settings include to/cc/bcc email, subject, read receipt, load attachment to body/html body flags, body text, and body HTML.

Where Used: Email outbound integrations and report/log notification scenarios.

Related UI: Forms\Transports\frmTransportSMTP.pas, General Setup email tab.

Related Runtime Behaviour: Runtime sends email through SMTP transport or shared email setup paths. Exact reuse between transport email and log notification should be checked before changing shared email behaviour.

Source: Classes\Transports\vxTransportSMTP.pas, Classes\vxSetup.pas.

Transport Authentication

Purpose: Authentication settings describe how Velox authenticates external communication.

Relationships: Transport and HTTP/email concepts use TvxAuthType; DB Connections use TvxSQLAuthType.

Lifecycle: Authentication is configured on connection/transport modules and used during runtime connect/send/receive.

Configuration: General auth values include None, Basic clear text, Bearer Token, Microsoft OAuth, Google OAuth, Netsuite OAuth, Custom OAuth, Windows SSPI, and NTLM old. Auth scopes include SMTP, IMAP, POP, and HTTP.

Where Used: Transports, HTTP, email, proxy, and DB connection setup.

Related UI: DB connection setup, transport setup forms, General Setup proxy/email tabs.

Related Runtime Behaviour: Runtime maps auth settings to protocol libraries. Exact OAuth token caching/refresh behaviour should be verified in the relevant transport/auth source before changes.

Source: Classes\Tools\vxTypes.pas, Classes\Transports\vxTransport.pas, Classes\vxDBCon.pas, Classes\vxSetup.pas.

Transformation, Reporting, and Script Concepts

Map

Purpose: A Map transforms data between source and destination definitions.

Relationships: Maps are modules derived from TvxDefModule. They contain view maps, field maps, variables, and script events. Flow map action items invoke maps.

Lifecycle: Maps can be created from definitions, designed, synchronized, saved, and executed in flows.

Configuration: Map configuration includes source/destination views, field maps, event formulas, global script, save-data flag, ignore-empty-source-data flag, use-XSINil-for-nulls flag, and runtime counters/state.

Where Used: Data transformation flows.

Related UI: Forms\frmSetupMaps.pas, Forms\frmSetupMapDesign.pas, map flow action panels.

Related Runtime Behaviour: Runtime creates data sources, executes maps, applies scripts/event formulas, writes destination data when configured, and logs execution through the parent flow.

Source: Classes\vxMap.pas, Classes\vxActionMan.pas.

Map View

Purpose: A Map View groups mapping behaviour for a source/destination view or data set.

Relationships: Map Views belong to Maps and contain Field Maps.

Lifecycle: Created during map design or map-from-definition creation, loaded with the map, and executed during map processing.

Configuration: View-level event formulas include before/on/after map and related detail/linked data events.

Where Used: Map design and runtime mapping.

Related UI: Map designer forms.

Related Runtime Behaviour: View events run around record/view mapping. Exact event ordering should be verified in TvxMap.Execute before changing scripts.

Source: Classes\vxMap.pas.

Field Map

Purpose: A Field Map defines how an individual destination field is populated or transformed.

Relationships: Field Maps belong to Map Views and can use formula/script concepts.

Lifecycle: Created during map design, saved with the map, and evaluated during map execution.

Configuration: Field mapping stores source/destination field relationships, field type, and event/formula values.

Where Used: Map designer and map runtime.

Related UI: Map designer field mapping panels.

Related Runtime Behaviour: Runtime evaluates field expressions and writes destination values.

Source: Classes\vxMap.pas, Classes\Tools\vxTypes.pas.

Report

Purpose: A Report defines printable/exportable output based on Velox data definitions.

Relationships: Reports are modules derived from TvxDefModule. Flow report action items invoke reports. Reports use report output destination/type enums.

Lifecycle: Reports can be created from definitions, designed, executed, and output to configured destinations.

Configuration: Report configuration includes source data, no-data print option, split report option, ignore report errors, embed fonts in PDF, and action-level output destination/type settings.

Where Used: Reporting flows and Designer report setup.

Related UI: Forms\frmSetupReports.pas, report designer components, report flow action panels.

Related Runtime Behaviour: Runtime executes reports, creates report output, and can send/save/print depending on configured action output.

Source: Classes\vxReport.pas, Classes\vxActionMan.pas, Classes\Tools\vxTypes.pas.

Report Output

Purpose: Report output concepts define where and in what format reports are produced.

Relationships: Report action items use output destination and output type enums.

Lifecycle: Output values are configured on report action items and applied during report execution.

Configuration: Destinations include screen/viewer, printer, file, and email. Output types include PDF, HTML, PNG, JPEG, BMP, Excel xlsx, Excel xls, RTF, and XHTML.

Where Used: Report action items and report execution.

Related UI: Flow setup report details and report setup forms.

Related Runtime Behaviour: Runtime output handling depends on the selected destination/type. Exact formatting/rendering comes from report engine code and third-party report components.

Source: Classes\Tools\vxTypes.pas, Classes\vxReport.pas, Classes\vxActionMan.pas.

SQL Script

Purpose: A SQL Script stores reusable SQL text associated with a DB Connection.

Relationships: SQL Scripts are modules and can reference DB Connections. Flow SQL actions can execute SQL command text; whether they directly reference SQL Script modules in all cases should be checked in the flow setup/action code.

Lifecycle: SQL Scripts are created in Designer, saved in VX_SQLSCRIPT, loaded by module code, and used wherever SQL script references are supported.

Configuration: SQL Script configuration includes script text, DB connection id/name/reference, and last editor position.

Where Used: SQL maintenance/configuration, scriptable database work, and possibly flow SQL actions depending on setup path.

Related UI: Forms\frmSetupSQLScript.pas.

Related Runtime Behaviour: Runtime can execute SQL through configured DB connections. Default SQL Script creation references _Site Settings and _Override scriptlet in source.

Source: Classes\vxSQLScript.pas, Classes\vxActionMan.pas.

Scriptlet

Purpose: A Scriptlet stores reusable script text that can be included in scripted formulas or runtime script contexts.

Relationships: Scriptlets are modules. Global gScriptlets caches scriptlets for runtime/script evaluation.

Lifecycle: Scriptlets are created and edited in Designer, persisted as modules, loaded into the global cache, and referenced by script items or script include lists.

Configuration: Scriptlet configuration includes script text/script object and last editor position.

Where Used: Custom scripts, map script events, transport scripts, route formulas, and reusable code snippets.

Related UI: Forms\frmSetupScriptlet.pas.

Related Runtime Behaviour: Runtime loads scriptlets and builds include lists for script evaluation. Exact include precedence and conflict handling should be checked in scriptlet/script item code before changes.

Source: Classes\vxScriptlet.pas, Classes\vxScriptItem.pas.

Script Item

Purpose: A Script Item is a configured formula/script attached to a flow action, route item, map event, transport event, or other scriptable point.

Relationships: Script Items can access action, email, file connection, source, scripter, and script template context.

Lifecycle: Script Items are configured, checked/compiled, then executed during runtime.

Configuration: Formula text, compiled status, handled flag, and compiles flag.

Where Used: Custom Script action items, route items, map events, transport scripts, and other scriptable runtime points.

Related UI: Script editor areas in flow, map, and transport setup forms.

Related Runtime Behaviour: Runtime executes script formulas and can mark handled/compiled status. Exact script engine and language semantics should be treated as compatibility-sensitive.

Source: Classes\vxScriptItem.pas, Classes\vxScriptlet.pas, Classes\vxMap.pas, Classes\Transports\vxTransport.pas.

Code Library

Purpose: Code Library appears as a Designer concept for code/snippet support.

Relationships: It is related to script editing and reusable code, but it is not modeled as a TvxModuleType in the inspected enum.

Lifecycle: The inspected source identifies a form, but the full business lifecycle was not traced in this pass.

Configuration: Unclear from inspected source.

Where Used: Script/code editing support.

Related UI: Forms\frmCodeLibrary.pas.

Related Runtime Behaviour: Unclear from inspected source.

Source: Forms\frmCodeLibrary.pas.

Variable Concepts

Variable Group

Purpose: A Variable Group organizes reusable variables under a group code.

Relationships: Variable Groups are modules. They contain TvxVariable items and are cached globally in gVariableGroups.

Lifecycle: Variable Groups are created/edited in Designer, saved as modules, loaded at runtime by Designer/services/API service, and referenced during tag/script processing.

Configuration: Group code, variables, and inherited module fields.

Where Used: Flows, maps, reports, scripts, transports, SQL, and text/tag substitution.

Related UI: Forms\frmSetupVariableGroup.pas, variable tree nodes in Classes\GUI\vxTreeNodes.pas.

Related Runtime Behaviour: gVariableGroups.LoadVariableGroups loads groups at startup. Runtime tag processing resolves values by group code and variable code.

Source: Classes\vxVariableGroup.pas, Classes\vxVariables.pas, Classes\Tools\vxTags.pas, VeloxService\classMain.pas, VeloxAPIService\classMain.pas.

Variable

Purpose: A Variable stores a reusable named value, optionally encrypted, for configuration and runtime substitution.

Relationships: Variables belong to Variable Groups and are referenced by code from scripts/tags.

Lifecycle: Variables are created under groups, validated for code uniqueness, saved with the group, loaded globally, and resolved at runtime.

Configuration: Variable code, value, item name, operator string, parameter type, encryption flag, and typed accessors such as string, SQL, float, integer, date/time, and boolean.

Where Used: Tags, scripts, SQL, maps, reports, transports, and flow configuration text.

Related UI: Forms\frmSetupVariableGroup.pas.

Related Runtime Behaviour: Tag processing expects a VariableGroupCode.VariableCode pattern and raises errors when the group or variable is missing.

Source: Classes\vxVariables.pas, Classes\vxVariableGroup.pas, Classes\Tools\vxTags.pas.

Variable Tag

Purpose: Variable Tags substitute variable values into text/configuration at runtime.

Relationships: Tags resolve through gVariableGroups to a Variable Group and Variable.

Lifecycle: Tags are written in configurable text, parsed at runtime, resolved to variable values, and errors are raised if references cannot be found.

Configuration: Tag format is inferred from source as group code plus variable code separated by a dot.

Where Used: Script/configuration text where tag substitution is supported.

Related UI: Forms with text/script/config fields may allow tags. The inspected source does not provide a complete UI list.

Related Runtime Behaviour: vxTags looks up variable groups and variables and substitutes resolved values.

Source: Classes\Tools\vxTags.pas, Classes\vxVariableGroup.pas, Classes\vxVariables.pas.

API Concepts

API

Purpose: An API module groups and publishes REST-enabled flows and API metadata.

Relationships: TvxAPI is a module that owns API action links. Those links connect the API to Flow modules. It can generate/export OpenAPI schema content from linked flow definitions.

Lifecycle: APIs are created in Designer, configured with metadata and linked actions, saved in VX_API, and used to create/export OpenAPI schema.

Configuration: API configuration includes version, API description, group description, production/test URLs, groups, terms, contact/license/documentation fields, OpenAPI schema text, and linked API actions.

Where Used: API documentation/schema generation and grouping of REST flows.

Related UI: Forms\frmSetupAPI.pas.

Related Runtime Behaviour: API module source generates OpenAPI documents. Actual HTTP request execution is handled by VeloxAPIService/REST manager using REST-enabled Flow configuration.

Source: Classes\vxAPI.pas, Classes\Service\vxManagerREST.pas.

API Action Link

Purpose: An API Action Link connects an API module to a REST-enabled Flow.

Relationships: It links API id to action/flow id and stores active/date metadata.

Lifecycle: Links are created/updated/deleted when API module configuration is saved.

Configuration: API id, action id, action name, active flag, created date, and updated date.

Where Used: OpenAPI schema generation and API setup.

Related UI: Forms\frmSetupAPI.pas.

Related Runtime Behaviour: Links are used for schema grouping/export. The REST manager executes flows based on flow REST endpoint configuration, not on API action links alone.

Source: Classes\vxAPI.pas.

REST Endpoint

Purpose: A REST Endpoint is the URL/method configuration that allows a Flow to be triggered by VeloxAPIService.

Relationships: REST endpoint settings live on TvxActionMan Flow modules. TvxRESTManager maps endpoint paths to TvxRESTItem.

Lifecycle: Endpoint settings are configured on the Flow, saved, synchronized by VeloxAPIService, and used to dispatch incoming requests. A default endpoint path is generated from the flow id if blank.

Configuration: REST method, endpoint path, groups, summary, description, documentation, params, success/client-error/server-error result configuration, anonymous access flag, request definition, and response definition.

Where Used: VeloxAPIService runtime, OpenAPI schema generation, REST-enabled flow setup.

Related UI: Flow setup REST/API tabs and API setup forms.

Related Runtime Behaviour: TvxRESTManager.ExecuteAPIForEndpoint receives WebBroker requests and dispatches matching endpoints. Source comments state it is called from WebModuleBeforeDispatch and runs in the request thread. GET and POST methods have visible execution methods in TvxRESTItem; support for all enum HTTP methods should be verified before documenting as runtime-complete.

Source: Classes\vxActionMan.pas, Classes\Service\vxManagerREST.pas, VeloxAPIService\vxWebModule.pas, Classes\vxAPI.pas.

OpenAPI Schema

Purpose: OpenAPI Schema is generated API documentation/contract data for Velox APIs.

Relationships: TvxAPI builds an OpenAPI document from API metadata, linked REST flows, request/response definitions, groups, URLs, and result settings.

Lifecycle: Created or exported from the API module in Designer.

Configuration: Stored schema text/path/name plus API metadata and linked flow REST configuration. Source creates OpenAPI v3.0.4 data.

Where Used: API documentation/export and external consumer contract review.

Related UI: Forms\frmSetupAPI.pas.

Related Runtime Behaviour: OpenAPI generation is a documentation/schema output path. It does not itself execute API calls.

Source: Classes\vxAPI.pas, Classes\vxActionMan.pas.

Logging, Audit, and Issue Concepts

Log

Purpose: A Log records execution/system outcomes for flows, transports, and system activity.

Relationships: Logs can contain log items, file records, transport records, SQL traces, tags, and trace data. Flows and transports create logs. Log records use log type/status enums.

Lifecycle: Logs are created during execution, receive messages/events, are saved to log tables, and can be viewed/managed in Designer.

Configuration: Flow configuration controls which statuses are saved or sent and whether SQL, HTTP communications, file data, and transport communications are logged. Setup controls some notification/email defaults.

Where Used: Flow execution, transport execution, system events, troubleshooting, notifications, and audit.

Related UI: Forms\frmLogs.pas, Forms\frmLogDetails.pas, Forms\frmManageLogs.pas.

Related Runtime Behaviour: Runtime methods record info, warning, issue, duplicate, cancelled, deadlock, error, test, and highlighted messages, save logs, create log file/transport links, and send log notifications.

Source: Classes\vxModule.pas, Classes\Tools\vxTypes.pas, Classes\vxActionMan.pas, Classes\Transports\vxTransport.pas.

Log Type

Purpose: Log Type categorizes logs by business/runtime area.

Relationships: Log records use TvxLogType.

Lifecycle: Set when a log is created for execution/system/transport work.

Configuration: Enum values are Not Set, Flow, Inbound, Outbound, and System.

Where Used: Log saving, viewing, filtering, and runtime categorization.

Related UI: Log and transport log management forms.

Related Runtime Behaviour: Log type influences how logs are classified and possibly displayed/filtered. Exact UI filtering should be checked in log forms.

Source: Classes\Tools\vxTypes.pas, Classes\vxModule.pas.

Log Status

Purpose: Log Status records the result/severity of execution or log messages.

Relationships: Logs and log items use TvxLogStatusType.

Lifecycle: Status is assigned during runtime logging and persisted with log records.

Configuration: Enum values are Not Set, Successful, Warning, Issue, Duplicate, Cancelled, Error, Test, and Note.

Where Used: Flow log saving/sending settings, notifications, log UI, and execution result handling.

Related UI: Log forms and flow setup save/send log status settings.

Related Runtime Behaviour: Runtime chooses status-specific methods such as Info, Warning, Issue, Duplicate, Cancelled, Error, and LogTest.

Source: Classes\Tools\vxTypes.pas, Classes\vxModule.pas, Classes\vxActionMan.pas.

Log Item

Purpose: A Log Item is an individual message/detail within a Log.

Relationships: Log Items belong to TvxLog.

Lifecycle: Created during execution, added to the current log, and persisted to VX_LOG_ITEM.

Configuration: Message/status/detail fields are handled by logging classes.

Where Used: Log detail views and troubleshooting.

Related UI: Forms\frmLogDetails.pas.

Related Runtime Behaviour: Runtime message methods create items and save them with the parent log.

Source: Classes\vxModule.pas.

Log File

Purpose: A Log File records a file involved in execution.

Relationships: Log Files link logs to files and file events.

Lifecycle: Created when runtime file handling reads/writes/moves/downloads/errors files and persisted through log file tables.

Configuration: File event, file path/name, and associated log/module metadata.

Where Used: File processing, transports, flow logs, troubleshooting.

Related UI: Log detail/file-related forms.

Related Runtime Behaviour: Runtime file operations create file events such as downloaded, audited, errored, issue, temp move, transporting, and deleted.

Source: Classes\vxModule.pas, Classes\vxFileCon.pas, Classes\Tools\vxTypes.pas.

Transport Log

Purpose: A Transport Log records send/receive communication details for transport execution.

Relationships: Transport logs are linked to TvxLog and transport modules. TvxLogTransport represents the transport log concept in code.

Lifecycle: Created during inbound/outbound transport execution and saved through transport log tables/links.

Configuration: Transport logging is controlled by flow/action setup flags such as log transport communications and by runtime transport context.

Where Used: Inbound and outbound transport troubleshooting, retry analysis, and audit.

Related UI: Forms\frmManageTransportLogs.pas, Forms\frmLogDetails.pas.

Related Runtime Behaviour: Runtime creates transport log records while sending/downloading and links them to execution logs. Transport status values include Sending, Completed, Cancelled, Failed, and Test.

Source: Classes\vxModule.pas, Classes\Tools\vxTypes.pas, Classes\Transports\vxTransport.pas, Classes\Service\vxManagerTransportOut.pas.

System Log

Purpose: System Log records product/runtime system events rather than a single flow execution.

Relationships: TvxSystemLog extends logging behaviour and global system logging is created during executable startup.

Lifecycle: System logging is created during startup, used during runtime/service events, finalized/recreated during Designer mode changes, and released during shutdown.

Configuration: Setup diagnostic flags may affect detail. Exact field-level control should be checked before changing system logging.

Where Used: Startup, service lifecycle, errors, diagnostics, and runtime status.

Related UI: Log forms and system logs views.

Related Runtime Behaviour: Startup calls CreateSystemLog; service code writes synchronization and lifecycle messages.

Source: Classes\vxModule.pas, Velox.dpr, VeloxService.dpr, VeloxAPIService.dpr, VeloxService\classMain.pas, VeloxAPIService\classMain.pas.

Issue

Purpose: Issue concepts represent business data quality or processing issues.

Relationships: TvxIssues, TvxIssueList, and TvxIssue exist in source. Flow execution has an Issues property. Issue type enums reference Order, Invoice, and ASN concepts and associated header/issue/event table names.

Lifecycle: Issues appear to be loaded/used during flow processing, but the full issue lifecycle is not fully clear from this repository alone.

Configuration: Issue type enum maps to order/invoice/ASN table naming. The underlying VxData schema source of truth is in a sibling repository, not this repo.

Where Used: Flow execution and VxData-related processing.

Related UI: Specific issue UI was not confirmed in the inspected source.

Related Runtime Behaviour: Runtime can attach issues to actions. Exact issue creation/resolution rules are unclear from inspected source.

Source: Classes\vxIssues.pas, Classes\vxActionMan.pas, Classes\Tools\vxTypes.pas.

Error

Purpose: Error is a runtime outcome/status used to identify failed processing.

Relationships: Errors appear in log statuses, file events, action status, transport status, and runtime exception paths.

Lifecycle: Errors are created during failed flow/transport/system work, logged, optionally trigger retries/notifications, and can be viewed in Designer.

Configuration: Error handling is influenced by flow log settings, retry settings, ReloadModuleOnError, transport retry settings, and setup diagnostics.

Where Used: Flow runtime, transport runtime, logs, service status, file moves to error directories.

Related UI: Log forms, flow setup, file connection setup error directory, service status UI.

Related Runtime Behaviour: Runtime logs errors, may move files to error folders, update statuses, and may trigger retry/reprocess paths depending on configuration.

Source: Classes\vxModule.pas, Classes\vxFileCon.pas, Classes\vxActionMan.pas, Classes\Tools\vxTypes.pas.

Designer and Supporting Concepts

Designer Tree

Purpose: The Designer Tree is the user-facing navigation model for all major Velox configuration concepts.

Relationships: Tree group nodes correspond to module types and supporting views such as logs, transport logs, Velox Web, and Velox API.

Lifecycle: The tree is built by TvxTreeNodes code and refreshed as modules are created/updated/deleted.

Configuration: Tree grouping is code-defined rather than user-configured in the inspected source.

Where Used: Velox Designer main UI.

Related UI: Forms\frmMain.pas, Classes\GUI\vxTreeNodes.pas.

Related Runtime Behaviour: Designer tree selection opens module setup forms and invokes module management actions. It does not directly run background service work.

Source: Classes\GUI\vxTreeNodes.pas, Forms\frmMain.pas.

Import, Export, and Synchronisation

Purpose: Import/export/synchronisation concepts support moving and reconciling Velox configuration.

Relationships: Module templates, configuration templates, relations, and module synchronization forms participate in this concept.

Lifecycle: Users export modules/templates, import them into an environment, review create/update/ignore decisions, and synchronize related references.

Configuration: .cfg template files and module relation metadata drive import/export decisions.

Where Used: Environment promotion, backup/restore-like configuration movement, and dependency management.

Related UI: Forms\frmConfigTemplateImporter.pas, Forms\frmModuleSync.pas, module export/import actions in Forms\frmMain.pas.

Related Runtime Behaviour: Import/export is configuration-time behaviour. Runtime services consume the resulting persisted module configuration.

Source: Classes\vxConfigTemplate.pas, Classes\vxModule.pas, Forms\frmConfigTemplateImporter.pas, Forms\frmModuleSync.pas.

XSD Generation

Purpose: XSD Generation supports XML schema creation or management around file definitions.

Relationships: It relates to XML File Definitions and schema settings.

Lifecycle: The inspected source confirms a Designer form. Full business rules were not traced in this pass.

Configuration: XML File Definition schema, namespace, validation, and root node settings are relevant.

Where Used: XML file definition design and schema support.

Related UI: Forms\frmCreateXSD.pas, XML file definition setup forms.

Related Runtime Behaviour: Runtime XML validation/loading depends on XML File Definition configuration. XSD generation itself appears to be design-time.

Source: Forms\frmCreateXSD.pas, Classes\vxFileDef.pas, Classes\vxFileDefXML.pas.

Database Explorer

Purpose: Database Explorer supports browsing or selecting database structures during design.

Relationships: It relates to DB Connections and DB Definitions.

Lifecycle: The inspected source confirms Designer forms. Full lifecycle was not traced.

Configuration: Uses DB Connection settings and database metadata.

Where Used: DB Definition design and related database setup work.

Related UI: Forms\frmDatabaseExplorer.pas.

Related Runtime Behaviour: Appears to be design-time support rather than runtime flow execution.

Source: Forms\frmDatabaseExplorer.pas, Classes\vxDBCon.pas, Classes\vxDBDef.pas.

File Search

Purpose: File Search supports finding files from Designer.

Relationships: It relates to File Connections, File Definitions, and file/log workflows.

Lifecycle: The inspected source confirms a Designer form. Full lifecycle was not traced.

Configuration: Likely uses file paths/patterns, but exact fields were not confirmed in this pass.

Where Used: Designer file investigation workflows.

Related UI: Forms\frmFileSearch.pas.

Related Runtime Behaviour: Appears to be design/support tooling rather than runtime service execution.

Source: Forms\frmFileSearch.pas.

Velox Web Reference

Purpose: Velox Web appears in the Designer tree as a related product/UI area.

Relationships: The root AGENTS guidance says velox-web is a separate front end that works from the VxData database. This repository has a tree node concept but does not own the web portal implementation.

Lifecycle: Unclear from this repository.

Configuration: General Setup includes Velox web domain, port, and install path settings.

Where Used: Designer navigation/setup context and General Setup.

Related UI: Classes\GUI\vxTreeNodes.pas, Forms\frmSetupGeneral.pas.

Related Runtime Behaviour: Web runtime behaviour is not owned by this repository.

Source: Classes\GUI\vxTreeNodes.pas, Classes\vxSetup.pas, Forms\frmSetupGeneral.pas.

High-Level Domain Flows

Design-Time Configuration Lifecycle

Background Flow Execution Lifecycle

API Flow Execution Lifecycle

Concepts That Are Explicitly Unclear

• AS2 transport runtime: AS2 is listed in TvxTransportType, but no concrete AS2 transport class was found in the inspected transport classes.
• Full plugin architecture: TvxActionType includes Call Plugin, but a complete plugin/module runtime architecture was not confirmed during this domain pass.
• Legacy enum values: Several enums include values such as Old, OLD, or action types whose current dedicated classes were not found. Treat these as compatibility-sensitive until traced.
• Issue lifecycle: Issue classes and issue type enums exist, but the complete business lifecycle for issue creation, resolution, and UI handling was not determined from the inspected source.
• Velox Web runtime: The velox repository has setup/tree references to Velox Web, but the web product behaviour belongs to another repository.
• Complete Code Library behaviour: A Designer form exists, but the full domain lifecycle and runtime impact were not determined in this pass.