障害処理・テスト・監視・移送

フォルトは 呼出し → スコープのフォルト・ハンドラ → グローバル・フォルトハンドラ → エラー処理フレームワーク（Errors ページ） の順に流れます。ハンドラで処理しきれば スコープの後ろから処理が続き、Re-throw Fault で外側へ投げ直します
グローバル・フォルトハンドラの既定は Re-throw Fault です。Stop で終わらせると、失敗が Errors に出ず、インスタンスは Succeeded と表示されます。通知してから Stop にします
テストは、有効化した統合を Run（Configure and run ページ） で実行し、結果を アクティビティ・ストリーム で確かめます
再送信は 手動のみ（自動の再送はありません）。同期統合のエラーは再送信できません。破棄（Discard）した後は元に戻せません
環境移送は IAR（統合 1 本）か プロジェクトのデプロイメント で行い、接続の設定は移送後に必ず直します

全体像

統合は、作って終わりではありません。設計 → テスト → 有効化 → 監視 → 回復 → 移送のサイクルで運用します。

工程	何をするか	どこで行うか
設計	フォルト・ハンドラ、ビジネス識別子、ログの設計	統合のキャンバス
テスト	正常・異常・境界・再送信の確認	マッパーのテスト、Configure and run
有効化	トレース・レベルの選択、接続の確認	Activate
監視	インスタンスとエラーの確認	Observability（Instances、Errors）
回復	再送信・破棄・再実行	Errors ページ
移送	開発 → テスト → 本番への展開	エクスポート／インポート、デプロイメント

フォルト処理

フォルトが流れる順序

呼出し（invoke）が失敗
  → ① スコープのフォルト・ハンドラ（名前付きフォルト／Default Handler）
  → ② グローバル・フォルトハンドラ（統合全体）
  → ③ エラー処理フレームワーク（Errors ページ。公式ドキュメントでは error hospital とも）

どこかの段階で正常に処理できれば、そこで止まります。処理できなければ、次の段階へ渡ります。

スコープのフォルト・ハンドラ

Scope は、複数のアクションをまとめる容器です。どのスコープにも Default Handler があります（スコープを選び、Actions > Fault Handlers > Default Handler）
スコープの中に呼出しを置くと、その呼出しが持つ 名前付きフォルト がハンドラに追加されます（例：REST アダプタの呼出しなら APIInvocationError REST）。名前付きフォルトは qname で識別されます
想定外のフォルトを拾うには、スコープのフォルト・ハンドラに Re-throw Fault を置きます（名前付きのハンドラが無いフォルトに対して実行されます）
ハンドラが成功すれば、スコープの後ろから処理が続きます。スコープが成功した場合、ハンドラは実行されません。スコープもハンドラも失敗したときは、両方が失敗として表示されます
スコープは 入れ子にでき、段数の上限はありません。ハンドラの中にもスコープを置けます
複数の REST 呼出しを持つ統合 では、ハンドラを 1 つしか定義できません。すべての呼出しがその 1 つのハンドラを指します
接続エージェント経由の呼出し では、名前付きフォルトのハンドラは処理されません。Default Handler にすべて書きます

Throw New Fault と Re-throw Fault

アクション	役割	使いどころ
Throw New Fault	業務エラーを意図的に発生させる（コード・理由・詳細を設定）	入力チェックの不合格、仕入先が存在しない、など
Re-throw Fault	受けたフォルトを外側へ投げ直す。フォルト・ハンドラの中でだけ使える	通知やログのあとに、上位のハンドラ・Errors へ渡す

Re-throw されたフォルトは、グローバル・フォルトハンドラが定義されていればそこを経由して、定義されていなければ直接、エラー処理フレームワークへ渡ります。

グローバル・フォルトハンドラ

統合全体のフォルトを受ける最後の砦です。同期・非同期・スケジュールのどの統合にも使えます。

開き方：キャンバスの 警告アイコン（View Global Fault Handler）で、メインの統合とグローバル・フォルトを切り替えます。元に戻すときは View Main Integration です
前提：統合に 呼出し（invoke）が 1 つ以上 必要です
既定の構成：トリガーに、最初から Re-throw Fault がつながっています。何もしなければ、フォルトはエラー処理フレームワークへ渡ります
使えるアクション：Switch や Stop などのアクションを置けます。メール通知（Notification）もここに置く設計が一般的です。典型は「Switch でフォルトの種類を見て、通知したうえで Re-throw し、それ以外は Stop」です
Re-throw Fault：集めたフォルトの詳細をエラー処理フレームワークへ送ります。トリガー（呼出し元）には応答しません
Stop：フォルト処理を終えます。エラー処理フレームワークには何も渡りません。ハンドラがエラーを正常に処理できた場合、インスタンスは Succeeded と表示されます（公式ドキュメントの記述）
フォルトの内容を使う：式ビルダーの Functions > Integration Cloud に、フォルトを取り出す関数があります（getFaultAsString、getFaultAsXML、getFaultName、getFaultedActionName、getFlowId）。送信元のツリーには $GlobalFaultObject があり、fault の下に errorCode、reason、details が入ります
インスタンスを追跡する：Instances ページで見つけられるよう、ビジネス識別子を定義しておきます

フォルト処理の設計パターン

パターン	作り方	注意点
リトライして回復する	Scope ＋ While ＋ Wait ＋ Assign（回数）	待機時間も処理時間（6 時間まで）に含まれる
業務エラーを呼出し元に返す（同期）	ハンドラでエラー内容を応答に組み立てて返す（必要なら Throw New Fault で業務エラーを発生させてから）	同期のエラーは再送信できない
通知してエラー処理へ渡す	Notification → Re-throw Fault	通知が洪水にならないよう、集約を検討する
エラーを記録して続行する	ハンドラで記録 → スコープの後ろへ	部分失敗を許容する業務だけに使う
失敗を無視して正常終了する	Stop	監視に出なくなる。原則として使わない

呼出しのリトライには、プロジェクト内の呼出しに リトライのロジックを追加する機能 もあります（公式の「Add Retry Logic to Invoke Connections in Projects」）。自作のリトライとどちらを使うかは、リトライ対象のエラーの種類と回数・間隔を決めてから選びます。

Assign  retryCount = 0、done = 'false'
While   $done = 'false' and $retryCount < 3
  Scope
    Invoke   外部 API を呼ぶ
    Assign   done = 'true'
    Default Handler
      Assign  retryCount = $retryCount + 1
      Wait    30 秒（回数に応じて延ばす）
Switch  $done = 'false'
  → Notification（統合名・フロー ID・業務キー・エラー内容）
  → Throw New Fault（コード・理由・詳細）→ グローバル・フォルトハンドラで Re-throw

並列処理（Parallel や並列の For-Each）で複数のフォルトが出る場合の扱いは、公式の「Define Fault Aggregation in Parallel Processing Scenarios」で確認してください。

同期と非同期のエラー

観点	同期統合	非同期統合
エラーの返り先	呼出し元にエラーを返す	受付済みなので呼出し元には返らない
再送信	できない	できる（Errors ページから）
設計の勘所	呼出し元が分かるエラー応答を作る	通知と Errors での監視、冪等な処理

テスト

テストの層

層	何を確認するか	方法
マッピング	項目の対応、変換、空値・境界値	マッパーのテスト機能（マッパー・ルックアップ・JavaScript ライブラリ）
統合の単体	トリガーから応答まで、フォルト処理	有効化して Configure and run で実行
結合	外部システム・Fusion との通し	外部のクライアント（curl など）から呼ぶ。スケジュール統合は Run
非機能	件数・サイズ・処理時間	本番に近い量でリハーサル

REST トリガーの統合をテストする

公式ドキュメントでは、REST アダプタをトリガーにした統合とスケジュール統合は、サードパーティのツールなしでテストできる と説明されています。テストの場所は 2 つです。

キャンバスの中から（Test Integrations from Inside the Integration Canvas）
キャンバスの外から：統合の Actions メニューから（Test Integrations from Outside the Integration Canvas）

統合を保存し、有効化（Activate） します。有効化していない統合はテストできません
上のいずれかの場所から Run を選び、Configure and run ページを開きます
リクエストの内容（パラメータ、ヘッダー、本文の JSON など。項目は統合の定義に従います）を入力し、Run で実行します
応答（ステータスと本文）を確認します
Observability > Instances でインスタンスを開き、アクティビティ・ストリーム で各アクションの入出力を確認します

症状	確認すること
`An Integration is not reachable`	統合が有効か、swagger の内容が取得できるか。画面を更新（refresh）する
Configure and run が動かない	アクセス制御リスト（ACL）が有効な環境では、エンドポイントがセキュリティ要件を満たさないと使えないことがある。動的なエンドポイント URL にアクセスできる必要がある

スケジュール統合は、Schedule ページの Run から Ad hoc request で試します（スケジュール統合とファイル処理）。

テストケースの設計

区分	観点	確認すること
正常系	全項目あり／任意項目なし／明細が複数	応答、Fusion 側のデータ、ビジネス識別子
入力エラー	必須項目の欠落、型の不正	業務エラーの応答（設計したステータス）、エラー内容
外部障害	外部 API の停止・タイムアウト	リトライ、通知、Errors への表示
重複	同じ要求を 2 回送る	二重登録されないこと（冪等）
再送信	失敗させて Errors から再送信	最初から再実行され、結果が正しいこと
負荷	想定のピーク件数・サイズ	処理時間、同時実行の影響

AI アシスタントには、テストケースを生成する機能があります（2026 年 9 月時点。提供リージョンは OIC の概要を参照）。生成された内容は、必ず人が見直します。

監視

Instances とアクティビティ・ストリーム

Observability > Instances で、統合の実行（インスタンス）を確認します。

表の項目：Primary Identifier、Instance Id、Status、Business Identifiers、Duration
Status の例：Queued（まだ実行していないスケジュール統合。Duration 欄に実行予定時刻）、In progress（実行中の非同期）、Waiting／Paused（スケジュール統合）、Failed（失敗。Errors で扱う）
Abort（中止）：実行中の非同期インスタンスと、待機中・一時停止中のスケジュール統合のインスタンスに使えます。それ以外では使えません
ビジネス識別子で検索：設計時にビジネス識別子を 1 つ以上定義した項目だけが追跡・検索できます（オーケストレーション統合とアクション）

アクティビティ・ストリーム は、メッセージが統合の中をどう流れたかを、アクションごとに表示します。

失敗した箇所が分かります。For-Each や While の繰返しは、1 回ずつ表示されます
各ステップの View Payload で、入出力のペイロード（Summary／Details、ヘッダー）を確認できます。コピーやダウンロードもできます
View slowest activities で、遅い上位 10 件のアクティビティを確認できます。Map などは debug のときだけ含まれます
子の統合は View Child Instances で開き、Back で親へ戻ります
画面上部のダウンロードで、インスタンス全体のログを取得できます

トレース・レベルとペイロードの見え方

トレース・レベル	ペイロード	備考
Production	見えない	利用者名も記録されない。本番の通常運用向け
Audit	見える	ペイロードを開くと、ユーザー名と時刻が監査ログに記録される
Debug	見える（最も詳細）	同上。調査のときだけ使う

個人情報や金額を含むペイロードは、本番で常時見えないようにします。調査のために Debug へ上げたら、終わった後に戻します。

Errors ページと再送信

失敗したインスタンスは、Errors ページで扱います。Errors ページは、統合や接続ごとに、期間を指定してエラーをまとめて確認できます。

原因の確認：失敗したインスタンスのアクティビティ・ストリームで、エラーメッセージとペイロードを確認します。AI を使ったエラー・メッセージの要約（View an AI-Powered Error Message）もあります（提供状況は公式の AI Feature Availability で確認）
再送信（Resubmit）
- 手動のみ です。OIC は失敗したメッセージを自動では再送信しません
- 再送信できるのは 非同期統合 のエラーです。1 つのインスタンス ID につき 10 回まで です（OIC の概要のサービス制限）
- 再送信は、統合を 最初から 実行し直します。そのため各ステップを冪等にしておきます
- 再送信するメッセージのトレース・レベルを変えられます。再送信の履歴は Instances ページで追跡できます
破棄（Discard）
- Errors ページから消え、Instances ページでは aborted と表示されます
- 以後の操作（回復を含む）はできません。メッセージは一定期間のあとにサーバーから完全に削除されます
回復の状況：再送信（回復）に出したメッセージの状況を Errors ページで確認できます

実行データの保持期間は 既定で 32 日 です。それより長く残したい監査証跡は、統合の中で外部の表やファイルに記録します。

調査の手順

Observability > Instances で、ビジネス識別子（請求書番号など）で該当のインスタンスを探します
アクティビティ・ストリームで、失敗したアクションを特定します
View Payload で入出力を確認します（Production では見えないため、必要なら Debug の再現環境で確かめます）
原因（相手先の停止、データの不正、接続・認証、設計ミス）を切り分けます
一時的な原因なら再送信、データの不正なら元を直して再送信または破棄、設計ミスなら統合を直して再有効化します

インポート／エクスポートと環境移送

移送の単位

単位	形式・手段	使いどころ
統合 1 本	IAR（`.iar`）ファイル。ファイル名は「統合の識別子＋バージョン」	単体の持ち出し・取込、別インスタンスへの複製
プロジェクト	プロジェクトのデプロイメント。REST API にプロジェクトのエクスポートもある	開発 → テスト → 本番の展開、ロールバック
Git	プロジェクトとデプロイメントを GitHub リポジトリと連携できる	版管理とレビュー（公式の「Integrate Projects and Project Deployments with a GitHub Repository」）

プロジェクトのデプロイメントは、統合（とロボット）のバージョンの組合せを固めたスナップショットです。詳しくは OIC の概要を参照してください。

IAR のエクスポートとインポート

エクスポート

Design > Integrations で統合にカーソルを合わせ、Actions > Export を選びます
IAR ファイルがダウンロードされます。ロック中の統合もエクスポートできます

インポート

次のどちらかから、インポートのパネルを開きます
- プロジェクト内：Projects > プロジェクト > Integrations > Add（または +）> Import
- プロジェクトの外：Design > Integrations の Import
IAR ファイルを選びます
Import（接続の設定は後で）か Import and Configure（構成エディタを開く）を選びます
同じ識別子とバージョンの統合があれば、上書きの確認 が出ます
接続のプロパティを更新 し、有効化します

制限と注意

接続のプロパティは、インポート後に必ず更新します（接続先 URL や資格情報は環境ごとに違うため）
IAR を手作業で編集しません。接続名を書き換えると、接続を更新も削除もできなくなることがあります。編集が必要なときは Oracle サポートに相談します
OIC 3 の統合を Generation 2 へインポートすることはできません
低いバージョンへの移送：上位バージョンの機能を使っていない場合に限り可能です（例：25.02 の開発環境から 24.10 の本番へ）
lookupValue で参照しているルックアップは、IAR に含まれて一緒にインポートされます
Basic ルーティング統合は、OIC 3 へのインポート時にアプリケーション統合へ変換されます

移送後のチェックリスト

項目	移送後にすること
接続	URL・資格情報・セキュリティ・ポリシーを環境に合わせて更新し、Test で疎通を確認する
ルックアップ	環境ごとに値が異なるものは、値を確認・更新する
スケジュール	スケジュールだけを単独でエクスポートすることはできないため、時刻とタイム・ゾーンを確認し、開始（Start Schedule）する
スケジュール・パラメータ	環境ごとの値を Update schedule parameters で設定する
証明書・PGP 鍵	証明書はインスタンス全体で共通のため、移送先で登録する
ERP のイベント購読	有効化した時点で Fusion 側に購読が登録される。どの環境の Fusion を指すかを確認する
統合ユーザーのロール	移送先の Fusion／OIC で、必要なロールが付いているか確認する
接続エージェント	移送先のエージェント・グループを接続に関連付ける

プロジェクトの外にある統合をプロジェクトへ移すと、統合のエンドポイント URL が変わります。外部に URL を伝えたあとに移す場合は、呼出し元の設定変更が必要です（OIC の概要）。

移送の流れ（例）

開発環境で、統合が完成してテストに合格したことを確認する
IAR をエクスポートする（プロジェクトならデプロイメントを作る）
テスト環境へインポートし、接続・パラメータ・スケジュールを設定する
テスト環境で、テストケース表の全ケースを実施する
本番環境へ同じ成果物をインポートし、接続などを設定する
有効化し、監視画面で初回の実行を確認する
問題があれば、前のバージョンへ戻す（デプロイメントのロールバック、または前の IAR の再インポート）

運用設計

運用設計は、統合の設計書に「障害が起きたとき誰が何をするか」まで含めて書きます。

項目	決めること	例
監視の担当と頻度	誰がいつ Observability を見るか	運用担当が毎朝 9:00 に Instances と Errors を確認
通知	何を・誰に通知するか	グローバル・フォルトで Notification（統合名・フロー ID・業務キー・エラー内容）
再送信の基準	どのエラーを誰が再送信するか	一時的な接続エラーは運用担当が再送信。データ不正は依頼元へ返す
再送信の上限	10 回を超えたときの扱い	新しい要求として再実行する手順を用意
保持と証跡	32 日を超えて残す記録	業務キーと結果を外部の表やファイルに記録
権限	環境ごとのロール	本番は開発者に ServiceDeveloper を付けない。呼出し専用は ServiceInvoker
変更管理	本番への反映の手順	承認 → 移送 → チェックリスト → 初回監視。切戻し手順を用意

通知は集約する：エラー 1 件ごとにメールを出すと、障害時にメールが洪水になります。Notification アクションには送信数などの上限があります（オーケストレーション統合とアクション）
業務キーをそろえる：ビジネス識別子、通知、外部ログ、Fusion のジョブに、同じ業務キー（請求書番号など）を残します
再送信の前に冪等性を確認する：再送信は最初から再実行です。相手先が二重登録されない設計かを確認してから再送信します（考え方はビジネスイベントとアウトバウンド連携のパターンを参照）
ServiceMonitor は監視のみ のロールです。再送信や中止まで運用担当に任せるときは、必要なロールを公式の「Service Roles」で確認します

コード例

REST トリガーの統合を、外部のクライアントから確認する簡単なスクリプトです。認証トークンは接続とアダプタのコード例と同じ方法で取得します。期待するステータスは、統合設計書のエラー設計に合わせて変えてください（値は例です）。

#!/usr/bin/env bash
# 使い方: export OIC_ENDPOINT_URL=... OIC_TOKEN=... してから実行する
set -u
tmp=$(mktemp)
trap 'rm -f "$tmp"' EXIT

check() {  # $1=ケース名  $2=期待する HTTP ステータス  $3=要求本文（JSON）
  code=$(curl -s -o "$tmp" -w '%{http_code}' -X POST "$OIC_ENDPOINT_URL" \
    -H "Authorization: Bearer $OIC_TOKEN" \
    -H "Content-Type: application/json" -d "$3")
  if [ "$code" = "$2" ]; then
    echo "PASS  $1 ($code)"
  else
    echo "FAIL  $1 期待=$2 実際=$code"; cat "$tmp"; echo
  fi
}

check "正常（明細 2 件）" 200 '{"invoiceNumber":"INV-T-0001","supplierNumber":"S-10001","amount":110000,"lines":[{"lineNumber":1,"amount":100000},{"lineNumber":2,"amount":10000}]}'
check "必須項目の欠落"   400 '{"supplierNumber":"S-10001","amount":110000}'
check "請求書番号の重複" 409 '{"invoiceNumber":"INV-T-0001","supplierNumber":"S-10001","amount":110000,"lines":[]}'

同期統合が業務エラーを返すときの応答の例です（形式は設計で決めます）。

{
  "status": "ERROR",
  "errorCode": "SUPPLIER_NOT_FOUND",
  "message": "仕入先番号 S-99999 が存在しません",
  "invoiceNumber": "INV-T-0002"
}

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

グローバル・フォルトハンドラを実装しない：何も通知されず、本番で失敗に気付けません。最初の統合から実装します
Stop で終わらせる：失敗が Errors に出ません。通知してから終えるか、Re-throw します
同期統合のエラーを再送信できると思い込む：同期は再送信できません。呼出し元がリトライできる設計にします
再送信が冪等でない：最初から再実行されるため、二重登録が起きます。外部への書込みはアップサートにします
接続の更新を忘れて移送する：インポート後に接続先が開発環境のままになります。チェックリストで確認します
Debug のまま本番運用する：ペイロードが見える状態で、閲覧のたびに監査ログが増えます。調査のあとに戻します
破棄を軽く使う：Discard は元に戻せません。破棄の基準と承認を決めます
IAR を手編集する：接続が壊れる原因になります

統合ごとに ビジネス識別子・Logger・通知 の書き方をそろえ、調査の手順を共通にします
テストケース表を 統合設計書に添付 し、移送のたびに同じケースを実施します
変更は バージョンを上げて 有効化し、問題があれば前のバージョンへ戻せるようにします

試験対策ポイント

対応する試験：OIC 模擬テスト（1Z0-1042-26）の「エラー処理・監視・運用」（分野名は暫定。公式の出題範囲は受験前に確認してください）
スコープ：どのスコープにも Default Handler がある。ハンドラが成功すればスコープの後ろから続く。入れ子の段数に上限なし
グローバル・フォルトハンドラ：既定は Re-throw Fault。Stop はエラー処理フレームワークに渡らず、Succeeded になる。invoke が 1 つ以上必要
Re-throw Fault はフォルト・ハンドラの中でのみ使う。Throw New Fault は業務エラーの発生
再送信：手動のみ、非同期のみ、1 インスタンス ID につき 10 回まで、最初から再実行。Discard は元に戻せず、Instances では aborted
Abort は実行中の非同期、待機中・一時停止中のスケジュール統合に限る
トレース・レベル：Production ではペイロードが見えない。Audit と Debug は閲覧が監査ログに残る
テスト：有効化が前提。Configure and run。An Integration is not reachable は、有効か・swagger・refresh を確認
IAR：ファイル名は識別子＋バージョン。インポート後に接続プロパティを更新。手編集は非サポート。Gen2 へは戻せない