請求メッセージに対する機能の影響
Oracle Integrationで特定の機能を使用すると、請求メッセージはインスタンスによって消費されます。 これは、統合によるデータの送信などには明らかですが、拡張データ保持やディザスタ・リカバリなどの機能も含まれています。
インスタンスには、スムーズでスケーラブルかつ回復力のある日常業務を確保するために、請求メッセージの使用をサポートするのに十分なメッセージ・パックが含まれている必要があります。 従量制テナンシのメッセージ・パック使用の見積りを参照してください。
サブスクライブするメッセージ・パックの数は、同期リクエストの処理時間にも影響します。 メッセージ・パックの使用状況および同期/非同期リクエストを参照してください。
次の項を参照して、請求メッセージの使用量の計算方法を確認してください。
一般的なメッセージ消費ルール
次のルールは、すべてのOracle Integrationコンポーネントのメッセージ消費に適用されます。
| ルール | 説明 |
|---|---|
| トリガーと呼出し |
トリガーおよび呼出しは通常、いくつかの例外を除いて1つのメッセージとしてカウントされます。 たとえば:
|
|
内部コール |
同じコンポーネント内の内部コールはメッセージとしてカウントされません。 たとえば、次のものはカウントされません:
ただし、あるOracle Integrationインスタンス内の統合で別のOracle Integrationインスタンス「します」内の統合をコールすると、ターゲットOracle Integrationインスタンス内のメッセージが表示されます。 |
|
50 KBを超えるメッセージ・ペイロード |
50 KBを超えるメッセージ・ペイロードの場合、追加の50 KBごとに1つの追加メッセージがカウントされます。 たとえば、メッセージ・ペイロードが102 KBの場合、2つの追加メッセージがカウントされます。 |
統合メッセージ消費
次のルールに従って、メッセージ消費量の計算方法を決定します。
| ルール番号 | ルール | 説明 |
|---|---|---|
|
1 |
トリガー |
各トリガー・アクティビティは、少なくとも1つのメッセージ(最大50 KBのインバウンド)としてカウントされます。 インバウンド・メッセージ・ペイロードが50 KBを超える場合、追加の50 KBごとに1つの追加メッセージがカウントされます。 |
|
2 |
Invoke |
呼出しリクエストはメッセージとしてカウントされませんが、50 KBを超える呼出しレスポンス数です。 メッセージ・ペイロードが50 KBを超える場合、追加の50 KBごとに1つの追加メッセージがカウントされます。 |
|
3 |
ファイル |
統合への受信ファイルがあるファイル・ベースのスケジュール済フローの場合、サイズが50 KBを超える場合にのみ、各ファイルが請求済メッセージ(50 KBの倍数)に変換されます。 |
|
4 |
内部 |
同じOracle Integrationインスタンス内の統合コールへの統合はカウントされません。 ただし、別のOracle Integrationインスタンスをコールすると、ターゲットのOracle Integrationインスタンスでメッセージが発生します。 |
統合メッセージ消費の例
この表は、メッセージ請求の計算方法と適用されるルールを例別に示しています。
| 統合タイプ | Scenario/Flow | 請求書メッセージ計算 | 適用されるルール |
|---|---|---|---|
|
Sync/Async (Trigger) |
|
ペイロード・サイズはトリガー時に考慮されます。 ceil(120/50) = 3メッセージ |
#1 (Trigger) |
|
Sync/Async (Trigger) |
|
ペイロード・サイズはトリガー時に考慮されます。 50 KBを超える後続のレスポンスも追跡されます。 このシナリオでは、50 KBを超えるファイルのみが考慮されます。 ceil(70/50) + ceil(170/50) = 2+4 = 6メッセージ |
#1 (Trigger) #3 (File) |
|
Sync/Async (Trigger) |
|
ペイロード・サイズはトリガー時に考慮されます。 50 KBを超える後続のレスポンスも追跡されます。 ceil (20/50) = 1メッセージ |
#1 (Trigger) |
|
Sync/Async (Trigger) |
|
ペイロード・サイズはトリガー時に考慮されます。 50 KBを超える後続のレスポンスも追跡されます。 ceil(10/50) + ceil (70/50) + ceil(100/50) = 1+2+2 = 5メッセージ |
#1 (Trigger) #2 (Invoke) #3 (File) |
|
Sync/Async (Trigger) |
|
ペイロード・サイズはトリガー時に考慮されます。 50 KBを超える後続のレスポンスも追跡されます。 トリガーはペイロードのないGETリクエストであるため、1つの課金対象メッセージとみなされます。 1件のメッセージ |
#1 (Trigger) |
|
スケジュール済フロー |
|
レスポンス・データが50 KBを超える場合、各呼出し/ファイルは50 KBの倍数で考慮されます。 ceil(170/50) = 4メッセージ |
#3 (File) |
|
スケジュール済フロー |
|
レスポンス・データが50 KBを超える場合、各呼出し/ファイルは50 KBの倍数で考慮されます。 カウントされません。 |
なし |
|
スケジュール済フロー |
|
レスポンス・データが50 KBを超える場合、各呼出し/ファイルは50 KBの倍数で考慮されます。 ceil(130/50) = 3メッセージ |
#3 (File) |
|
スケジュール済フロー |
|
レスポンス・データが50 KBを超える場合、各呼出し/ファイルは50 KBの倍数で考慮されます。 ceil(100/50) = 2メッセージ |
#2 (Invoke) |
|
スケジュール済フロー |
|
レスポンス・データが50 KBを超える場合、各呼出し/ファイルは50 KBの倍数で考慮されます。 カウントされません。 |
#4 (Internal) カウントなし |
|
子統合フロー |
|
統合子フロー起動はメータリングから放棄されます。 カウントされません。 親がカウントされる場合があることに注意してください。 |
#4 (Internal) カウントなし |
|
子統合フロー |
|
統合子フローの起動は、メータリングから放棄されます。 後続のレスポンスはすべて従量制されます。 各子= ceil(70/50) = 2メッセージ 親がカウントされる場合があることに注意してください。 |
#2 (Invoke) |
拡張データ保持メッセージ消費
デフォルトでは、標準およびエンタープライズ・エディション・インスタンスはデータを32日間保持し、Healthcareエディション・インスタンスはデータを184日間保持します。 エンタープライズ・エディション・インスタンスがある場合は、必要に応じて「データ保持期間の延長」を実行できます。
ノート:
StandardまたはHealthcareエディション・インスタンスの保持期間は変更できません。拡張データ保持を追加すると、1時間当たりのメッセージ消費量が次の表に示す割合で増加します。 この増加は、トリガー・リクエストおよび呼出しリクエストの受信メッセージおよび送信メッセージの時間ごとの合計に適用されます。
| 拡張データ保持期間 | データ保存のための追加のメッセージ消費 | 1時間ごとの合計メッセージ消費量の計算例 |
|---|---|---|
| 93日(3か月) | +10% | 3,000メッセージ+データretention= 3,300totalメッセージの300メッセージ |
| 184日(6か月) | +20% | 3,000メッセージ+ 600メッセージのデータretention= 3,600totalメッセージ |
注意:
後でデータ保存期間を短くすると、選択内容を保存するときに、新しく選択した期間より古いデータが削除されます。ディザスタ・リカバリ・メッセージの消費
「Oracleは障害時リカバリ・ソリューションを提供」を使用すると、自然災害または人為的災害から迅速にフェイルオーバーし、セカンダリ・リージョンでビジネス継続性を提供できます。 このソリューションは、計画移行やリージョン間の定期的な切替えにも使用できます。 Oracleは、ほぼすべての障害リカバリの責任を自動的に管理します。 管理責任は最小限です。
エンタープライズまたはHealthcareエディション・インスタンスにディザスタ・リカバリを追加できます。
ディザスタ・リカバリを追加すると、既存のメッセージ・パックの消費量に基づいてメッセージ・パックの消費量が増加します。 既存のメッセージ・パック消費量は、統合、データ保持、「プロセス自動化」、ディシジョンおよびロボティック・プロセス自動化によって消費されるメッセージ・パックの数です。
| 既存のメッセージ・パック消費量 | ディザスタ・リカバリのための追加のメッセージ・パック消費 | 合計メッセージ・パック消費量の計算例 |
|---|---|---|
| 1-3メッセージ・パック | +1メッセージ・パック | 2メッセージ・パック+ 1メッセージpack= 3messageパック |
| 4-8メッセージ・パック | +2メッセージ・パック | 6メッセージ・パック+ 2メッセージpacks= 8messageパック |
| 8以上のメッセージ・パック | +3メッセージ・パック | 12メッセージ・パック+ 3メッセージpacks= 15messageパック |
オプション機能の追加メッセージ消費
Oracle Integrationには、追加機能のロックを解除できるいくつかのテクノロジおよびサービスが含まれています。
この表は、オプション機能を有効にした場合の追加のメッセージ消費を示しています。
| 機能 | 追加のメッセージ消費 |
|---|---|
|
測定では、同時(Visual Builderアプリケーションと対話する一意のユーザー)の数が1時間間隔で追跡されます。 これらのVisual Builderユーザーは、メッセージの使用法に変換されます。 1時間当たり1人のVisual Builderユーザーは、1時間当たり100メッセージと同等です。 |
|
|
|
|
|
|
従量制テナンシのメッセージ消費の例
次の表に、(ユニバーサル・クレジットを使用した)従量制テナンシのメッセージ消費計算の例を示します。
コンポーネント別メッセージ消費
最初のステップは、各コンポーネントによって消費されるメッセージを判別し、すべてのコンポーネントによって消費されるメッセージの合計を計算することです。
| コンポーネント | コンポーネント消費 | メッセージへの変換 | 消費されたメッセージ |
|---|---|---|---|
|
統合 |
9,000メッセージ |
x 1 |
9,000 |
|
拡張データ保存 |
6か月 |
x 20% |
1,800 |
|
プロセスの自動化 |
|
x 1 |
1,900 |
|
意思決定 |
1,400個のデシジョン呼出し |
x 1 |
1,400 |
|
ロボットによるプロセス自動化 |
|
x 1 |
1,300 |
|
メッセージ合計 |
該当なし | 該当なし |
15,400 |
メッセージ・パック消費
次のステップでは、メッセージ合計をカバーするために必要なメッセージ・パックの合計を計算します。
| ライセンス・タイプ | パック当たりのメッセージ数 | 消費済パック数 |
|---|---|---|
| クラウドの新しいOracle Integrationライセンス | 5,000 | 4 |
| 既存のOracle Fusion Middlewareライセンスからクラウドへ(BYOL) | 20,000 | 1 |
障害時リカバリ用のメッセージ・パック消費量
オプションで、ディザスタ・リカバリを設定した場合は、ディザスタ・リカバリに適切な数のメッセージ・パックを追加する必要があります。
| ライセンス・タイプ | 消費されたメッセージ・パックの数 | ディザスタ・リカバリ用のメッセージ・パック数 |
|---|---|---|
| クラウドの新しいOracle Integrationライセンス | 4 | 2 |
| 既存のOracle Fusion Middlewareライセンスからクラウドへ(BYOL) | 1 | 1 |
メッセージ・パック消費合計
最後に、メッセージ・パックの合計消費量を取得するためにすべてを追加します。
| ライセンス・タイプ | 消費されたメッセージ・パックの数 | ディザスタ・リカバリ用のメッセージ・パック数 | 総計 |
|---|---|---|---|
| クラウドの新しいOracle Integrationライセンス | 4 | 2 | 6 |
| 既存のOracle Fusion Middlewareライセンスからクラウドへ(BYOL) | 1 | 1 | 2 |