About Integrations Usage
When creating Oracle Integration instances, administrators specify the number of message packs they plan to use for per instance.
Rules for tracking Integration billed messages
Follow these rules to determine how message consumption is calculated.
Number | Rule | Description |
---|---|---|
1 |
Trigger |
Each trigger activity counts as at least one message, up to 50KB inbound. If the inbound message payload exceeds 50KB, 1 additional message is counted for each additional 50KB. |
2 |
Invoke |
Invoke requests don't count as messages, but invoke responses over 50KB count. If the message payload exceeds 50KB, 1 additional message is counted for each additional 50KB. |
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 50KB) only when the size is greater than 50KB. |
4 |
Internal |
Internal calls within the same Oracle Integration instance aren't counted as messages. For example, the following aren't counted:
Calling another Oracle Integration instance does incur messages in the target Oracle Integration instance, and, depending on the response size, may also incur messages in the calling Oracle Integration instance. |
Integration Usage 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 50KB is also tracked. In this scenario, only files greater than 50KB 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 50KB is also tracked. ceil (20/50) = 1 message |
#1 (Trigger) |
Sync/Async (Trigger) |
|
Payload size is considered at trigger. Any subsequent response greater than 50KB 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 50KB 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 50KB when response data is more than 50KB. ceil(170/50) = 4 messages |
#3 (File) |
Scheduled flow |
|
Each invoke/file is considered in multiples of 50KB when response data is more than 50KB. Not counted. |
None |
Scheduled flow |
|
Each invoke/file is considered in multiples of 50KB when response data is more than 50KB. ceil(130/50) = 3 messages |
#3 (File) |
Scheduled flow |
|
Each invoke/file is considered in multiples of 50KB when response data is more than 50KB. ceil(100/50) = 2 messages |
#2 (Invoke) |
Scheduled flow |
|
Each invoke/file is considered in multiples of 50KB when response data is more than 50KB. 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) |
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 |