Dynamic Reference files in CE 24.4

Chad1234

Hello everyone,

We are currently in the process of converting from Command Center 3.1.0 to CE 24.4. We currently use a dynamic reference file for rates which are unique for each run of the application. I am trying to figure out how to achieve that in CE 24.4, we are trying to avoid a straight webservice due to it being cloud based. Does anyone have any suggestions on what might be a solution to attempt?

Vyv

I put your question straight up into a publicly available AI and it replied:

This is a great and very specific migration question. Based on what's known about how CE Cloud Native works architecturally versus Command Center 3.1.0, here's a practical breakdown of your options:

The Core Challenge

In Command Center 3.1.0 (server-based), dynamic reference files were straightforward — you could drop a run-specific flat file (rates table, lookup data, etc.) into a watched folder or pass it as an auxiliary data file, and the engine would consume it per job. In CE 24.4's Cloud Native/Orchestration model, the engine is stateless and containerized, so the traditional file-drop approach doesn't translate directly.

Options to Explore

1. Embed the Rates Data in the Driver/Input Data Stream

The most architecturally clean solution: instead of a separate reference file, embed the rate data directly into your per-run input data (XML, JSON, etc.) as additional records or nodes. The engine's data mapping can pull from sections of the input file the same way it pulled from a reference file. This keeps everything self-contained per job with no external dependency.

2. Use a Sort/Auxiliary Data File Passed via Orchestration API

In CE Cloud Native, the Orchestration service accepts job submissions via REST. You can pass multiple input file references as part of the job payload — including what would function as an auxiliary or sort data file. If your rates file changes per run, your upstream process generates it fresh each run and includes it as a named input in the orchestration job call. The design in Design Manager would reference it as a secondary data source.

3. Shared Persistent Volume / File Mount (On-Prem/Private Cloud Deployment)

Exstream Cloud Native is engineered for a Kubernetes environment that can live anywhere — public clouds like AWS, Azure, or Google Cloud, or even on-premise setups like OpenShift. If you're running CE on-prem or in a private cloud on Kubernetes, you can mount a persistent volume (e.g., a network share or NFS volume) into the Document Generation pods. Your external process writes the run-specific rates file to that volume path before triggering the job, and the engine reads it from a known path — closely mimicking the old behavior without a web service call.

4. Inline the Rates in the Orchestration Flow Context

CE 24.4's Communications Orchestrator supports flow contexts, which are parameter sets passed to an engine run. If your rates are structured enough (key/value pairs or small tables), you can encode them as flow context variables and reference them in the design as user variables. This works best for smaller, structured rate tables rather than large flat files.

5. DocX Runtime Import (CE 25.1 and Later — Worth Noting)

CE 25.1 added support for DocX files as dynamic (runtime) imports. If your roadmap allows a version bump, this opens an additional pathway for runtime content injection. Worth flagging to OpenText support as a specific use case to see if a similar capability for data files is planned.

Recommendation

Given your preference to avoid a direct web service and depending on your deployment model:

• On-prem/private Kubernetes: the persistent volume mount approach is the most direct analog to your existing behavior and requires the least redesign.
• Fully cloud-hosted: embedding rates in the driver data stream or passing them as a secondary input file via the Orchestration API are the most reliable paths.

The OpenText developer forums at developer.opentext.com/ce/products/exstream are also worth posting this specific use case to — there's an active community of engineers who've navigated similar 3.1.x-to-CE migrations and may have implementation-specific details for CE 24.4's Orchestration API payload structure for multi-file inputs.