My Dream Project - Building EPM Connector: A Single Console for Oracle EPM Cloud

 Building EPM Connector: A Single Console for Oracle EPM Cloud

How I built a lightweight, AI-assisted control center for Oracle EPM Cloud — using Oracle's own documented REST APIs.

The Thought Behind This

If you've worked with Oracle EPM Cloud (Planning, EPBCS, PBCS, or FCCS), you know the drill: metadata lives in one place, data exports live in another, job statuses require a separate check, and activity history is scattered across logs and console screens. Every task — checking a data load rule, running an Essbase export, reviewing whether last night's job actually finished — means jumping between different tools and screens.

Honestly, it's the kind of friction you stop noticing after a while. You just accept that "checking on things" means five tabs open at once. It wasn't until I found myself doing the same five-tab dance for the third client environment in a row that I actually stopped and asked: why am I still doing this manually?

As an Oracle EPM consultant working across multiple client environments, I wanted one thing: a single console where I could authenticate once and handle the day-to-day operational work — without writing a new script every time I needed a quick answer.

That's what led me to build EPM Connector.

What EPM Connector Does

EPM Connector is a web-based console, built entirely on Oracle's documented REST APIs, that brings together the tasks I found myself repeating most:

• Connection Management — authenticate against an Oracle EPM Cloud environment and confirm connectivity status at a glance.
• Plan Types & Dimensions — explore Planning application metadata without digging through the native UI.
• Essbase Data Export — trigger and monitor Essbase data exports directly from the dashboard.
• Block Analysis Report — generate block-level analysis reports for performance and storage review.
• Job Monitor — a live view of job status (Complete, Failed, In Progress, Unknown) that updates automatically as jobs finish, so there's no more manually refreshing a status page.
• Activity Reports — application-wide activity history, exportable in both JSON (for automation/integration) and HTML (for human-readable reporting), with a graceful fallback in demo mode when live tenant data isn't available.
• Application Metrics — a dashboard view of storage usage, artifact counts (forms, dashboards, business rules, data load rules, smart lists), and last snapshot/export timestamps, so I can see the health of an environment in one glance.

Job Monitor

Application Metrics

Everything is designed around a simple idea: if Oracle already exposes it through a REST API, EPM Connector should be able to surface it in a clean, readable interface — instead of requiring a new script or a trip into the native console.

It sounds obvious when you say it out loud. But it's surprising how often the "obvious" thing doesn't exist yet, simply because nobody's had the time to build it.

 Plan Types & Dimensions

Why I Built It This Way

A few design principles guided the build — some of them learned the hard way, from years of writing one-off scripts that solved a problem once and then quietly rotted in a folder somewhere:

1. REST-API first. Every feature maps to a documented Oracle EPM REST API call — nothing relies on scraping the UI or undocumented behavior. That makes the tool stable across environments and upgrade cycles. I've been burned before by tools that broke the moment Oracle shipped a UI update; I didn't want to build another one.

2. Operational visibility over raw data. Rather than just dumping JSON, the dashboard translates job states, storage metrics, and activity logs into something a consultant or admin can scan in seconds. Raw API responses are great for scripts, but terrible for a 7 AM status check before a client call.

3. Safe by design. Every action that changes state (like triggering an export) is explicit and reviewable — the console never silently runs jobs in the background. If you've ever had a script "helpfully" do something you didn't ask for, you understand why this mattered to me.

4. Built for real environments, but safe to demo. A graceful "Demo Mode" fallback means the tool can be shown and explored without exposing live tenant data — useful for walkthroughs, training, or showcasing the tool externally without anyone worrying about what's on screen.

 Connection

 What's Next

This started as a personal productivity tool, but it's evolving toward something bigger — I'm exploring how patterns like Agent Studio and Model Context Protocol (MCP) could let AI agents interact with EPM environments through the same governed, permissioned tool layer: a defined set of tools (get data, run a rule, refresh a cube, export data), scoped by persona and role-based access, so that automation stays safe and auditable even as it becomes more autonomous.

I'll be honest — this is the part I'm most excited about, and also the part I'm most cautious about. Giving an AI agent the ability to act inside an EPM environment (not just report on it) is powerful, but it only works if every action is scoped, permissioned, and logged the same way you'd expect from any enterprise tool. That's the whole point of layering personas and role-based access underneath the agent — the AI shouldn't have more freedom than the human it's assisting would have.

The long-term vision: a console that doesn't just show you what's happening in your EPM environment — it helps you act on it, safely, with the same rigor you'd expect from any enterprise-grade tool.

 

Final Thoughts

Building EPM Connector reinforced something I already believed as an Oracle ACE: the best tools in this space aren't the ones that hide complexity — they're the ones that make the existing, well-documented capabilities of the platform genuinely usable day to day. Oracle already gives us the REST APIs. The opportunity is in the console layer on top.

If you're an EPM consultant or admin who's ever wished for one screen instead of five, I'd love to hear what you'd want in a tool like this.