機能が請求メッセージに与える影響

Oracle Integrationで特定の機能を使用すると、請求メッセージはインスタンスによって消費されます。これは、統合によるデータの送信などでは明らかですが、拡張データ保持やディザスタ・リカバリなどの機能も含まれます。

インスタンスには、スムーズでスケーラブルかつ回復力のある日常業務を確保するために、請求メッセージの使用をサポートするのに十分なメッセージ・パックが含まれている必要があります。従量制テナンシのメッセージ・パック使用の見積りを参照してください。

サブスクライブするメッセージ・パックの数は、同期リクエストの処理時間にも影響します。メッセージ・パックの使用状況および同期/非同期リクエストを参照してください。
ノート

  • 消費されたメッセージ・パックの数が、サブスクライブされたメッセージ・パックの数より多い場合、超過とみなされます。請求対象とみなされるメッセージ・パックの最終数は、サブスクライブ済メッセージ・パック数または消費済メッセージ・パック数のいずれか大きい方の値になります。
  • 超過の場合、同期および非同期リクエストの制限は増加しません。

次の項を参照して、請求メッセージの使用量の計算方法を確認してください。

一般的なメッセージ消費ルール

すべてのOracle Integrationコンポーネントのメッセージ消費には、次のルールが適用されます。

ルール 説明
トリガーおよび呼出し

トリガーおよび呼出しは通常、いくつかの例外を除いて1つのメッセージとしてカウントされます。次に例を示します:

  • 統合で別の統合がコールされている場合を除き、各Oracle Integrationトリガー・アクティビティは1つのメッセージとしてカウントされます。
  • Oracle Integrationからのリクエストの起動は、メッセージとしてカウントされず、レスポンスが50KBを超える場合にのみカウントされます。
  • プロセスが別のプロセスを呼び出す場合を除き、各プロセスの呼出しは1つのメッセージとしてカウントされます。
  • ネイティブ・アクション・リクエスト(統合でのアクション)は、invokeアクティビティとみなされます。
  • 統合のイベント・アクション(イベントの公開など)は、イベントをサブスクライブする統合の実行を開始するため、トリガー・アクティビティとみなされます。

内部コール

同じコンポーネント内の内部コールはメッセージとしてカウントされません。

たとえば、次はカウントされません:

  • 同じOracle Integrationインスタンス内での統合
  • 処理するプロセス

ただし、あるOracle Integrationインスタンスの統合で別のOracle Integrationインスタンスの統合をコールすると、ターゲットのOracle Integrationインスタンスにメッセージが発生します。

50KBを超えるメッセージ・ペイロード

50KBを超えるメッセージ・ペイロードの場合、追加の50KBごとに1つの追加メッセージがカウントされます。たとえば、メッセージ・ペイロードが102KBの場合、2つの追加メッセージがカウントされます。

統合メッセージ消費

次のルールに従って、メッセージ消費を計算する方法を決定します。

ルール番号 ルール 説明

1

トリガー

各トリガー・アクティビティでは、少なくとも1つのメッセージ(最大で50KBインバウンド)としてカウントされます。インバウンド・メッセージのペイロードが50KBを超える場合、追加の50KBごとに1個の追加メッセージがカウントされます。

2

起動

起動リクエストはメッセージとしてカウントされず、50KBを超える起動レスポンスはカウントされます。メッセージのペイロードが50KBを超える場合、追加の50KBごとに1個の追加メッセージがカウントされます。

3

ファイル

統合に対する受信ファイルが存在するファイル・ベースのスケジュール済フローの場合、各ファイルは、サイズが50KBより大きい場合にのみ、(50KBの倍数単位で)請求メッセージに変換されます。

4

内部

同じOracle Integrationインスタンス内の統合コールへの統合はカウントされません。ただし、別のOracle Integrationインスタンスをコールすると、ターゲットのOracle Integrationインスタンスでもメッセージが発生します。

統合メッセージ消費の例

この表では、メッセージ請求を計算する方法と、適用されるルールを例によって示します。

統合タイプ シナリオ/フロー 請求メッセージの計算 適用されるルール

同期/非同期(トリガー)

  1. 120KBのペイロードのあるRESTインバウンド。

  2. データ変換。

  3. Logfireにデータをプッシュする外部起動。

ペイロード・サイズは、トリガー時に考慮されます。

ceil(120/50) = 3メッセージ

#1 (トリガー)

同期/非同期(トリガー)

  1. 70KBのペイロードのあるSOAPインバウンド。

  2. ループでファイルをダウンロードします。

  3. 20KB、170KBおよび40KBのサイズの3ファイルがそれぞれダウンロードされます。

  4. データの変換/エンリッチメント。

  5. RESTを介して外部システムにデータをプッシュする外部起動。

ペイロード・サイズは、トリガー時に考慮されます。50KBを超える後続レスポンスもトラッキングされます。このシナリオでは、50KBを超えるファイルのみが考慮されます。

ceil(70/50) + ceil(170/50) = 2 +4 = 6メッセージ

#1 (トリガー)

#3 (ファイル)

同期/非同期(トリガー)

  1. 20KBのデータと2つの行をプルしたデータベース・アダプタ。

  2. 行ごとに1個のアウトバウンドREST起動が発生し、その結果、起動ごとに20KBのデータが生成されます。

  3. データ・エンリッチメント/変換。

  4. 外部の場所へのFTP。

ペイロード・サイズは、トリガー時に考慮されます。50KBを超える後続レスポンスもトラッキングされます。

ceil (20/50) = 1メッセージ

#1 (トリガー)

同期/非同期(トリガー)

  1. 10KBのペイロードのあるSOAPインバウンド。

  2. ループでファイルをダウンロードします。サイズがそれぞれ20KBおよび70KBの2つのファイルがダウンロードされます。

  3. RESTアダプタを介してさらにデータを取得する外部起動。100KBのデータが返されます。

  4. 外部の場所へのFTP。

ペイロード・サイズは、トリガー時に考慮されます。50KBを超える後続レスポンスもトラッキングされます。

ceil(10/50)+ ceil (70/50) + ceil(100/50) = 1+2+2 = 5メッセージ

#1 (トリガー)

#2 (起動)

#3 (ファイル)

同期/非同期(トリガー)

  1. テンプレート・パラメータがあり、ペイロードのない単純なREST GETリクエスト。

  2. 連絡先詳細を取得するためのOracle Fusion Cloud B2C Serviceへのコール。40KBのレスポンスが返されます。

  3. 連絡先データが返されます。

ペイロード・サイズは、トリガー時に考慮されます。50KBを超える後続レスポンスもトラッキングされます。トリガーはペイロードのない単なるGETリクエストであるため、1つの請求メッセージであるとみなされます。

1メッセージ

#1 (トリガー)

スケジュール済フロー

  1. スケジュール済トリガー。
  2. ループでファイルをダウンロードします。サイズがそれぞれ20 KB、170 KB、40 KBの3つのファイルがダウンロードされます。
  3. データ変換。

  4. 10バイトのレスポンスが生成されるデータを転送する外部起動。

レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。

ceil(170/50) = 4メッセージ

#3 (ファイル)

スケジュール済フロー

  1. スケジュール済トリガー。
  2. 30KBのデータと10の行をプルしたデータベース・アダプタ。
  3. データ変換。

  4. 5バイトのレスポンスが生成されるデータを転送する外部起動。

レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。

カウントされません。

なし

スケジュール済フロー

  1. スケジュール済トリガー。
  2. BIPレポートを介してデータを取得する外部SOAP起動。130KBのデータが返されます。
  3. RESTアダプタを介してさらにデータを取得する外部起動。10KBのデータが返されます。

  4. データ変換。
  5. 5バイトのレスポンスが生成されるデータを転送する外部起動。

レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。

ceil(130/50) = 3メッセージ

#3 (ファイル)

スケジュール済フロー

  1. スケジュール済トリガー。
  2. ループでファイルをダウンロードします。サイズがそれぞれ20KBおよび40KBの2つのファイルがダウンロードされます。
  3. RESTアダプタを介してさらにデータを取得する外部起動。100KBのデータが返されます。

  4. 外部の場所へのFTP。

レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。

ceil(100/50) = 2メッセージ

#2 (起動)

スケジュール済フロー

  1. スケジュール済トリガー。
  2. RESTアダプタを介してさらにデータを取得する外部起動。10KBのデータが返されます。
  3. データ変換。

  4. 500バイトのレスポンスが生成されるデータを転送する外部REST起動。

レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。

カウントされません。

#4 (内部)

カウントされません

子の統合フロー

  1. 親の統合フローがループでRESTを介して子の統合フローをコールします。
  2. 子の統合フローは、親フローから渡された情報を含む通知電子メールを送信します。
  3. 子フローの実行が完了します。

統合子フローの起動は、測定から除外されます。

カウントされません。親はカウントされる場合があることに注意してください。

#4 (内部)

カウントされません

子の統合フロー

  1. 親の統合フローがFTPアダプタを介してCSVファイルをダウンロードします。CSVには5行が含まれます。
  2. CSVファイルの各行は、子の統合子フローをコールします。
    1. 子の統合フローは、入力として渡されたorderidを読み取ります。

    2. Oracle Fusion Cloud B2C Serviceに対するリクエストを起動して、オーダーに関するデータを取得します。各起動により70KBのデータが返されます。

    3. 子フローでのデータ変換。

    4. FTPアダプタを介してデータをプッシュし、ファイルに書き込みます。

    5. 子フローの実行が完了します。

統合子フローの起動は測定から除外されます。後続のレスポンスはすべて測定されます。

個々の子 = ceil(70/50) = 2メッセージ

親はカウントされる場合があることに注意してください。

#2 (起動)

拡張データ保持メッセージ消費

デフォルトでは、Standardエディション・インスタンスとEnterpriseエディション・インスタンスはデータを32日間保持し、Healthcareエディション・インスタンスはデータを184日間保持します。Enterpriseエディション・インスタンスがある場合は、必要に応じてデータ保存期間を延長できます。

ノート

StandardエディションまたはHealthcareエディション・インスタンスの保持期間は変更できません。

拡張データ保持を追加すると、1時間当たりのメッセージ消費量が次の表に示す割合で増加します。この増加は、トリガー・リクエストおよび呼出しリクエストの受信メッセージおよび送信メッセージの時間ごとの合計に適用されます。

延長されたデータ保持期間 データ保存のための追加のメッセージ消費 1時間ごとの合計メッセージ消費量の計算例
93日(3か月) +10% 3,000メッセージ+データ保存のための300メッセージ= 3,300メッセージの合計
184日(6か月) +20% 3,000メッセージ+データ保存のための600メッセージ= 3,600メッセージの合計

注意:

後でデータ保存期間を短くすると、選択内容を保存するときに、新しく選択した期間より古いデータが削除されます。

ディザスタ・リカバリ・メッセージの消費

Oracleが提供するディザスタ・リカバリ・ソリューションにより、自然災害または人為的災害から迅速にフェイルオーバーし、セカンダリ・リージョンでビジネス継続性を提供できます。このソリューションは、計画移行やリージョン間の定期的な切替えにも使用できます。Oracleは、ほぼすべてのディザスタ・リカバリの職責を自動的に管理します。管理責任は最小限です。

エンタープライズまたはHealthcareエディション・インスタンスにディザスタ・リカバリを追加できます。

ディザスタ・リカバリを追加すると、既存のメッセージ・パックの消費量に基づいてメッセージ・パックの消費量が増加します。既存のメッセージ・パック消費は、統合、データ保持、プロセス自動化および人間がループ、意思決定およびロボティック・プロセス自動化によって消費するメッセージ・パックの数です。

既存のメッセージ・パック消費量 ディザスタ・リカバリのための追加のメッセージ・パック消費 合計メッセージ・パック消費量の計算例
1-3メッセージ・パック +1メッセージ・パック 2メッセージ・パック+ 1メッセージ・パック= 3メッセージ・パック
4-8メッセージパック +2メッセージ・パック 6メッセージ・パック+ 2メッセージ・パック= 8メッセージ・パック
8+メッセージ・パック +3メッセージ・パック 12メッセージ・パック+ 3メッセージ・パック= 15メッセージ・パック

オプション機能の追加メッセージ消費

Oracle Integrationには、追加機能のロックを解除できるいくつかのテクノロジおよびサービスが含まれています。

この表は、オプション機能を有効にした場合の追加のメッセージ消費を示しています。

機能 追加のメッセージ消費

Visual Builder

測定では、1時間の間隔内でOracle Visual Builderアプリケーションと同時一意のユーザー対話の数をトラッキングします。これらのOracle Visual Builderユーザーは、メッセージの使用方法に変換されます。1時間当たり1人のOracle Visual Builderユーザーは、1時間当たり100メッセージに相当します。

ヒューマン・イン・ザ・ループ
  • ワークフロー呼出し当たり+1メッセージ

    別のワークフローを起動するワークフローでは、この料金は発生しません

  • 最初の1時間後のワークフロー期間の時間当たり+1メッセージ

プロセス自動化

  • プロセス起動ごとに+1メッセージ

    別のプロセスを起動するプロセスでは、この手数料は発生しません

  • 最初の1時間後のプロセス期間1時間当たり+1メッセージ

決定事項

  • 決定呼出しごとに+1メッセージ

ロボットによるプロセスの自動化

  • ロボットの呼び出しごとに+1メッセージ
  • 最初の5分後のロボットの継続時間5分当たり+1メッセージ

エージェントAIツール

エージェントAIツールには、ダイレクト・メッセージ消費料金はありません。ただし、ツールが実行されると、そのツールにリンクされている統合も実行されます。通常のメッセージ消費ルールが統合に適用されます。

AIエージェント

AIエージェントが実行されると、統合も実行されます。通常のメッセージ消費ルールが統合に適用されます。

ナレッジ・ベース

データ取込みおよびナレッジ・ベースの問合せには、ダイレクト・メッセージ消費料金はありません。ただし、統合をコールしてナレッジ・ベースにデータをロードすると、通常のメッセージ消費ルールが統合に適用されます。

従量制テナンシのメッセージ消費の例

次の表に、(ユニバーサル・クレジットを使用した)従量制テナンシのメッセージ消費計算の例を示します。

コンポーネント別メッセージ消費

最初のステップは、各コンポーネントによって消費されるメッセージを判別し、すべてのコンポーネントによって消費されるメッセージの合計を計算することです。

コンポーネント コンポーネント消費 メッセージへの変換 消費されたメッセージ

統合

9,000メッセージ

x 1

9,000

データ保持の拡大

6か月

x 20%

1,800

ヒューマン・イン・ザ・ループ
  • 1,700件のワークフロー呼出し
  • 1~2時間続く200のワークフロー

x 1

1,900

プロセス自動化

  • 1,700個のプロセス起動
  • 1~2時間持続する200プロセス

x 1

1,900

決定

1,400個のデシジョン呼出し

x 1

1,400

ロボットによるプロセスの自動化

  • 1,200個のロボット呼び出し
  • 5分から10分続く100回のロボット呼び出し

x 1

1,300

AIエージェントとエージェントAIツール

  • 1000件のエージェント呼出し
  • エージェントは、エージェントの起動ごとに2つのツールを呼び出します。

x 1

3,000

MCPサーバーのツールとしての統合

  • 外部エージェントは、Oracle Integration MCPサーバーをコールしてツールを起動します。
  • MCPを使用した1000個のツール呼出し

x 1

1,000

ナレッジ・ベース

  • ナレッジ・ベースへの150KBドキュメントの取込み
  • ナレッジ・ベースへの1MBドキュメントの取込み

各統合コールについて:

2メッセージ

+

150KBのドキュメントを処理するための3つのメッセージ

+

1MBのドキュメントを処理するための20メッセージ

x 1

25

外部エージェントとエージェントAIツール

  • 外部エージェントは、MCPサーバーを使用してOracle IntegrationのAIツールを呼び出します。
  • 1,000件のエージェント呼出し(1,000メッセージ)
  • エージェントは、エージェントの起動ごとに5つのツールを呼び出します(5,000メッセージ)。

x 1

6,000

メッセージ合計

該当なし 該当なし

25,425

メッセージ・パック消費

次のステップでは、メッセージ合計をカバーするために必要なメッセージ・パックの合計を計算します。

ライセンス・タイプ パック当たりのメッセージ数 消費済パック数
クラウドの新しいOracle Integrationライセンス 5,000 6
クラウドへの既存のOracle Fusion Middlewareライセンス(BYOL) 20,000 2

障害時リカバリ用のメッセージ・パック消費量

オプションで、ディザスタ・リカバリを設定した場合は、ディザスタ・リカバリに適切な数のメッセージ・パックを追加する必要があります。

ライセンス・タイプ 消費されたメッセージ・パックの数 ディザスタ・リカバリ用のメッセージ・パック数
クラウドの新しいOracle Integrationライセンス 6 3
クラウドへの既存のOracle Fusion Middlewareライセンス(BYOL) 2 2

メッセージ・パック消費合計

最後に、メッセージ・パックの合計消費量を取得するためにすべてを追加します。

ライセンス・タイプ 消費されたメッセージ・パックの数 ディザスタ・リカバリ用のメッセージ・パック数 総計
クラウドの新しいOracle Integrationライセンス 6 3 9
クラウドへの既存のOracle Fusion Middlewareライセンス(BYOL) 2 2 4