Cloud ETL
Informatica PowerCenter — planned
The repository database holds mappings, sessions and run statistics — including per-target row counts. This integration is planned: documented here as reference, not connectable from the admin today.
PowerCenter carries critical load in many enterprises, and it is well served by its
own repository. The repository database exposes a set of
REP_* views describing mappings, sessions, workflows and — most usefully — per
target-instance row statistics for every session run.
REP_SESS_TBL_LOG is the standout. It records applied, affected and rejected
rows per target per session, which is a complete reconciliation recorded automatically. Very
few platforms offer this, and most teams running PowerCenter have never queried it.
Informatica PowerCenter today
Decim does not call cloud ETL service APIs today. Job scripts kept in a connected GitHub repository are read as code; a definition that exists only in a service console is not seen yet. Run logs can be read from Google Cloud Logging where they are shipped there, or exported and attached to the incident as files.
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned Informatica PowerCenter integration: what it is designed to read, and why.
What Decim will read from Informatica PowerCenter
The intended read-only surface for this integration. It is reference material for the roadmap — and useful on its own, because these are the views and APIs worth knowing during an incident whether or not any tool reads them for you.
| What | From | Why it matters |
|---|---|---|
| Session runs | REP_SESS_LOG | Status, start, end and error per session run |
| Per-target row counts | REP_SESS_TBL_LOG | Applied, affected and rejected rows per target instance |
| Workflow structure | REP_WORKFLOWS, REP_TASK_INST | Task order and dependencies |
| Mappings | REP_ALL_MAPPINGS | Mapping inventory and their folders |
| Source/target fields | REP_SRC_FLD, REP_TARG_FLD | Column-level structure |
| Connections | REP_SESSION_CNXS | Which physical systems a session touched |
| Schedules | REP_WFLOW_RUN | Workflow run history and cadence |
Permissions it is designed around
Written out in full, because "read-only access" is not a specification. These are the grants the planned integration is designed around and may change before it ships. Nothing below grants the ability to write, and row access would be requested only on the specific tables you name. You do not need to create any of this today.
-- The repository is an ordinary Oracle or SQL Server database.
-- Grant SELECT on the REP_ views only — never on the underlying OPB_
-- tables, which are internal and not a supported interface.
GRANT SELECT ON REP_SESS_LOG TO decim_agent;
GRANT SELECT ON REP_SESS_TBL_LOG TO decim_agent;
GRANT SELECT ON REP_WORKFLOWS TO decim_agent;
GRANT SELECT ON REP_TASK_INST TO decim_agent;
GRANT SELECT ON REP_ALL_MAPPINGS TO decim_agent;
GRANT SELECT ON REP_SESSION_CNXS TO decim_agent;
-- The reconciliation this platform gives you for free:
SELECT SESSION_NAME, TABLE_NAME,
SUCCESSFUL_ROWS, FAILED_ROWS, THRUPUT
FROM REP_SESS_TBL_LOG
WHERE SESSION_TIMESTAMP >= SYSDATE - 1
ORDER BY FAILED_ROWS DESC;What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- Workflow and session topology with task dependencies
- Per-target row counts — applied, affected and rejected — for every run
- Which physical connections each session used
- Mapping inventory, including mappings no workflow references
Today, topology is built from code in GitHub, and each connection is marked direct or inferred. The design direction for sources like this one is a provenance model: a step found in a definition is declared, a step seen running is observed, one that is both is verified, and where two sources disagree the disagreement is kept as a drift note rather than resolved silently. That model is planned, not shipped.
Failure modes it would surface
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it. Until the integration ships, the same signals can be checked by hand, or requested by Decim as a check your team runs.
| Failure mode | The signal |
|---|---|
| Rows rejected silently | FAILED_ROWS non-zero on a succeeded session |
| Session succeeded with zero rows | SUCCESSFUL_ROWS at zero |
| Workflow stopped being scheduled | No run rows after a date, with no failure |
| Connection repointed | Connection value differing from the previous good run |
Limits
What this source cannot tell you, even once it is read. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest cause unclear.
- Reject files themselves live on the integration service host, not in the repository
- The
REP_views are documented but vary between PowerCenter versions - Informatica Cloud (IICS) has a completely different metadata surface and is not covered by this page
Related integrations
- Oracle Database — Will read ALL_SOURCE for PL/SQL bodies, DBA_TAB_MODIFICATIONS for writes and DBA_SCHEDULER_JOBS for schedules.
- SSIS — SSISDB holds executions, per-component row counts and the parameter values actually used.
- SQL Server Agent — Job steps are rows in msdb, not files in git. Will read sysjobs, sysjobsteps and sysjobhistory.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a Informatica PowerCenter pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.