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: Process Automation to Integration Visual Builder to Integration Integration to Integration 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)	REST inbound with 120KB payload. Data transformation. External invoke to push data to Logfire.	Payload size is considered at trigger. ceil(120/50) = 3 messages	#1 (Trigger)
Sync/Async (Trigger)	SOAP inbound with 70KB payload. Download files in a loop. 3 files downloaded of sizes 20KB, 170KB, and 40KB, respectively. Data transformation/enrichment. External invoke to push data to an external system via REST.	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)	Database adapter pulling in 20KB data and 2 rows. For each row, 1 outbound REST invoke is made, which results in 20KB data for each invoke. Data enrichment/transformation. FTP to an external location.	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)	SOAP inbound with 10KB payload. Download files in a loop. Two files downloaded of sizes 20KB and 70KB, respectively. External invoke to get further data via REST adapter. Returns 100KB data. FTP to an external location.	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)	Simple REST GET request with template parameters without payload. Call to Oracle Fusion Cloud B2C Service to get contact details. Returns a response of 40KB. Return the contact data.	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	Scheduled trigger. Download files in a loop. Three files downloaded of sizes 20KB, 170KB, and 40KB, respectively. Data transformation. External invoke to transfer data which results in 10 bytes of response.	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	Scheduled trigger. Database adapter pulling in 30KB data and 10 rows. Data transformation. External invoke to transfer data which results in 5 bytes of response.	Each invoke/file is considered in multiples of 50KB when response data is more than 50KB. Not counted.	None
Scheduled flow	Scheduled trigger. External SOAP invoke to get data via BIP reports. Returns 130KB data. External invoke to get further data via REST adapter. Returns 10KB data. Data transformation. External invoke to transfer data which results in 5 bytes of response.	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	Scheduled trigger. Download files in a loop. Two files downloaded of sizes 20KB and 40KB, respectively. External invoke to get further data via REST adapter. Returns 100KB data. FTP to an external location.	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	Scheduled trigger. External invoke to get data via REST adapter. Returns 10KB data. Data transformation. External REST invoke to transfer data which results in 500 bytes of response.	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	A parent Integration flow calls a child Integration flow via REST in a loop. The child Integration flow sends a notification email with the information passed from a parent flow. Child flow execution completes.	Integration child flow invoke is waived from metering. Not counted. Note that the parent may count.	#4 (Internal) None counted
Child Integration flow	Parent Integration flow downloads a CSV file via the FTP adapter. The CSV contains 5 rows. Each row in the CSV file calls a child Integration child flow. The child Integration flow reads a orderid passed as an input. Invokes a request to Oracle Fusion Cloud B2C Service to get data about the order. Each invoke returns 70KB data. Data transformation in child flow. Pushes the data via an FTP adapter to write it to a file. Child execution completes.	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.

The requests-per-second calculation helps you determine the approximate number of concurrent requests that your system can receive from client applications. For example, when a mobile application calls Oracle Integration, how many concurrent requests from the mobile app can your instance process?

This calculation is specifically for synchronous integrations, for which Oracle Integration waits for a response from the target service. If you have an integration that completes a large task and needs a long time to run, Oracle recommends creating an asynchronous integration instead.

Note

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.
1. Determine the number of message packs that you purchased per hour for the instance.
  
  For this example, we'll say that you have an Oracle Integration license and purchased 4 packs.
2. Multiply the number of message packs by the number of messages in the message pack (5,000 messages for non-BYOL customers, and 20,000 messages for BYOL customers).
  
  For this example, we'll say that you're a non-BYOL customer, so your message packs contain 5,000 messages.
  
  4 message packs x 5,000 messages per hour = 20,000 requests per hour
3. Divide the number of hourly requests by 3,600 to determine your approximate per-second capacity.
  
  20,000 requests per hour / 3600 = 5.6 requests per second
4. Multiply the per-second requests by 2; an instance can typically handle about twice your purchased capacity.
  
  5.6 requests per second x 2 = 11 requests per second
Calculate your concurrency (the number of concurrent requests your system can handle from client applications).
1. Determine the typical response time in seconds.
  
  For example, run a few requests and check the response times in the activity stream timestamps. See Track the Status of Integration Instances in Using Integrations in Oracle Integration 3.
  
  The response time can vary depending on circumstances. When the volume of transactions increase in your instance, your response times might also increase.
  
  For this example, we'll say that your response time is 5 seconds.
2. Multiply the number of requests you can process per second by the response time.
  
  11 requests per second x 5 seconds = 55 concurrent requests
  
  This value is your approximate concurrency.

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

Use the Cost Estimator Tool to Determine Your Monthly Bill

Oracle provides a cost estimator tool to help you determine your monthly usage and bill for Oracle Integration.

Go to the cost estimator tool.
From the Select category list, choose Integration.
In the Application Integration box, click Load.
Follow the instructions on the page to calculate your costs.
The estimated monthly cost is displayed.

See Estimate Your Monthly Cost.

Oracle Cloud Infrastructure Documentation