Okay. Let's talk about some specific patterns within OIC. So OIC, as you are probably aware,
has three frequently used types of integration and another couple of less commonly used ones.
The three commonly used ones are scheduled orchestrations, synchronous orchestrations, and
asynchronous orchestrations. We also have publish and subscribe options, and we will touch briefly
on those. Let's start off talking about scheduled orchestrations. We get a lot of questions about
concurrency with scheduled orchestrations. First of all, for a given integration type and version,
only one instance of that integration can be active at any one time on a schedule.
This is important when we come to talk about persistent state,
because we only want one instance upgrading that persistent state.
We do, however, allow the same instance to be run on demand.
So you can run the same integration on demand. In that sense,
you can have two instances--one running on a schedule, and one where you say ‘run now.’
in addition to limiting the concurrency of specific integrations, we also limit the
concurrency of all scheduled integrations. This is because, in our experience, most scheduled
integrations are picking up large files, processing hundreds or thousands of records,
and can be very intensive in resources. In order to prevent those scheduled integrations from
stealing resources from other applications, particularly synchronous orchestrations and
to a lesser extent async orchestrations, we limit the concurrency to normally between two and four
concurrently executing scheduled integrations. So if we have more than that that we want to
be executed on the schedule, they will be delayed until resources are available. It's a
variable number because we base it on the actual memory and CPU consumption of the OIC instance.
Okay. So persistent state within a scheduled orchestration: We have a concept called a
schedule variables so schedule states. Schedule variables are used to hold the
state of a scheduled integration. So why would you want to do that? Well, for example, you might only
want to pick up files since the last time you ran. So you could store the last time you ran
in the schedule variable, and then you could do a query saying, “Okay.
List all the files, but only pick the ones that have a date time later than the last time I ran.”
Similarly, if I need to pick up data out of a database um there may be a sequence number, “Hey,
pick up all the transactions greater than this sequence number.” If we write
to a schedule variable inside our scheduled orchestration it is automatically persisted.
So this probably now starts to make sense why we only want to allow one instance of a scheduled
integration to run at a time. And you're probably also wondering what happens if I have something
running on schedule, and something on a ‘run now.’ ‘Run now’ integrations have a separate set of
schedule variables from scheduled integrations. However, we do allow ‘run now’ to pick whether
it's going to use the ‘run now’ schedule variables or whether it's going to use the ‘schedule’
schedule variables. The reason for this is that if perhaps there was an error on a schedule run,
and perhaps the target system was down, you want to re-run it immediately,
you can go in and hit the ‘run now’ and tell it to pick up the state from the last schedule run.
So that's one of the reasons we do that.
Okay, so now let's move on to application-driven orchestration async integrations. There's some
confusion with customers. I’ve seen customers try and use publish/subscribe when all they wanted was
async execution. That is a terrible idea! First of all, it typically means that you're writing
at least two, and usually four, integrations because you'll typically have a sync integration
that accepts the request, perhaps to some basic enrichment before it calls a publish integration.
You then have a subscribe integration you have to write, and then the subscribe integration
will usually call orchestration again to do more complex mappings and multiple invokes. You can
get rid of all that if it's a one-to-one. If all you really want is a fire and forget capability,
if your integration does not give any response in the trigger, then it is automatically
an async app-driven orchestration. In that case, as soon as the request is received,
it is persisted in OIC, and we will send back a 202 response: http 202, which basically says,
“I’ve done nothing with this, but I do have it stored and I will work on it later.”
In other words, it's been accepted. At that point, in the background we are looking for
async work requests and we will pick them up and start executing them.
Because these are async, these are now re-startable. So if an error occurs, we have the
opportunity to restart it, either from the error console or through the API. That that's a big
plus to using an async integration over sync. In addition, it allows us to decouple the source from
the target, so if the target system is down--no problem! We will kill the messages up in OIC,
and then we can resubmit them when the target system is available. In addition,
it allows us to cope with bursts. One customer I was working with carefully crafted an async
integration with them, so that they were decoupled from their source to their target.
What they neglected to tell us is that when they went live with OIC and with Fusion ERP,
they had batched up 500,000 orders--each of which arrived as an individual message in OIC.
Now if we had tried to throw in and they sent submitted those 500 000 orders in a period
of about 40 minutes was what it took for the source system to send it to OIC and OIC to say
accept it If we tried to send that number of messages at that rate to Fusion ERP,
it would have just started thrashing around, and performance would have been terrible.
So what happened is because we limit the concurrency in OIC,
we were effectively also throttling the target system. It actually took Fusion ERP about three
to four hours to process all those orders, as that wasn't what they'd sized the system for.
There was more than a day's worth of orders submitted in 40 minutes.
However, afterwards they discovered that they had lost not a single message. Not
a single order went astray. All the orders were successfully delivered into Fusion ERP,
into warehousing. So no messages were lost, and the key to this was async. We guarantee
persisting the data, and guarantee delivery. If an error occurs, the integration can be
restarted and resubmitted. If the error is perhaps a temporary glitch in the target,
async integrations are really your preferred way of doing guaranteed delivery.
Okay, let's talk about sync integrations. This is where most people start. You know,
the traditional ‘hello world’ --get a few parameters in and put them into a response
and send the response. The way that we know it's a synchronous integration is because the trigger
has a response attached to it. So no response, async. Response, sync. We don't have a timeout on
asynchronous integrations. We do put a limit on the number of steps that may be executed.
Most customers don't even know that that exists but it's really to stop runaway
integrations where perhaps the while loop hasn't been properly terminated and so it
would run forever. So we have a pretty high step count before we will stop an async integration,
and async integration has a five minute timeout. If we don't complete within five minutes,
the load balancer will time out the session and send response error back to the client.
So you will get timeouts if your sync integrations take up to five minutes. So really, synchronous
integrations should be crafted so that they run in a matter of seconds, and certainly
less than a minute should be normal for them. As soon as you start going over a minute,
you've potentially got a problem. Synchronous integrations, also both sync and async and also
the scheduled concurrency, is if you have a large number of message packs you will
expect to see greater concurrency. So. for example, we will allocate additional resources.
If you have more than about six message packs, additional resources get allocated.
If you have a customer that has a very high volume requirement (and we see this, where people are
using integration as a convenient way to pull data from multiple sources) and present a simplified
API for web portals and for mobile applications. In that case, we often also see associated with it
very high volumes. So one customer I worked with will submit up to half a million to a
million messages an hour shortly after they send out a a special offer through their mobile app,
and they get something like a 20 percent response rate. Out of a 5 million person user base,
and so people go in and will take advantage of those special offers.
In order to cope with that kind of volume, it is possible for us at Oracle to scale your OIC
instance beyond the standard 12 message packs or the three BYOL message packs. In order to do that,
you need to raise a service request. The largest customer we have today has 53 message packs for
BYOL, which is a million messages an hour. We have a number of customers scaled out to that kind of
capacity. So if you do have very high volumes, reach out to your Oracle account team and we
will work with you to make sure that you get an OIC instance that scales beyond the normal size.
Testing. When we talk about testing, we have a test button in the Oracle Integration screen.
That's fine for a developer to validate the basic functionality is working
before the integrations are moved into the test environment, but as soon as we move into the test
environment we should be thinking first of all about what the real data will look like.
For example, if we expect orders with 1000 lines, and multiple sub items on those lines, then we
should be testing with that. It seems obvious, but it's surprising the number of customers
that we've seen go live and then have problems when they didn't scale the way they expected to
because they'd made some bad choices in their integration and their testing didn't catch it.
So make sure that you test with realistic sizes and also with realistic loads.