Estimate Message Usage
When you create an Oracle Integration instance, you specify the number of message packs you expect the instance to use. Use the following information to help estimate how many message packs you'll need.
The number of message packs you subscribe to can also affect the processing time of synchronous requests. See Message Pack Usage and Synchronous Requests.
Common Message Consumption Rules
The following rules apply to message consumption in all Oracle Integration components.
| Rule | Description |
|---|---|
| Triggers and invokes |
Triggers and invokes are generally counted as 1 message with a few exceptions. For example:
|
|
Internal calls |
Internal calls within the same component aren't counted as messages. For example, the following aren't counted:
However, an integration in one Oracle Integration instance calling an integration in another Oracle Integration instance does incur messages in the target Oracle Integration instance. |
|
Message payloads over 50 KB |
For message payloads over 50 KB, 1 additional message is counted for each additional 50 KB. For example, if a message payload is 102 KB, 2 additional messages would be counted. |
Integration Message Consumption
Follow these rules to determine how message consumption is calculated.
| Rule number | Rule | Description |
|---|---|---|
|
1 |
Trigger |
Each trigger activity counts as at least one message, up to 50 KB inbound. If the inbound message payload exceeds 50 KB, 1 additional message is counted for each additional 50 KB. |
|
2 |
Invoke |
Invoke requests don't count as messages, but invoke responses over 50 KB count. If the message payload exceeds 50 KB, 1 additional message is counted for each additional 50 KB. |
|
3 |
File |
For file based scheduled flows where there are incoming files into integrations, each file is converted into a billed message (in multiples of 50 KB) only when the size is greater than 50 KB. |
|
4 |
Internal |
Integration to integration calls within the same Oracle Integration instance aren't counted. However, calling another Oracle Integration instance does incur messages in the target Oracle Integration instance. |
Integration Message Consumption Examples
This table shows by example how message billing is calculated and the rules that apply.
| Integration Type | Scenario/Flow | Billing Message Calculation | Rules That Apply |
|---|---|---|---|
|
Sync/Async (Trigger) |
|
Payload size is considered at trigger. ceil(120/50) = 3 messages |
#1 (Trigger) |
|
Sync/Async (Trigger) |
|
Payload size is considered at trigger. Any subsequent response greater than 50 KB is also tracked. In this scenario, only files greater than 50 KB are considered. ceil(70/50) + ceil(170/50) = 2 +4 = 6 messages |
#1 (Trigger) #3 (File) |
|
Sync/Async (Trigger) |
|
Payload size is considered at trigger. Any subsequent response greater than 50 KB is also tracked. ceil (20/50) = 1 message |
#1 (Trigger) |
|
Sync/Async (Trigger) |
|
Payload size is considered at trigger. Any subsequent response greater than 50 KB is also tracked. ceil(10/50)+ ceil (70/50) + ceil(100/50) = 1+2+2 = 5 messages |
#1 (Trigger) #2 (Invoke) #3 (File) |
|
Sync/Async (Trigger) |
|
Payload size is considered at trigger. Any subsequent response greater than 50 KB is also tracked. Since the trigger is just a GET request with no payload, it's considered 1 billed message. 1 message |
#1 (Trigger) |
|
Scheduled flow |
|
Each invoke/file is considered in multiples of 50 KB when response data is more than 50 KB. ceil(170/50) = 4 messages |
#3 (File) |
|
Scheduled flow |
|
Each invoke/file is considered in multiples of 50 KB when response data is more than 50 KB. Not counted. |
None |
|
Scheduled flow |
|
Each invoke/file is considered in multiples of 50 KB when response data is more than 50 KB. ceil(130/50) = 3 messages |
#3 (File) |
|
Scheduled flow |
|
Each invoke/file is considered in multiples of 50 KB when response data is more than 50 KB. ceil(100/50) = 2 messages |
#2 (Invoke) |
|
Scheduled flow |
|
Each invoke/file is considered in multiples of 50 KB when response data is more than 50 KB. Not counted. |
#4 (Internal) None counted |
|
Child Integration flow |
|
Integration child flow invoke is waived from metering. Not counted. Note that the parent may count. |
#4 (Internal) None counted |
|
Child Integration flow |
|
Integration child flow invokes are waived from metering. Any subsequent response is metered. Each child = ceil(70/50) = 2 messages Note that the parent may count. |
#2 (Invoke) |
Extended Data Retention Message Consumption
By default, Standard and Enterprise edition instances retain data for 32 days, and Healthcare edition instances retain data for 184 days. If you have an Enterprise edition instance, you can extend the data retention period if you want.
You can't change the retention period for Standard or Healthcare edition instances.
Adding extended data retention increases your total message consumption.
This table shows how different data retention periods affect your message consumption.
| Extended data retention period | Additional message consumption for data retention | Example calculation of total message consumption |
|---|---|---|
| 93 days (3 months) | +10% | 3,000 messages + 300 messages for data retention = 3,300 total messages |
| 184 days (6 months) | +20% | 3,000 messages + 600 messages for data retention = 3,600 total messages |
This increased message consumption may or may not increase your message pack consumption. In the examples above, if you had 1 message pack of 5,000 messages, the service instance's total message consumption (3,300 or 3,600 messages) would still be within the limits of that 1 message pack , so you wouldn't incur any additional cost.
If you later decreased your data retention period, your message consumption would decrease, but any data older than the newly selected period would be deleted when you save your selection.
Disaster Recovery Message Consumption
Oracle provides a disaster recovery solution that allows you to fail over quickly from natural or human-made disasters and provide business continuity in your secondary region. You can also use this solution for planned migrations and switch between regions periodically. Oracle manages nearly all disaster recovery responsibilities automatically for you. Your administrative responsibilities are minimal.
You can add disaster recovery to Enterprise or Healthcare edition instances.
Adding disaster recovery increases your message pack consumption.
This table shows the additional message pack consumption and cost when you add disaster recovery.
| Existing message pack consumption * | Additional message pack consumption for disaster recovery | Additional cost for disaster recovery | Example calculation of total message pack consumption |
|---|---|---|---|
| 1-3 message packs | +1 message pack | 33% to 100% | 2 message packs + 1 message pack = 3 message packs |
| 4-8 message packs | +2 message packs | 25% to 50% | 6 message packs + 2 message packs = 8 message packs |
| 8+ message packs | +3 message packs | Up to 37% | 12 message packs + 3 message packs = 15 message packs |
* Existing message pack consumption includes additional message consumption for features such as extended data retention.
Additional Message Consumption for Optional Features
Oracle Integration includes several technologies and services that you can enable for additional features.
This table shows the additional message consumption when you enable optional features.
| Feature | Additional message consumption |
|---|---|
| Visual Builder |
|
| Process Automation |
|
| Decisions |
|
| Robotic process automation |
|
Overage Message Packs
If your Oracle Integration instance consumes more messages than what is included in the message packs you purchased, you'll be billed for overage message packs. Overage message packs are smaller than regular message packs.
- For Oracle Integration licenses, overage message packs include 2,500 messages per hour (instead of 5,000).
- For Oracle Fusion Middleware licenses (BYOL), overage message packs include 10,000 messages per hour (instead of 20,000).
Overage message packs don't apply to Oracle Integration for SaaS instances.
Message Consumption Example
The following tables show an example of message consumption calculations. The first step is to determine the messages consumed by each component and then calculate the total messages consumed by all components.
Table 5-1 Message Consumption by Component
| Component | Component consumption | Conversion to messages | Messages consumed |
|---|---|---|---|
|
Integration |
2,500 messages |
x 1 |
2,500 |
| Extended data retention |
6 months |
x 20% |
500 |
|
Visual Builder |
3 OCPUs |
|
12,500 |
|
Process Automation |
|
x 1 |
4,000 |
|
Robotic process automation |
500 robot invocations |
x 1 |
500 |
| MESSAGE TOTAL | N/A | N/A | 20,000 |
The next step is to figure out if the total consumed messages are covered by the subscribed message packs. If not, determine how many overage message packs are needed to make up the difference. Then add the subscribed and overage message packs together to determine the total message packs consumed.
Table 5-2 Subscribed and Overage Message Pack Consumption
| Message pack type | Messages per pack | Number of packs | Messages |
|---|---|---|---|
| Subscribed | 5,000 | 3 | 15,000 |
| Overage
20,000 consumed - 15,000 subscribed = 5,000 overage |
2,500 | 2 | 5,000 |
| MESSAGE PACK TOTAL | N/A | 5 | 20,000 |
Optionally, if you've set up disaster recovery, you need to add the appropriate number of message packs for disaster recovery to your message pack consumption total.
Table 5-3 Total Message Pack Consumption Including Disaster Recovery
| Component | Number of message packs |
|---|---|
| Message pack total | 5 |
| Disaster recovery | 2 |
| GRAND TOTAL | 7 |
Calculate Requests Per Second
If a synchronous integration keeps timing out or is taking longer than usual to complete, the integration might be trying to process too many requests. Knowing the requests that your instance processes in a second helps you design synchronous integrations that deliver the fast responses that you need.
-
Generally, the words "message" and "request" are synonymous. However, when you're working with large payloads, you might consume more than one message per request. This change impacts your calculations. See View Message Metrics and Billable Messages.
The calculations in this section assume that every request is 50 KB or smaller.
-
This calculation is typically called TPS, or transactions per second. TPS doesn't apply directly to Oracle Integration for two reasons:
- Oracle Integration processes requests, rather than transactions.
- Sizing in Oracle Integration is based on the hourly consumption of messages, rather than the per-second consumption.
The Oracle Integration equivalent to TPS is requests per second, which is your concurrency.
- Determine the approximate number of requests that an instance can process in
one minute.
- Calculate your concurrency (the number of concurrent requests your system can
handle from client applications).
Example 5-1 Processing the maximum number of concurrent requests
Let's take a look at a sample request queue when an instance that can handle 55 concurrent requests is working at full capacity.
The following table illustrates how requests arrive and complete as each second passes. The total requests in the queue increase until they reach 55 and remain at 55 indefinitely. After 5 seconds (the response time), requests start completing.
| Time that has elapsed | Requests that arrive | Requests that complete | Total requests in the queue |
|---|---|---|---|
|
1 second |
11 |
0 |
11 |
|
2 seconds |
11 |
0 |
22 |
|
3 seconds |
11 |
0 |
33 |
|
4 seconds |
11 |
0 |
44 |
|
5 seconds |
11 |
11 |
55 |
|
6 seconds |
11 |
11 |
55 |
|
7 seconds |
11 |
11 |
55 |
|
8 seconds |
11 |
11 |
55 |
Example 5-2 Exceeding the maximum concurrent requests
Imagine the same instance is receiving a higher number of requests per second than the maximum concurrency value. The following table illustrates how quickly the number of requests in the queue can build, even when you exceed the concurrency by just a few requests. After 3 seconds, the instance has already exceeded its maximum number of concurrent requests, and within 8 seconds, the instance is dealing with twice the maximum number of concurrent requests.
If an integration is likely to exceed the instance's maximum concurrency, the integration is probably going to experience timeouts when built as a synchronous integration. Instead, build the integration as an asynchronous integration.
| Time that has elapsed | Requests that arrive | Requests that complete | Total requests in the queue |
|---|---|---|---|
|
1 second |
20 |
0 |
20 |
|
2 seconds |
20 |
0 |
40 |
|
3 seconds |
20 |
0 |
60 |
|
4 seconds |
20 |
0 |
80 |
|
5 seconds |
20 |
11 |
89 |
|
6 seconds |
20 |
11 |
98 |
|
7 seconds |
20 |
11 |
107 |
|
8 seconds |
20 |
11 |
116 |
