Oracle Integration Cloud (OIC) is a powerful platform for application integration, process automation, and streamlined mobile and web development. It incorporates machine learning recommendations to accelerate every step of designing and delivering integrations.

With all of the capability that OIC delivers, how do you determine how much OIC you need to purchase? How does your usage of the features in OIC influence the rate of consumption? In this blog we will cover:

  • What are the high level components of OIC
  • What is the billing metric for OIC
  • How the billing metric is defined and calculated
  • Scenarios of how the billing metric is consumed for the various components of OIC.

To best understand how the OIC billing metric is consumed, we must first have an awareness of the high level functional capabilities of OIC.

High Level Components of OIC

Oracle Integration Cloud encompasses three main functional capabilities

  • Integration Applications, system to system integration
  • Process Automation, people to people and people to system automation and integration
  • Visual Applications (Oracle Visual Builder), creating web and mobile workflow applications in front of process automation, directly from the browser.

These three components are designed and built to work together seamlessly to integrate your applications with humans and robots, build visual interfaces, and get end-to-end monitoring. The first section of this article focuses on OIC billing with respect to Integration Applications, with later sections covering Process Automation and Visual Applications, as well as inter component communication metric consumption.

OIC Billing Metric

Oracle Cloud utilises a single billing metric per services, which greatly simplifies the estimation and tracking of service consumption, and delivers predictability of expenditure to the business. The metric for OIC is "Messages Per Hour". The messages are sold in increments (or "packs") of 5,000 per hour (or in the case of a "Bring Your Own License" instance, 20,000 Messages Per Hour. For the purposes of this blog we will assume the use of a license included service, and therefore 5,000 messages increments). The minimum purchase of an OIC instance is 1 message pack, that is 5,000 messages per hour.

So how much can you do with the minimum purchase? A minimum purchase will provide you with the ability to process 3,720,000 messages across the month. (24 hours x 31 days x 5000 messages). So, what is defined as a message?

Definition of a Message

The definition of a message for OIC can be found on the OIC pricing page as well the Oracle PaaS and IaaS Universal Credits Service Descriptions document. In part it reads:

A message is defined as up to 50Kb of in-and-out transmission from/to the Oracle Cloud Service. Any message over 50Kb in size must be counted as multiple messages, with each 50Kb or portion thereof counting as equivalent to one message

There are two important parts of the definition above that are worth exploring. The first is "in-and-out transmission from/to the Oracle Cloud Service", and the second is the 50KB message size.

To avoid confusion when using the word "message" with respect to the messages that flow between OIC and participating applications, and the OIC billable metric Message, in this article I will refer to the latter as simply "M" as a unit of measure.

"in-and-out transmission" Messages

OIC only counts an in-bound message to the cloud service as billing message, these include:

  • The initiating request message to a service.
  • The response message into OIC from calls made to other services (over the 50KB limit, see the Message Size section below).

Message Size

An M in OIC is defined as up to 50KB. If an inbound message is greater than 50KB, the number of M consumed is the inbound message size divided by 50KB, and rounded up. For example:

ceiling ( inbound message size / 50KB M limit )

210KB inbound message size / 50KB M limit = 4.2 M

ceiling ( 4.2 Messages ) = 5 M

When the integration makes calls to other services as part of an orchestration or enrichment, the first 50KB of the reply message (that is the message that is entering OIC) is free. If the message is greater 50KB then the following formula applies

floor ( inbound message size / 50KB Message limit )

80KB inbound message size / 50KB message limit = 1.6 M

floor ( 1.6 M ) = 1 M

Message Examples

Example 1

In the example below:

  • The inbound initiating message is counted as 1 M, as the message is less than 50KB.
  • The outbound messages to the other services (green dots) are not counted
  • The reply messages to OIC from the other services (green dots) are not counted as they are less than 50KB
  • The outbound call to the target service (pink dot) is not counted

So the overall consumption of this service invocation is 1 M.

Example 2

In the example below:

  • The inbound initiating message is counted as 5 M, as the message is 230KB. ceiling ( 230KB / 50KB ) = 5
  • The outbound messages to the other services (green dots) are not counted
  • The reply messages to OIC from the other services (green dots) are not counted as they are less than 50KB
  • The outbound call to the target service (pink dot) is not counted

So the overall consumption of this service invocation is 5 M.

Example 3

In the example below:

  • The inbound initiating message is counted as 5 M, as the message is 230KB.   ceiling ( 230KB / 50KB ) = 5 M
  • The outbound messages to the other services (green dots) are not counted
  • The reply messages to OIC from the first other service green dot is counted as 1 M, as it exceeds 50KB.   floor ( 80KB / 50KB ) = 1 M
  • The reply messages to OIC from the second other service green dot is not counted as it is less than 50KB.
  • The outbound call to the target service (pink dot) is not counted

So the overall consumption of this service invocation is 6 M.

Scheduled Execution / File Polling

In scenarios where you have scheduled the integration to run at a certain interval, for example to poll for a file, only the instances that detect and process the file will consume OIC M for billing purposes. All of the intervals where no file is found do not consume M. The standard 50KB message size is also applied to files with respect to the consumption of M.

For scheduled integrations that do not poll for a file, and do not take an input message as such, they consume 1 M per scheduled instance, irrespective of the absence of an input payload.

Process Automation and Visual Builder Message Consumption

The consumption of M as a metric for the Integration Applications of OIC is a natural fit, however how are M used when employing the Process Automation and Visual Builder capabilities of OIC? As these two components have a more human facing element to them, Oracle draw a correlation between a distinct concurrent user for each of these applications to a set number of messages.

For Process Automation 1 concurrent user hour equates to 400 M.

For Visual Builder 1 concurrent user hour equates to 100 M.

So how does this work? If a user uses the Visual Builder component, 100 M are consumed. As the user is defined as a concurrent user hour, they could start using it for 10 minutes, let the session expire, come back in 15 minutes and interact with it again for another 20 minutes, and all of this would be counted within the same user hour, and only consume 100 M. The same is true for Process Automation, with the key difference of consuming 400 M.

Assuming that you have purchased 1 message pack, providing 5,000 M (messages) per hour, one person using Visual Builder and another person using Process Automation would consume 500 M of the 5,000 M for that hour. (100 M for Visual Builder, and 400 M for Process Automation)

What About Inter-Component Messages?

So far the scenarios we have looked at cover the consumption of OIC messages for the "Integration Applications", but what happens if our Process Automation flow calls an integration, or if we launch Process Automation flow from our Visual Application, or indeed if our Visual Application calls an Integration Application? The good news is that the M are only consumed at the inbound point for OIC (e.g. 100 M for Visual Builder, 400 M for Process, and 1 M for Integration Applications). Inter component calls and invocations do not consume M, with exception of where the message size exceed 50KB.

In the following example a Process Automation flow calls two Integration Applications, each of which makes a call to an external service / system before updating another cloud application. As the entry point of the system was from Process Automation and all of the messages sizes are within the 50KB message size, this interaction only consumes 400 M, as per the distinct user hour of the Process Automation user. This user could initiate 1 of these processes, or multiple instances of this process within their user hour and still only 400 M in total would be consumed.

Conclusion

Oracle Integration Cloud's use of a single metric per cloud service greatly simplifies estimating and tracking the cost of the integration platform, and allows for predictable expenditure. Purchased in increments of 5,000 Messages Per Hour, the Oracle Integration Cloud delivers comprehensive breadth of functionality across integration, orchestration, process automation, and low code visual applications at a very competitive price. The pricing model delivers a balanced approach to providing significant message processing power and the draw down of M (billable messages) by not charging for any out bound messages, and only charging for inter-component and inbound reply messages greater the 50KB. This approach helps circumvent "architecture to evade cost" and implementing anti-patterns to avoid being charged. You can achieve a great deal of processing with the 3,720,000 M (messages) across the month.

The ability to mix and match the use of M within your purchased Message Per Hour between Integration Applications, Process Automation, and Visual Builder gives great flexibility to design and utilise the full power and potential of the platform.