EPM データ統合（Data Integration・EPM Automate・Fusion GL 連携）

この章の結論

• Data Integration は、ERP・ファイル・オンプレミス DB・EPM アプリの間でデータを出し入れする EPM 共通の機能です。以前の Data Management の後継で、実行コマンドも runDataRule から runIntegration に置き換わっています。
• 1 本の統合は「ソースとターゲットのアプリケーション」「列とディメンションの対応（Map Dimensions）」「メンバーのマッピング（Map Members）」「期間・カテゴリ」でできています。実行時に importMode・exportMode・期間を指定します。
• Fusion GL とは直接連携できます。GL の実績残高を取り込み（Load Actuals）、EPM の予算と実績の調整仕訳を GL へ書き戻します。書戻しは、Balance Type、仕訳ソース・カテゴリ、期間（1 会計年度内）などの条件を守らないと失敗や重複の原因になります。
• 運用は、スケジューラから EPM Automate（runIntegration・runPipeline）か REST API で実行し、結果を Process Details とログで確認します。複数ジョブの順序制御はパイプラインです。

この章の確認範囲（2026 年 10 月）

Administering Data Integration の「Defining a Data Integration」「Writing Back Actuals to the Oracle General Ledger」「Using the EPM Integration Agent」（導入部）と、EPM Automate の runIntegration の説明を読んで書いています。Agent の導入手順、GL 取込のソース側オプション、ドリルスルーの設定手順は読めていないため、本文で「公式で確認」と明記しています。

全体像

Data Integration は、EPM の各ビジネス・プロセスに組み込まれたデータ連携機能です。以前の画面である Data Management の後継にあたり、公式は runDataRule の代わりに runIntegration の使用を推奨しています。パイプラインは Data Integration の機能です。入口（ホーム画面の「データ交換（Data Exchange）」など）の配置は、ビジネス・プロセスとリリースで異なります。

構成要素

概念	役割	Data Management での呼び名
アプリケーション（Application）	データの出し入れ先（EPM アプリ、ERP、ファイルなど）の登録	ソース・システム、ターゲット・アプリケーション
統合（Integration）	ソースからターゲットまでの 1 本の定義	データ・ロード・ルール
ロケーション（Location）	統合の設定をまとめる単位。同じロケーションの統合はマッピングを共有する（公式で確認）	ロケーション
Map Dimensions	ソースの列（ファイルなら列番号）とディメンションの対応	インポート形式
Map Members	ソースの値からメンバーへの変換ルール	データ・ロード・マッピング
Period Mapping、Category Mapping	期間と、シナリオの種別（Actual など）の対応	同名
ワークベンチ、Process Details	取込結果の確認、ジョブの履歴とログの確認	データ・ロード・ワークベンチ、Process Details

接続できるソースと用途

公式の「Defining a Data Integration」に挙がっている直接連携のソースです。

ソース・ターゲット	公式に挙げられている用途
Oracle ERP Cloud の General Ledger	実績の取込（Load Actuals）。予算と実績調整仕訳の書戻し
Oracle ERP Cloud の Budgetary Control	コミットメント・債務・支出の取込。予算の書戻し
Oracle ERP Cloud の Sub-Ledgers	サブレジャーの取引データの取込
Oracle NetSuite、HCM Cloud	NetSuite は実績とメタデータ、HCM は従業員属性・給与・職務情報の取込
Oracle E-Business Suite、PeopleSoft	GL の実績の取込
カスタムのオンプレミス・データソース	データベース・アダプタと EPM Integration Agent
Oracle Autonomous Database	ステージングなどからの取込、EPM から DWH へのエクスポート
EPM アプリ（同じ環境、別のサービス・インスタンス）	入力キューブとレポーティング・キューブ、別のビジネス・プロセス間の同期
ファイル	区切り文字ファイルなど任意のテキストファイル（ファイル型の統合）

ビジネス・プロセス同士の連携では、両者のリリースレベルが同じである必要があります（公式）。EPM は環境ごとに月次更新の日が違い（テスト：第 1 金曜、本番：第 3 金曜）、環境をまたぐ連携は更新後の約 2 週間でリリースレベルが食い違います。連携はテスト同士、本番同士で組みます。

設定の手順（統合を作る流れ）

ファイル型の統合を例に、公式の手順で確認できた画面名で示します。

1. Data Integration のホーム画面で「Actions > Setup actions > Applications」を開き、ソースとターゲットのアプリケーションを登録する
2. 「Actions > Period Mapping」「Category Mapping」で、期間とカテゴリの対応を定義する
3. ホーム画面の追加アイコンから Create Integration を開き、Name and Description、Location、Source、Target、Cube（ターゲットのプラン・タイプ）、Category を指定する
4. Map Dimensions で、ファイルの列番号とディメンションを対応づける（複数の列を同じディメンションに対応づけられる。ソース式・ターゲット式も使える）
5. Map Members で、ソースの値をメンバーに変換するルールを登録する
6. 統合の Options で、File Name、Directory、File Name Suffix Type、Period Key Date Format などを設定する
7. 実行し、ワークベンチと Process Details で結果を確認する

GLBALANCES.csv（架空の例）

Entity,Account,Dept,Amount
JP01,5110,D100,1200000
JP01,6200,D200,350000
JP02,5110,D100,980000

Map Members のタイプ	ソース → ターゲットの例（架空）	意味
All	* → *	そのまま対応づける（公式の書戻し手順で使用）
Explicit	5110 → Sales_Domestic	1 つの値を 1 つのメンバーへ
Between、In	6000,6999 → Other_Expenses	範囲、または列挙した値をまとめて
Like	7* → Non_Operating	ワイルドカード

複数のタイプが同じ値に当てはまるときの優先順位は、公式の Map Members の節で確認してください。

Fusion GL との連携

実績の取込（GL → EPM）

Oracle ERP Cloud の General Ledger は、実績の取込ができる直接連携のソースです。

1. EPM 側で Oracle ERP Cloud への接続を設定し、General Ledger のアプリケーションを登録する（勘定体系の定義ごとに登録する）
2. ソースを GL、ターゲットを EPM のアプリケーションとして統合を作り、カテゴリを Actual にする
3. Map Dimensions で COA のセグメントをディメンションに、Map Members でセグメント値をメンバーに対応づける
4. Period Mapping で GL の会計期間を EPM の Year・Period に対応づける
5. 実行し、ワークベンチで未マッピングやエラーを確認して、GL の試算表と合計を照合する

GL 残高キューブ（Essbase）は勘定体系とカレンダーの組合せごとに作られます（COA・元帳・GL セキュリティ・残高キューブ）。接続設定、ソース側のオプション（元帳・通貨など）、必要な ERP のアプリケーション・ロールは、公式の「Integration Process Description」「Integrating Oracle ERP Cloud Oracle General Ledger Applications」「Required Oracle ERP Cloud Application Roles」で確認してください。

仕訳の書戻し（EPM → GL）

EPM のアプリケーションをソース、Oracle ERP Cloud のアプリケーションをターゲットにして実行します。データはフラット・ファイルに書き出されてファイル・リポジトリにコピーされ、GL に仕訳が作成されます。公式の手順で確認できた条件は次のとおりです。

項目	条件
ERP 側の準備	ESS ジョブ「Create General Ledger Balances Cube」で残高キューブを、「Create Scenario Dimension Members」でシナリオを作る
Balance Type	EPM アプリケーションの Application Detail > Options タブで Actual にする
仕訳ソース・カテゴリ	同じ Options タブの Journal Source、Journal Category を、ERP に定義済みの値と一致させる
Ledger	ターゲットのディメンション Ledger にソースを必ず対応づける（例：Entity を Ledger に対応づけ、Map Members で GL の元帳名に変換）。単一元帳なら式に元帳名を入れる
参照・属性の列	ATTR1〜10 は REFERENCE1〜10 用（例：REFERENCE3 は ATTR3）、ATTR11〜30 は ATTRIBUTE1〜20 用（ATTRIBUTE1 は ATTR11）に予約。REFERENCE ディメンション（Attribute タイプ）を追加して ATTR 列に対応づける
期間	開始・終了期間は 1 会計年度内（またぐと重複データになる）。Period Key は月末日、Target Period Month は元帳の会計カレンダーと一致させる
ファイル	複数期間は期間ごとにファイルを作り、File Name Suffix Type（Period Name か Period Key）で名前に期間を付ける

画面の流れは前節と同じです。Map Members は All（* → *）で「そのまま」にでき、期間は Period Mapping の Application Mapping タブで Target Application に Oracle General Ledger を選んで追加します（Period Key・Target Period Month・Target Period Year）。

ERP 側の仕訳インポートのジョブ名、バッチ名、転記の扱いは、読めた公式ページに記載がありません。専用の仕訳ソース・カテゴリを用意し、ERP 側の承認・転記の流れに乗るかを設計時に確認してください（仕訳）。

予算の書戻し・Budgetary Control・ドリルスルー

• GL へは予算の書戻し、Budgetary Control とはコミットメント等の取込と予算の書戻しができると、公式に書かれています。手順は「Writing Back Budgets to the Oracle General Ledger」で確認してください。
• ドリルスルー（Drill-through）は、取込済みの値から取込元の明細へ移動する機能です。EPM の集計値の根拠を確認する用途で、書戻し（EPM → ERP）とは向きが逆です。公式によると、ドリルスルーは Planning、FreeForm、FCC、Tax Reporting、Account Reconciliation、PCM・EPCM などで使え、人事データには対応しません。ドリル可能なセルは**ドリル領域（drill region）**で決まり、データのロード時に Create Drill Region を Yes にして自動作成するか、手動でカスタム定義します。ドリル先は、標準／ダイレクト・ドリル、Oracle ERP Cloud（General Ledger の勘定残高サマリー画面や BI Publisher レポート）、EPM Integration Agent 経由のソースです。設定手順の詳細は、公式の Drill Through の章で確認してください。

EPM Integration Agent

EPM Integration Agent は、オンプレミスやサードパーティ・クラウドなどからデータとメタデータを抽出・変換して EPM に届ける仕組みです。公式の説明で確認できた用途は、オンプレミスのデータソースからのカスタム SQL クエリによる取込、Oracle E-Business Suite と PeopleSoft の GL の定義済みクエリによる取込、Quick Mode でのロード（「Performing a Quick Mode Load using the EPM Integration Agent」）です。

状況	選ぶ方法	理由
ソースがファイルを出力できる	ファイル型の統合と EPM Automate	ファイルを置くだけで足り、構成が単純
ソースがオンプレミスの DB で、SQL で抽出したい	EPM Integration Agent	社内の DB に直接問い合わせられる
EBS・PeopleSoft の GL	Agent（定義済みクエリ）	公式が定義済みクエリを用意している

導入手順、起動方法、Java などの要件、ネットワーク要件（ポート・プロキシ）、実行モードの違い、スクリプトの扱いは、導入部しか読めていません。公式の「Using the EPM Integration Agent」の各ページで確認してください。

EPM Automate によるジョブ自動化

EPM Automate は EPM のコマンドライン・ツールです。統合の実行は runIntegration です。対象は Planning、Planning Modules、FreeForm、FCC、Tax Reporting、Account Reconciliation、PCM、EPCM、Sales Planning、Strategic Workforce Planning で、Service Administrator か Power User のロールが必要です。主なコマンド（login、uploadFile、exportSnapshot など）は Planning の全体像 の実装リファレンスにあります。

runIntegration の書式（公式の説明より。実際は 1 行）

epmautomate runIntegration JOB_NAME
  importMode=Append|Replace|"Map and Validate"|"No Import"|Direct
  exportMode=Merge|Replace|Accumulate|Subtract|"No Export"|Check
  periodName={PERIOD_NAME} [inputFileName=FILE_NAME] [PARAMETERS]

パラメータ	必須	意味
JOB_NAME	必須	Data Integration で定義した統合の名前
importMode	標準モードで必須	Append は既存の POV のデータに追加、Replace は POV のデータを削除して置換、Map and Validate は取込を省いて更新後のマッピングで再処理、No Import はステージング表への取込を省く。書式には Direct も載るが、runIntegration のページに説明はない（REST API のクイック・モードの例では Direct が使われている）
exportMode	必須	Merge、Replace、Accumulate、Subtract（PCM・EPCM のみ）、No Export、Check。クイック・モードでは Check と No Export は使えず、Planning・FCC などでは Replace・Merge・Accumulate が有効
periodName	標準モードで必須	期間名を { } で囲む
inputFileName	任意	ファイル型の取込で inbox のファイルを指す。inbox/DIR_NAME/FILE_NAME または #epminbox/FILE_NAME
PARAMETERS	任意	実行時のパラメータ（NAME="値"）

• periodName の書式は、{Jan-21}、{Jan-21}{Mar-21}、{Jan#FY21}{Mar#FY21}（Planning 形式）、{Jan#&CurYr}{&FcstMonth#&CurYr}（代入変数）、{GLOBAL_POV} です。ほかの書式は HTTP 400 のエラーになります。Planning 形式と代入変数の期間は、期間マッピング（Application または Global）に Year と Month のターゲット値が必要です。
• パラメータ名と値は大文字小文字を区別します。クイック・モードの統合に必要なのは exportMode だけです。ディメンション（メタデータ）をターゲットにする統合で使えるパラメータは "Refresh Database"=Yes|No だけです。
• 標準モードの Replace は Scenario・Version・Year・Period・Entity のデータを削除し、クイック・モードの Replace は Year・Period・Entity を削除します。
• Oracle Fusion Cloud をターゲットにするときの exportMode は MERGE と NONE だけです。

月次の実績取込（例）

#!/usr/bin/env bash
set -euo pipefail

# 認証情報は環境変数や秘密管理から渡す（スクリプトに直書きしない）
epmautomate login "$EPM_USER" "$EPM_PASSWORD_FILE" "$EPM_URL"
trap 'epmautomate logout' EXIT

PERIOD="Apr-26"   # 例：4 月始まりの会社の 1 か月目

# ファイルを inbox へ置く（uploadFile の引数は公式で確認）
epmautomate uploadFile ./GLBALANCES.csv inbox/GL

# 統合を実行する（公式の例と同じ Replace・Merge の組合せ）
epmautomate runIntegration GL_ACTUAL_LOAD \
  importMode=Replace exportMode=Merge \
  periodName="{${PERIOD}}" inputFileName=inbox/GL/GLBALANCES.csv

set -e により、epmautomate が 0 以外の終了コードを返すとスクリプトが止まります。成否は終了コードで判定し、失敗時は Process Details でログを確認します（コマンドごとの終了コードは公式で確認）。認証方式（パスワード、パスワード・ファイル、OAuth 2.0）はリリースで変わるため、公式で確認してください。

REST API

EPM Automate と同じ種類の操作は REST API でも呼べます。パイプラインを実行する「Run a Pipeline」の REST API が公式にあります。EPM Automate はシェルやジョブ管理製品から手軽に呼ぶ用途、REST API は OIC・Python・社内アプリから呼ぶ用途やジョブの状態を細かく取得する用途に向きます。統合の実行（INTEGRATION ジョブ）は、/aif/rest/V1/jobs に POST します（Service Administrator か Power User）。

統合の実行リクエスト（公式の例をもとにした形）

{
  "jobType": "INTEGRATION",
  "jobName": "GLDATA",
  "periodName": "{Mar-20}",
  "importMode": "Replace",
  "exportMode": "Merge",
  "fileName": "inbox/GLBALANCE.txt"
}

項目	必須	意味
jobType・jobName	必須	INTEGRATION と、Data Integration の統合名
periodName・importMode・exportMode	必須	EPM Automate の runIntegration と同じ書式。exportMode の値はターゲットで変わる（FCC・Tax Reporting は Merge・Replace・No Export）
fileName	任意	ファイル型の取込のみ。inbox/ファイル名 か #epminbox/ファイル名
sourceFilters・targetOptions	任意	実行時にソースのフィルタ・ターゲットのオプションを上書きする（sourceFilters はファイル型では使えない）
executionMode	クイック・モードで必須	SYNC は完了まで待ち、ASYNC は即座に返る

ジョブ状態の取得方法とレスポンスの項目は、取得した公式ページに記載がありません。一般のジョブ API では、ジョブ ID を指定した GET で状態を取るのが通例ですが、リリースごとの公式ドキュメントで確認してください。認証方式と次の雛形のパス・項目名も、環境に合わせて置き換えます。次は「実行 → 完了待ち」の雛形です。

REST で実行して完了を待つ雛形（URL・項目名は公式で確認して置き換える）

import os
import time

import requests

BASE = os.environ["EPM_BASE_URL"]  # EPM 環境の URL
session = requests.Session()
session.headers["Authorization"] = os.environ["EPM_AUTH_HEADER"]  # 認証方式は環境に合わせる


def run_and_wait(run_path, payload, status_url_of, is_done, timeout_s=1800, interval_s=15):
    res = session.post(BASE + run_path, json=payload, timeout=60)
    res.raise_for_status()
    job = res.json()
    deadline = time.time() + timeout_s
    while time.time() < deadline:
        st = session.get(status_url_of(job), timeout=60)
        st.raise_for_status()
        if is_done(st.json()):
            return st.json()
        time.sleep(interval_s)
    raise TimeoutError("ジョブが制限時間内に終わりませんでした")

実務での拡張点は、一時的なエラーのリトライ、完了後の成否判定、失敗時のログ取得と通知です。

パイプライン

パイプライン（Pipelines）は、複数のジョブを順序立てて 1 つの処理として実行する Data Integration の機能です。取込の後にビジネス・ルールで計算する、といった月次処理の手順をまとめられます（組み込めるジョブの種類は、公式の runPipeline のページに記載がないため、Data Integration のガイドで確認）。画面のほか、EPM Automate の runPipeline と Run Pipeline REST API で実行できます。公式の What’s New には、runPipeline コマンドの新設（2025 年 2 月の更新）と、runPipeline と Run Pipeline REST API の項目（同年 8 月の更新）があります。

順序依存のある処理をスケジューラのスクリプトではなくパイプラインに持たせると、ジョブ管理製品側の定義が 1 回の呼び出しで済みます。期間などは、実行時に渡す変数で切り替える設計にします。

パイプラインの実行（例。MONTHLY_LOAD_AND_CALC は架空のコード）

epmautomate runPipeline MONTHLY_LOAD_AND_CALC "STARTPERIOD=Apr-26" "ENDPERIOD=Apr-26" "IMPORTMODE=Replace" "EXPORTMODE=Merge"

書式は epmautomate runPipeline PIPELINE_CODE [PARAMETER=VALUE] です。PIPELINE_CODE はパイプライン作成時に付けたコードで、パラメータはパイプラインに定義した変数に依存します。既定のパラメータは次のとおりです。

パラメータ	意味
STARTPERIOD・ENDPERIOD	取り込む最初・最後の期間（期間マッピングに定義が必要）
IMPORTMODE・EXPORTMODE	runIntegration と同様の取込・書出しの方式（EXPORTMODE は Merge・Accumulate・Replace・No Export）
ATTACH_LOGS	ログを zip にして通知に添付するか（Y・N）
SEND_MAIL・SEND_TO	完了時のメール送信（Always、No（既定）、On Failure、On Success）と宛先

実行できるのは Service Administrator か、パイプラインのプロキシ・ユーザー（ロケーション・セキュリティ、またはシステム設定の Enable Pipeline Execution for Non-Admin Users を Yes にする方法で付与）です。

運用設計

観点	設計のポイント
実行基盤	JP1 などのジョブ管理製品や cron から EPM Automate を呼ぶ。OIC のスケジュール統合から REST を呼ぶ方法もある
認証	専用の統合ユーザー（Service Administrator か Power User）で実行する。パスワードの期限切れで止まらないよう、期限管理か OAuth 2.0 を検討する
再実行	取込は Replace を基本にする。Append は再実行で二重計上になる
監視	終了コード、Process Details、ログで確認する。マッピングのエラーは、直したあとに Map and Validate で再処理する
稼働時間	日次メンテナンスと月次更新の時間帯を避ける
環境間	統合定義はマイグレーションで移し、接続情報は環境ごとに設定し直す前提にする（公式で確認）
照合	取込後に GL の試算表と EPM の合計を突き合わせる。ERP 側の残高 SQL は BI Publisher の SQL 実践

落とし穴とベストプラクティス

よくあるミス

• Append のまま再実行して、データが二重になる
• 書戻しで Journal Source・Journal Category が ERP の定義と一致しない、または期間が会計年度をまたぐ
• Ledger ディメンションの対応づけを忘れる
• periodName の書式を間違えて HTTP 400 になる。パラメータ名の大文字小文字も区別される
• テスト環境と本番環境をまたいで連携し、更新後にリリースレベルが食い違う

• 統合の名前に規則を決め（例：GL_ACTUAL_LOAD）、マッピングの変更を管理します。
• 取込は ERP の確定後（月次クローズ後）に実行し、差異は ERP 側で直して再取込します。
• 4 月始まりの会社は、期間マッピングと FY の表記を最初に固定します（EPM Cloud の全体像）。

試験対策ポイント

項目	内容
試験	Oracle Cloud EPM Data Integration 2026 Implementation Professional（1Z0-1133-26）
形式	問題数・時間・合格ラインは公式ページを読めず未確認（暫定で 50 問・90 分・合格 68%）。Oracle 日本語サイトの試験一覧に掲載なし
模擬テスト	EPM連携 模擬テスト

出題分野の大項目は公式の Exam Topics を確認できていません。非公式の学習ガイドにあった分野名（Understanding Data Integration、Registering Applications、Creating Data Integrations、Running Data Integrations、Drill-through、Pipelines、Performance and Troubleshooting、EPM Integration Agent、Data Maps and Smart Push など）を参考に、模擬テストの分野を暫定で区切っています。

• 覚えること：統合の構成要素、直接連携できるソース、runIntegration の importMode・exportMode・periodName の書式、書戻しの条件（Balance Type、仕訳ソース・カテゴリ、Ledger、1 会計年度内）、runDataRule から runIntegration への置換。
• 判断問題：「ファイル型か Agent か」「Append か Replace か」「単発の統合かパイプラインか」「EPM Automate か REST か」を、状況から選ぶ形がよく出ます。

公式ドキュメント

• Defining a Data Integration
• Writing Back Actuals to the Oracle General Ledger
• Writing Back Budgets to the Oracle General Ledger
• Using the EPM Integration Agent
• Working with EPM Automate：runIntegration
• Working with EPM Automate：runPipeline
• Run a Pipeline（REST API）
• Required Oracle ERP Cloud Application Roles
• Integration Process Description（EPM Data Integration）
• Integrating Oracle ERP Cloud Oracle General Ledger Applications（Administering Data Management）
• Loading Data Using Data Integration（チュートリアル）
• 1Z0-1133-26 試験ページ（Oracle University。作成時は取得できませんでした）

関連ページ

• EPM Cloud の全体像と Fusion ERP との関係
• R2R：記帳から決算・連結・EPM まで
• GL の全体像と試験範囲
• 連携方式の全体像と選び方
• Oracle Integration（OIC Gen3）の概要とコンポーネント
• EDM：マスタデータ（ディメンション）の統制と配信
• Planning の全体像と試験範囲
• 連結決算（FCC）の全体像と試験範囲