Skip to content

Connect to Oracle Essbase

Connect PlaidCloud to Oracle Essbase (21c or later, or Oracle Analytics Cloud) so a workflow can run a live MDX query against a cube or load a dimension outline as a PlaidCloud dimension. The connection reaches Essbase’s own REST API cloud-direct — there is no on-premises agent path for these steps. This guide covers the connection, running a query, the options that control row limits and labeling, and loading a dimension hierarchy.

You need, from your Essbase administrator:

  • The Essbase server origin, for example https://your-host:9001 — no trailing /essbase/... path.
  • A service account — username and password — with read access to the applications and cubes your workflows will query.
  1. Open Tools > Connections and click New Connection.

  2. Choose Oracle Essbase from the menu.

  3. Fill in the fields:

    Field Value
    Name A friendly name, e.g. Essbase Prod.
    Base URL The Essbase server origin, e.g. https://your-host:9001.
    Default Application Optional. Pre-selects this application in the step forms.
    Username The service-account username.
    Password The service-account password.
    Verify SSL On by default. Turn off only for a host with a self-signed or otherwise unverifiable certificate.
  4. Click Test Connection. A successful test reaches the Essbase server, lists the applications the service account can see, and reports how many it found — confirming both the base URL and the credentials before you build a query.

  5. Click Create.

  1. Add an Essbase: Query Cube step to a workflow (it’s under Oracle Essbase in the step menu).

  2. Under Configuration, set Connection, Application, Cube (Database), and a Target Table.

  3. Build the MDX:

    • Guided member selection — browse the cube’s dimensions and members and pick what goes on columns and rows; the step assembles the MDX for you.
    • Raw MDX — write or paste an MDX SELECT directly, for anything the guided picker doesn’t cover, such as calculated members or set operators.
  4. Run the step. The returned grid lands as the target table, with columns derived from the grid itself — there’s no schema to declare up front.

  • Member labels are deterministic. Column labels for members come from the alias table configured on the connection, applied consistently on every run — not Essbase’s own per-session default, which could show different label text depending on who was logged in when the query ran.
  • Row Limit defaults to 250,000, and it’s raisable. An unset Row Limit falls back to a 250,000-row cap, not to “unlimited” — a query that returns more rows than the effective limit is refused, naming the count and the cap, instead of running unbounded or silently truncating the grid. Narrow the query, or raise Row Limit explicitly, to bring a legitimate larger extract through.
  • Zero suppression is opt-in and lossy. Suppressing zero-valued cells is a filter you turn on deliberately, and it’s a destructive one: it discards cells that hold a genuine posted 0, which is a different thing from Essbase’s own #Missing marker for a cell with no data at all. In a planning cube, a posted zero is meaningful — someone entered it — so suppressing zeros can drop real data, not just absence of data. Leave it off unless you specifically want zeros excluded from the result.

The Essbase: Read Dimension step reads one Essbase dimension’s outline and loads it into a PlaidCloud dimension’s main hierarchy — cloud-direct, over the same connection. It’s a separate step from Essbase: Query Cube: it reads outline structure, not cube cells.

The step refuses, by name, anything it can’t represent rather than loading it wrong: shared members, label-only members, Dynamic Calc members, attribute dimensions, a consolidation operator other than +/- (Essbase’s *, /, and % have no PlaidCloud equivalent), and an outline with more than 5,000 total outline members. See the step reference for the full list and what each refusal means.