従量制テナンシの請求メッセージ使用の見積
請求メッセージの使用量は、テナンシの消費モデルによって異なります。このトピックは、従量制(ユニバーサル・クレジット)モデルを使用するテナンシに適用されます。次の情報を使用して、インスタンスで使用する請求メッセージの数を見積もります。
- クラウドで新しいOracle Integrationライセンスを作成した場合:
- 各メッセージ・パックには、1時間当たり5,000件の請求メッセージが含まれています。
- ユーザー・インタフェースで最大12個のメッセージ・パックを選択できます。
- 既存のOracle Fusion Middlewareライセンスをクラウドに持ち込んだ場合(BYOL):
- 各メッセージ・パックには、1時間当たり20,000件の請求メッセージが含まれています。
- ユーザー・インタフェースで最大3つのメッセージ・パックを選択できます。
サブスクライブするメッセージ・パックの数は、同期リクエストの処理時間にも影響します。メッセージ・パックの使用状況および同期リクエストを参照してください。
一般的なメッセージ消費ルール
次のルールは、すべてのOracle Integrationコンポーネントのメッセージ消費に適用されます。
| ルール | 説明 |
|---|---|
| トリガーおよび呼出し |
トリガーおよび呼出しは通常、いくつかの例外を除いて1つのメッセージとしてカウントされます。次に例を示します:
|
|
内部コール |
同じコンポーネント内の内部コールはメッセージとしてカウントされません。 たとえば、次はカウントされません:
ただし、ある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インスタンスでメッセージが発生する可能性があります。 |
統合メッセージ消費の例
この表では、メッセージ請求を計算する方法と、適用されるルールを例によって示します。
| 統合タイプ | シナリオ/フロー | 請求メッセージの計算 | 適用されるルール |
|---|---|---|---|
|
同期/非同期(トリガー) |
|
ペイロード・サイズは、トリガー時に考慮されます。 ceil(120/50) = 3メッセージ |
#1 (トリガー) |
|
同期/非同期(トリガー) |
|
ペイロード・サイズは、トリガー時に考慮されます。50KBを超える後続レスポンスもトラッキングされます。このシナリオでは、50KBを超えるファイルのみが考慮されます。 ceil(70/50) + ceil(170/50) = 2 +4 = 6メッセージ |
#1 (トリガー) #3 (ファイル) |
|
同期/非同期(トリガー) |
|
ペイロード・サイズは、トリガー時に考慮されます。50KBを超える後続レスポンスもトラッキングされます。 ceil (20/50) = 1メッセージ |
#1 (トリガー) |
|
同期/非同期(トリガー) |
|
ペイロード・サイズは、トリガー時に考慮されます。50KBを超える後続レスポンスもトラッキングされます。 ceil(10/50)+ ceil (70/50) + ceil(100/50) = 1+2+2 = 5メッセージ |
#1 (トリガー) #2 (起動) #3 (ファイル) |
|
同期/非同期(トリガー) |
|
ペイロード・サイズは、トリガー時に考慮されます。50KBを超える後続レスポンスもトラッキングされます。トリガーはペイロードのない単なるGETリクエストであるため、1つの請求メッセージであるとみなされます。 1メッセージ |
#1 (トリガー) |
|
スケジュール済フロー |
|
レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。 ceil(170/50) = 4メッセージ |
#3 (ファイル) |
|
スケジュール済フロー |
|
レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。 カウントされません。 |
なし |
|
スケジュール済フロー |
|
レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。 ceil(130/50) = 3メッセージ |
#3 (ファイル) |
|
スケジュール済フロー |
|
レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。 ceil(100/50) = 2メッセージ |
#2 (起動) |
|
スケジュール済フロー |
|
レスポンス・データが50KBを超える場合、各起動/ファイルは50 KBの倍数単位で考慮されます。 カウントされません。 |
#4 (内部) カウントされません |
|
子の統合フロー |
|
統合子フローの起動は、測定から除外されます。 カウントされません。親はカウントされる場合があることに注意してください。 |
#4 (内部) カウントされません |
|
子の統合フロー |
|
統合子フローの起動は測定から除外されます。後続のレスポンスはすべて測定されます。 個々の子 = 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には、追加機能に対して有効化できるいくつかのテクノロジおよびサービスが含まれています。
この表は、オプション機能を有効にした場合の追加のメッセージ消費を示しています。
| 機能 | 追加のメッセージ消費 |
|---|---|
|
|
|
|
|
メッセージ消費の例
次の表に、メッセージ消費量の計算の例を示します。
コンポーネント別メッセージ消費
最初のステップは、各コンポーネントによって消費されるメッセージを判別し、すべてのコンポーネントによって消費されるメッセージの合計を計算することです。
| コンポーネント | コンポーネント消費 | メッセージへの変換 | 消費されたメッセージ |
|---|---|---|---|
|
統合 |
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 |