Okay. So what we'll talk about this morning is some patterns and anti-patterns, and some
best practices thrown in along the way. The basic focus for OIC was we built it to be in the sweet
spot for cloud to cloud integration--typically, SaaS to Saas applications (Perhaps Salesforce to
ServiceNow, for example). So, for this there is no additional infrastructure required beyond what OIC
provides. OIC is always made available on a public IP address, and it always talks to public IP
addresses on the target side. With that in mind, let's look at some patterns that extend this.
The first one is on-prem integration. In order to access on-prem systems, or those could be systems
in another cloud such as AWS, or they could be virtual compute networks in OCI. They could be
in Azure. They could be in Google cloud, or Ali cloud. Whatever the case, if they're on a private
network they will have private non-routable IP addresses. In order to access those systems,
we use the Connectivity Agent. We'll talk more about the Connectivity Agent later,
but the Connectivity Agent allows us to install a small (140 mb download) piece of software.
It connects back to Oracle Integration cloud using https, so standard punch through a corporate
firewall. If you can browse the internet from your corporate network, then the Connectivity Agent
will work. The Connectivity Agent asks Integration Cloud, "Have you got work for me?" If it does,
then it will pick up the request and then send it either directly to the target application,
or you might want to take advantage of existing on-premise integrations, either in SOA suite,
or in another tool such as Mulesoft, and call those directly instead.
Now, if you're using SOA suite, we have some optimizations
that enable you to browse all the available SOA suite integrations from the cloud. And similarly,
from within JDeveloper we can browse all the OIC integrations. So the key thing about this is that
we can access private network endpoints, but we have to do it through the Connectivity Agent.
Now, if the application on the private network needs to call back into Oracle Integration,
there are two different possible routes that it can go. If the application is making REST or SOAP
calls, or it's e-business suite or Siebel, then in that case the the calls will go
directly from the application through the firewall into OIC. The agent is only involved for EBS and
Siebel in actually setting up the callbacks. So when you activate an integration that uses
an EBS trigger, then at activation time the Connectivity Agent says, "Oh. I see that
an EBS trigger is being activated." It connects to EBS, and then it configures EBS to have a trigger
that will fire, and it sets the target for that trigger to be OIC directly. So once that is done,
during operations the calls go directly from app to OIC. So if you have a network
where you allow list applications to access the internet, then in that case your EBS instance or
Siebel instance, or other applications that use REST or SOAP would need to be 'allow' listed.
Usually, that's not the case. Usually, as long as they use the right proxy,
they can go through the firewall. But there are some companies that have an additional
'allow' listing. However, if you're trying to have a trigger based on Oracle AQ, or reading a file,
or querying a database, when records appear in the database or messages on the queue or SAP,
those callbacks, those triggers, all go through the Connectivity Agent because all of those paths
are not using standard https protocols. They're using sqlnet, or they're using something else.
So just to be aware--bottom line--applications using https go straight to OIC,
even if in a private network. Other protocols have to go through Connectivity Agent.
In this brave new cloud world, we all thought that files were such an old technology that nobody
would want them, but the reality is, of course, that files are still a huge part of integration.
So here we show a couple of different file patterns. One pattern is that we can use
MFT within SOA cloud service, either provisioned as SOACS, or provisioned using marketplace. We can
use that MFT server so that a source app can push a file into the MFT server and then
we can pick it up. It can push it into Oracle Integration cloud using MFT. A new capability
that we released about six or eight weeks ago is an embedded file server in OIC. So this is
part of OIC. It's an option for those of you that have Gen 2 instances. You can check to enable it.
This enables you to set up an sftp server very quickly, very easily, and gives you
folder level access control, so that multiple customers can be pushing data into the same
file server, but they would each have their own unique credentials, their own unique certificates.
They would not be able to see other clients' files and addresses. Then,
from within Oracle Integration, we would use the sftp adapter running on a schedule (that's what
the little clock in the corner is), running on a schedule to pick up those files and process them.
Another common pattern we see is that often applications are lifted and shifted from
on-prem into a cloud infrastructure. This is basically re-platforming the application.
If that's the case, and if the you already have SOA suite being used on-premise,
it might make sense for your customers to take advantage of SOA suite in the cloud, provisioned
via marketplace. They can continue to run their existing integrations and still talk to their
applications that have been re-platformed. If these are newer type integrations,
then we can connect directly. Or more likely, through the Connectivity Agent.
One of the key features we have is the Process capabilities in Oracle Integration Cloud. One of
the key extension capabilities we take advantage of is to embed the Process forms from Oracle
Integration process into SaaS applications. This is an important pattern, because it means that,
for example, a salesman can access extensions to his Salesforce or Engagement cloud application
without ever leaving the screens he's familiar with. He just sees some new screens which are
actually embedded Process forms. These Process forms will kick off processes in
Oracle Integration. The forms themselves can be using Oracle Integration to retrieve data
from the application they're embedded in, so that you really get a very seamless experience.
Then, if you have a user using a different application but part of the same process, again,
those same forms could be embedded. For example, in a financials application like Fusion ERP,
so that again the accounting person doesn't have to go into another tool. So very powerful.
We can then, if necessary, access on-premise systems as well,
and we can even embed the forms in on-premise systems if we need to.
One one key point that i should have made about this is that when we're extending our
applications, we generally do not want to create a separate database with application data in it.
We generally want to use integration to pull and push data into our existing systems of
record. We don't want to create new systems of record. It's a very important point from
an architectural perspective--keep the data with who owns it. Don't create new databases.
It's also possible for us to kick off whole business processes from within Oracle Integration.
We can use the process capability to create a much longer running integration, that perhaps involves
human approvals. So the ability to kick that off from Oracle Integration makes it very simple
to access from SaaS applications. Similar to the way that we talked about extending Process forms,
we can do the same with Visual Builder as well. And we can embed Visual Builder forms and screens
into existing applications. So this gives us the option to either extend the SaaS user experience,
or to create our own custom apps. A common use case we often see is to use Visual Builder
to create a mobile application for particular functions that aren't mobile-enabled in
an application. Visual Builder can then take advantage of adapters in Oracle Integration to
to update or retrieve data from the SaaS applications.
And of course, within the Oracle ecosystem, we have a large number of other services running
in OCI that we can take advantage of from within Oracle Integration cloud. We particularly will
notice in the REST adapter. We support the standard OCI signatures alongside with AWS
signatures, so we can take advantage of all the OCI native applications, including blockchain,
Oracle Digital Assistants, as well as calling out into container native applications.