Welcome.

Let's get this training started with an overview of the complete Oracle
Integration Cloud environment. OIC 3 includes several features. You can design i
ntegrations to monitor and manage connections between your applications, sele
cting from a portfolio of pre-built adapters and recipes to connect with both Oracl
e and third-party applications.
You can also create process applications to automate and manage your business
workflows, whether they be structured or dynamic processes. The Visual Builder f
eature is an integrated development environment that allows you to create and
deploy custom web and mobile applications. You can store and retrieve files in O
racle Integration using the embedded secure FTP compliant file server. And
this feature allows you to use B2B e-commerce to extend integrations to reach tr
ading partners.
Of course, since the predominant OIC feature is integrations, that is indeed the p
rimary scope of this learning path. But you will also see some videos and demos
that include the file server and show using the B2B feature with integrations, as
well. However, since both Visual Builder and process automation have their
own separate Oracle university training courses, those two features will not be p
art of this learning path, nor will they be on any application integration certificati
on exam. All exam questions will focus on the integrations feature.
However, since this is an overview lesson for all of OIC, we'll briefly talk about ea
ch of these, starting with Process Automation. Now, to use this feature, it must
first be enabled after the OIC instance has been provisioned because, as you can
see, it is not enabled by default. Now, once enabled, it appears in the OIC Servic
e Console menu as process, and when a developer clicks the link, it will take the
m to this new web page where they can now get started on their first process ap
plication.
Low code means that developers and business experts can collaborate t
o create processes using a simple visual interface. You drag and drop fr
om a visual palette to include pre-built integrations, decision services a
nd human task configurations. This is an extensive product on its own w
here you can design and adapt workflows efficiently with visual process
modeling tools, primarily focusing on humancentric business processes.
Another capability is to automate decision-making with customizable bu
siness rules and logic. And although humancentric integration is the foc
us, you can also seamlessly integrate with external systems for data ex
change and collaboration. To streamline data capture and input, you ca
n create user-friendly web forms, and it's important to be able to track
tasks, assignments and approvals in real time for enhanced efficiency a
nd accountability.
Process automation development and runtime management environmen
ts enable you to perform iterative process automation development usi
ng Designer to create applications and their components and workspac
e to test, run, monitor, and administer applications.
Next, the Visual Builder feature is also an extra app that must first be e
nabled. Then when you click on this link in the OIC Service Console men
u, it launches the Visual Builder web app, where you can now start buil
ding web or mobile applications without any additional setup. When yo
u click to create a new application, it opens on the Welcome page. And t
he Designer that
is shown here is what you see is what you get page Designer where you
drag and drop UI components and visually create your pages.
A Visual Builder provides simple but powerful visual development tools that help
you quickly design your app with UI components and customizing their attributes
to define behavior. Now, while these tools lend themselves to low code develope
rs, experienced developers can just as easily access the underlying source code,
even extend it using standard HTML5, JavaScript, and CSS techniques for more c
omplex needs.
You access your app's data through REST based services where you create reusa
ble business objects to implement application logic and store data, which can the
n be managed through REST endpoints that Visual Builder generates for you. Or,
you can pick data objects exposed by Oracle SaaS applications or OIC integration
s in an integrated catalog of REST services. You can also access data from any e
xternal REST service with just a few clicks.
This is a complete development tool, as well as a hosting platform, which means
you can manage your applications life cycle right from development to test and fi
nal publishing, where version management and data migration are built into the
app's life cycle, making it easier for you to stage and publish your app and mana
ge its data in every phase.
An administrator must enable file server before an organization can start using it
with their OIC instance and enabling it is a one time action in the OCI console. Th
en, back in the Oracle Integration service console, administrators can navigate to
the Settings page to monitor the overall health of file server and to change its m
ain settings if needed.
Developers can then design integrations that process files in the embedded file s
erver, where you have two options for connecting to it from an integration flow. T
he FTP adapter and the file server action. This OIC feature eliminates the cost an
d operational expenses associated with hosting and maintaining a separate secu
re FTP server either in the Cloud or on-premises. You can also give your vendors
or partners access to your OIC instance file server, where they can upload or dow
nload files using their secure FTP client software.
B2B for Oracle Integration provides support for business-to-business e-
commerce, allowing you to communicate with trading partners by sending and re
ceiving data from your integration flows. Now, from this menu, in addition to con
figuring the host profile for your organization, you can define one or more trading
partners along with all the schemas and document types you'll be exchanging, s
uch as purchase orders or product specifications using standard EDI formats.
B2B represents a collective set of features inside OIC to support processing to inc
lude a trading partner management interface, a schema and document editor for
customization, a specialized B2B tracking user interface for viewing messages ex
change with trading partners and adapters to support B2B protocols such as AS2,
RosettaNet, and FTP, of course, and actions you configure within your integration
s for EDI processing.
Integrations deal with live operational data, which can be processed either in real
time or in batch, and used to facilitate communication between two or more appl
ications, events or other external APIs. OIC includes dozens of pre-built adapters
that make it easy for your integrations to connect to a wide variety of application
s or databases and other external systems, which allows you to bring data and a
pplications together across both Oracle and third-party Cloud applications, as wel
l as applications hosted on-premises.
So developers access the integrations feature components from the Design men
u, as shown here, or they can create a new project to organize the building, depl
oying, and monitoring of one or more related integrations. However, instead of st
arting from scratch, they can also take advantage of preassembled integration s
olutions known as pre-built integrations. A recipe or accelerator contains all the r
esources required for a specific integration scenario, and there is a huge collectio
n of these in the integration store.
Oracle Integration is available in two editions, Standard and Enterprise. Now, eith
er edition gives you the power to integrate your SaaS and on-premise application
s using integrations, as well as the embedded file server. Developers can also cr
eate custom web or mobile applications using Visual Builder. However, the Enter
prise Edition provides additional capabilities, including enterprise adapters, as w
ell as the B2B feature. This edition also provides process automation, allowing yo
u to create humancentric business workflows.
And that brings us to the end of this overview lesson on OIC. However, among th
e huge number of upcoming video lessons and demos in this course, we have a l
ot more to learn about OIC and integrations. Thanks for watching.

2nd video: Integrations Feature Overview

Welcome back. In this lesson, we'll overview OIC's integrations feature. But befor
e we explore the various components and use cases, now is a good time to revie
w some terminology, specifically with words that have more than just one meani
ng, such as instance and integration.
First of all, there is Oracle Cloud's platform as a service, which is called Oracle Int
egration Cloud, or OIC. And as we discussed in the previous lesson, while OIC incl
udes a number of different components and capabilities, we explicitly identify fiv
e distinct features or products-- file server, B2B, Process Automation, Visual Build
er, and the Integrations feature, which, of course, is the main scope of this certifi
cation training learning path. As we'll explore further in just a bit, this huge featu
re or product contains a number of components and capabilities, which allow for
the creation of integrations.
However, before someone can start using any of those features to include Integr
ations, an OIC environment needs to be provisioned, which is also referred to as
an OIC instance. Within the scope of an OCI region identified within a compartme
nt, this single OIC instance provides the design, time and runtime managed infra
structure that allows you to create Visual Builder applications, Process Applicatio
ns, and of course, one or more Integrations. Essentially, an integration is a servic
e that you define and configure and then deploy within your OIC instance.
And finally, after integration is activated, it can then be triggered numerous time
s, perhaps even invoked by multiple concurrent clients. Once that happens, each
time it is triggered, a new integration instance is spawned, which runs separately
and is identified uniquely with its metadata persisted, so it can be tracked later o
n. So with those definitions, better understood, let's dive into this integrations fe
ature overview.
In the OIC console, this feature is always exposed. You just click on Design to acc
ess all of the individual components, starting with the key component, integratio
ns. As we now understand, an integration is the service you create and deploy to
handle a particular integration use case, or perhaps a service used to facilitate s
ome other business requirement, or to provide a layer of abstraction to other ser
vices or applications. Essentially, integrations are the main component of the OIC
integrations feature, and there are many more lessons later on where we'll learn
how to design and build these services.
However, creating integrations require other components, starting with adapters.
There are over 80 of these pre-installed in your OIC environment. These include
Oracle Cloud, SaaS applications, third party cloud SaaS applications, on-premises
enterprise apps, social and productivity applications, and other generic technolo
gy adapters for databases, FTP and file servers, REST and SOAP.
This graphic illustrates the various categories and icons representing 55 of these
adapters. Essentially, you'll be leveraging one or more of these when designing y
our integrations, which is handled with the configuration of connections. A conne
ction is the component you'll define based on one of the adapters, which will incl
ude connectivity and security properties. In addition, you'll leverage that Adapter
s Configuration wizard when configuring the connection for a particular use case
within your integration. Some connections, however, will require a component ca
lled a connectivity agent. This will be necessary if the external service or applicat
ion is located in a private network or on premises or in a private cloud network.
Once deployed, these components interact with Oracle Integration Cloud to facili
tate that connectivity.
To further simplify data mapping within integrations, a lookup associates values
used by one application for a specific field with the values used by other applicati
ons for a similar field. These are commonly referred to as domain value maps. W
ell, this capability enables you to map values across various vocabularies or syst
ems. For example, you could create a lookup that maps country codes, city code
s, currency codes or any other type of common data between different systems.
Once defined, these lookups work much like a database table, except that the ru
ntime lookup function pulls the data values directly from internal memory.
In addition to a host of built-in XSLT functions you can use to assist with your dat
a transformations, OIC also allows you to create one or more custom functions w
ritten in JavaScript and then register them as a JavaScript library. Once libraries a
re added to your OIC environment, you can leverage these new custom functions
within the data mapper tool inside your integration, just as you would those built-
in functions.
While most of the time your integrations will be triggered by an external applicati
on or invoked explicitly by a client, another option is to create a local integration
service that is triggered with an event published by another integration. An even
t is defined with a unique name and includes a JSON object, which now can be us
ed for event subscriptions and also published from any other integration. These i
nternal OIC events support a publish subscribe pattern for the decoupling of cert
ain integrations.
And finally, you can group one or more integrations into a package which greatly
simplifies those use cases where you need to export and import a group of integr
ations that are related to one another because it also contains the integrations d
ependencies such as connections, lookups, libraries, and events. And so to wrap
up this overview, integrations are the key component of the OIC integrations feat
ure. And while other required or optional components used to complete the impl
ementation of an integration solution are also there. Thanks for watching.

Oic features
As you've now learned, central to Oracle Integration Cloud is the integrations fea
ture. In this lesson, we'll look at the three integration pattern options and provide
a high-level list of various use case categories.
When you start to create a new integration, you'll have the option to choose one
of three patterns from the Create Integration Panel wizard application, schedule,
or the event pattern. The difference between these three involves how the integr
ation will be triggered. To trigger an application integration, you can define a RE
ST or SOAP-based interface that is designed to be called by some client applicati
on. From there, your integration can invoke one or more external applications. Or
this pattern also provides an option to leverage certain Oracle Fusion application
adapters to subscribe to specific business events to trigger the integration.
For example, you could ensure that an Oracle Service Cloud application is update
d with information based on data sent from an application pattern integration tha
t was triggered with an event subscription to the adapter for the Oracle CX Sales
and B2B Cloud Service. The schedule pattern allows you to define a time-based s
chedule to trigger the integration instead of an adapter. For example, you could
add an initial invoke to an FTP server to read a trigger file and then a second call
to download the file for further processing downstream. After designing this integ
ration, you simply schedule when and how often to run it.
Finally, the event pattern allows you to decouple integration logic by having your
integration subscribed to an event. So now your subscribe integration will be trig
gered when that event is published by some other local OIC integration. You sim
ply define these events in advance in JSON formatted files. For example, you coul
d create an event pattern integration that subscribes to customer added events
published by other integrations. Once this event is received, the integration coul
d be responsible for other tasks, such as database updates, notifications, or send
ing data to other downstream applications.
With that understanding of integration triggering patterns, we'll now take a look
at some common types of use case scenarios, along with a high level example of
each one. Probably the most common type of use case is application-to-
application integrations. For example, consider the need to synchronize sales ord
ers from a third party SaaS application, such as Salesforce, with your company's
system of record maintained in your Oracle ERP Cloud application.
By utilizing OIC connectors, you can seamlessly sync the sales orders, ensuring e
fficient data flow. This not only simplifies the process, but it also ensures that ev
ery sales order is accurately reflected in both systems bridging the gap between
sales and financial operations. In the implementation, you determine the data m
apping, transformation requirements, and any business logic that needs to be ap
plied during the flow of the integration instance.
With OIC, certain business workflows can be further automated. For example, cle
arly the HR onboarding process is important to a new employee success. Well, yo
u can automate workflows between applicant tracking systems and onboarding t
ools so that when an applicant status changes to hired, the system could automa
tically initiate the onboarding process. In the implementation, workflow automati
on might require some additional conditional checks so that only a status change
to hired would then initiate the onboarding process in the target system.
Next, consider real-time data synchronization use cases, such as ensuring that e
very product sold is accurately reflected in the inventory by providing synchroniz
ation between e-commerce platforms and inventory management systems. If no
specific built-in OIC adapters were available, the implementation for the integrati
on might include webhooks or polling mechanisms, depending on the capabilities
of the system involved. You'd also need to ensure that error handling logic is incl
uded for inventory mismatches or sync failures.
Of course, there are many use cases that involve extending the capabilities of ex
isting applications. In this example, as the ecommerce world expands, so does th
e need for diverse payment options. You could then extend the e-commerce appl
ication to integrate even unsupported third party payment gateways, leveraging
OIC's capability for creating custom adapters if pre-built adapter connections are
n't available. Legacy systems hold vast amounts of invaluable data. And using OI
C, businesses can bridge the gap between vintage mainframes and modern clou
d-based mobile applications. If the legacy system doesn't provide standard APIs,
once again, we can create custom adapters or use other middleware solutions. O
IC can then be used to format and forward the data to the cloud application.
Customer support is more than just answering queries, it's about trying to provid
e a unified experience. OIC enables you to integrate separate systems for email,
chat, and phone support, resulting ultimately in a single ticket system that aggre
gates communication history, ensuring that no customer query goes unnoticed o
r unresolved. Your implementation would need to ensure data consistency and a
void data duplication. For example, if a ticket raised on email and then later was
updated via chat, the unified system should reflect a single ticket with a merged
communication history.
Transitioning to the cloud doesn't mean leaving your data behind. For example, b
usinesses can migrate data from on-premises customer resource management s
ystems to cloud-based platforms. For the implementation, you'll need to consider
data validation, transformation, and deduplication. You can also leverage oasis b
atch processing capabilities for large data volumes.
And the world of IoT, or Internet of Things, is vast and consistently evolving. So u
se cases of this type are really continuing to grow. As an example, OIC can be us
ed to integrate machinery IoT devices with central monitoring systems by handli
ng the high volume of real-time data streaming from these devices. Businesses,
of course, can gain improved insights into their operations for real-time analytics
or alerts.
Now, since the actual number of integration use cases is limitless, we'll stop here
for now. Suffice it to say that the integrations feature of OIC empowers organizati
ons to connect applications, automate and enhance workflows, synchronize data,
and modernize legacy systems or applications. That's it for this lesson. Thanks fo
r watching.
OIC use cases
As you've now learned, central to Oracle Integration Cloud is the integrations fea
ture. In this lesson, we'll look at the three integration pattern options and provide
a high-level list of various use case categories.
When you start to create a new integration, you'll have the option to choose one
of three patterns from the Create Integration Panel wizard application, schedule,
or the event pattern. The difference between these three involves how the integr
ation will be triggered. To trigger an application integration, you can define a RE
ST or SOAP-based interface that is designed to be called by some client applicati
on. From there, your integration can invoke one or more external applications. Or
this pattern also provides an option to leverage certain Oracle Fusion application
adapters to subscribe to specific business events to trigger the integration.
For example, you could ensure that an Oracle Service Cloud application is update
d with information based on data sent from an application pattern integration tha
t was triggered with an event subscription to the adapter for the Oracle CX Sales
and B2B Cloud Service. The schedule pattern allows you to define a time-based s
chedule to trigger the integration instead of an adapter. For example, you could
add an initial invoke to an FTP server to read a trigger file and then a second call
to download the file for further processing downstream. After designing this integ
ration, you simply schedule when and how often to run it.
Finally, the event pattern allows you to decouple integration logic by having your
integration subscribed to an event. So now your subscribe integration will be trig
gered when that event is published by some other local OIC integration. You sim
ply define these events in advance in JSON formatted files. For example, you coul
d create an event pattern integration that subscribes to customer added events
published by other integrations. Once this event is received, the integration coul
d be responsible for other tasks, such as database updates, notifications, or send
ing data to other downstream applications.
With that understanding of integration triggering patterns, we'll now take a look
at some common types of use case scenarios, along with a high level example of
each one. Probably the most common type of use case is application-to-
application integrations. For example, consider the need to synchronize sales ord
ers from a third party SaaS application, such as Salesforce, with your company's
system of record maintained in your Oracle ERP Cloud application.
By utilizing OIC connectors, you can seamlessly sync the sales orders, ensuring e
fficient data flow. This not only simplifies the process, but it also ensures that ev
ery sales order is accurately reflected in both systems bridging the gap between
sales and financial operations. In the implementation, you determine the data m
apping, transformation requirements, and any business logic that needs to be ap
plied during the flow of the integration instance.
With OIC, certain business workflows can be further automated. For example, cle
arly the HR onboarding process is important to a new employee success. Well, yo
u can automate workflows between applicant tracking systems and onboarding t
ools so that when an applicant status changes to hired, the system could automa
tically initiate the onboarding process. In the implementation, workflow automati
on might require some additional conditional checks so that only a status change
to hired would then initiate the onboarding process in the target system.
Next, consider real-time data synchronization use cases, such as ensuring that e
very product sold is accurately reflected in the inventory by providing synchroniz
ation between e-commerce platforms and inventory management systems. If no
specific built-in OIC adapters were available, the implementation for the integrati
on might include webhooks or polling mechanisms, depending on the capabilities
of the system involved. You'd also need to ensure that error handling logic is incl
uded for inventory mismatches or sync failures.
Of course, there are many use cases that involve extending the capabilities of ex
isting applications. In this example, as the ecommerce world expands, so does th
e need for diverse payment options. You could then extend the e-commerce appl
ication to integrate even unsupported third party payment gateways, leveraging
OIC's capability for creating custom adapters if pre-built adapter connections are
n't available. Legacy systems hold vast amounts of invaluable data. And using OI
C, businesses can bridge the gap between vintage mainframes and modern clou
d-based mobile applications. If the legacy system doesn't provide standard APIs,
once again, we can create custom adapters or use other middleware solutions. O
IC can then be used to format and forward the data to the cloud application.
Customer support is more than just answering queries, it's about trying to provid
e a unified experience. OIC enables you to integrate separate systems for email,
chat, and phone support, resulting ultimately in a single ticket system that aggre
gates communication history, ensuring that no customer query goes unnoticed o
r unresolved. Your implementation would need to ensure data consistency and a
void data duplication. For example, if a ticket raised on email and then later was
updated via chat, the unified system should reflect a single ticket with a merged
communication history.
Transitioning to the cloud doesn't mean leaving your data behind. For example, b
usinesses can migrate data from on-premises customer resource management s
ystems to cloud-based platforms. For the implementation, you'll need to consider
data validation, transformation, and deduplication. You can also leverage oasis b
atch processing capabilities for large data volumes.
And the world of IoT, or Internet of Things, is vast and consistently evolving. So u
se cases of this type are really continuing to grow. As an example, OIC can be us
ed to integrate machinery IoT devices with central monitoring systems by handli
ng the high volume of real-time data streaming from these devices. Businesses,
of course, can gain improved insights into their operations for real-time analytics
or alerts.
Now, since the actual number of integration use cases is limitless, we'll stop here
for now. Suffice it to say that the integrations feature of OIC empowers organizati
ons to connect applications, automate and enhance workflows, synchronize data,
and modernize legacy systems or applications. That's it for this lesson. Thanks fo
r watching.
Elements of an Integration
[AUDIO LOGO]
Welcome back. When we talk about OIC integrations, we use a lot of different ter
ms. Let's take a look at a few of them. First, when it comes to building an integra
tion, we're creating a service that provides a connection between two or more ap
plications and often moving data between them. In a simple integration that pass
es data from application A to application B, we represent the source system and
the destination or target system.
We use the word source to refer to the application the data comes from and dest
ination to refer to the application that receives the data. These are the endpoints
of our integration, whether the applications they represent are on-premise or in t
he cloud. Between the source and destination endpoints, we take action to transf
orm the incoming data into a format that's compatible with the destination syste
m. That action is called data mapping or just mapping. That would suggest just c
opying incoming data fields to outgoing data fields. And a lot of times, that's exa
ctly what we do. But there's more to mapping than just copying.
We can also reformat incoming values to suit the needs of the destination syste
m. We can ignore incoming fields we don't need, and we can also insert other val
ues that the destination system needs that aren't necessarily available in the inc
oming message. Sometimes we use other terms when we talk about source and
destination endpoints. The source is also called a trigger, and the destination is s
ometimes called an invoke. These terms refer to the roles the endpoints play wh
en the integration runs. It might be useful to think about the source endpoint trig
gering all of the subsequent actions we've defined in our integration. Likewise, it
might be helpful to think about the integration calling or invoking interaction with
the destination application.
And depending on the design pattern of our integration, we might have other co
mbinations of elements. But we still use the same terms. A larger, more complex
integration might interact with multiple applications. These interactions might pa
ss data to an external system or receive data from it, or perhaps both. But in any
case, each of the additional interactions is also called an invoke. And for each of
those invokes, we're also going to use an additional mapping.
As we'll learn later on, there's a lot of other actions we can take between invocati
ons, but we'll save those for later lessons. So in the meantime, you should under
stand these basic terms-- source, destination, endpoint, data mapping, trigger, a
nd invoke, as they'll be used rather extensively throughout our training.
Understanding OIC Service Roles
Welcome. In this lesson, you'll learn about the predefined roles that govern acces
s to Oracle Integration Cloud. Once the OIC instance has been provisioned, in ord
er for anyone to access that environment, first, identity and access management
users will need to be added to that OCI tenancy's identity domain by an OCI secu
rity administrator. And once that's done, users will need to be assigned to one or
more of these seven service roles, service viewer, invoker, user, monitor, develo
per, or administrator, depending on what tasks that they will need to do.
Most will need to have some level of access to the OIC Service Console as well as
the OIC REST APIs, but also perhaps the permission to invoke integration instanc
es at runtime that are exposed with SOAP or REST APIs. Let's now break down th
ese roles a bit further.
A user with the service viewer role can navigate to all integration resource pages
, for example, integrations, connections, lookups, and libraries, but only can view
those details. They'll also have limited access to read-only APIs. Essentially, the c
onsole and REST API permissions go hand-in-hand. Also, this user cannot navigat
e to the administrative setting pages in the console nor invoke any administrativ
e APIs. In addition, their credentials cannot invoke any integrations at runtime.
By contrast, the service invoker role user cannot access the OIC console at all, no
r can they invoke any of the documented Oracle Integration REST APIs. Instead, t
heir credentials provide the permission to invoke any integration flow that is exp
osed through SOAP or REST APIs or to trigger a scheduled integration run. The se
rvice user role is similar to the service viewer, in that they have view-only access
to the OAC console and REST APIs. The difference is that they can also run integr
ations. So in effect, the service user combines the privileges of both the viewer a
nd the invoker.
Interestingly, a user with the service monitor role cannot access or view any desi
gn time information. However, they can monitor everything provisioned in an OIC
instance from a runtime perspective. So, for example, they can view instances a
nd metrics, find out response times, and track whether instance creation complet
ed successfully or failed. Essentially, they can access all of the observability infor
mation available in the monitoring dashboard or via the related REST APIs.
In addition, of course, they are also not allowed to invoke any integrations. The p
urpose of this role is for users with limited knowledge of OIC integration, design a
nd implementation but have a high level of knowledge of monitoring it. Of course
, this user role does not grant permissions to change anything. A user with the se
rvice developer role can create, delete, edit, and develop any of the resources as
sociated with creating, activating, monitoring, and troubleshooting integrations.
And since you need to be able to test, these credentials can also be used for runt
ime access to invoke integrations as well.
However, this user cannot navigate to the administrative settings pages in the co
nsole, nor invoke any administrative APIs. For those of you that choose to access
the on-demand lab environment, this is the role you will be assigned in order to b
e able to perform all of the hands-on lab exercises. And finally, a user with the se
rvice administrator role is essentially a superuser who can not only manage and
administer everything using the OIC Service Console or REST apis, but they also
can develop and test integrations themselves since they have full developer acce
ss as well.
And so to review, users can be assigned to one or more of these predefined roles
depending on the task they will need to perform in your OIC environment. Norma
lly, you'll need to be assigned to the service developer role if you're going to be c
reating or editing any integrations in OIC.

Projects
Welcome. In this video, we'll learn about the benefits of using projects for integra
tions as opposed to creating standalone integrations and other components, suc
h as connections, as global resources within the OIC environment.
A project provides a single unified workspace for you and your team to design, m
anage and monitor integrations. Essentially, working within a project helps you g
et started quickly because you build all the components that an integration need
s within the project. You don't need to click all over the user interface to find the
right page, to create a new connection, or a lookup, or a JavaScript library. It's all
right there within your project, including the ability to monitor your integration in
stances.
And after you've built an integration or two within a project, creating additional i
ntegrations is even faster and easier because the connections, JavaScript librarie
s and lookups from other existing integrations are already accessible for you. Just
grab what you need from the streamline user interface and continue to build add
itional solutions.
Another feature of projects includes the ability to define project deployments, wh
ere you can easily move integrations to other environments, such as testing or p
roduction. A project deployment represents a list of one or more specific integrati
on and their versions that must be in the environment you're exporting to, which
then makes it easier for release management. Accelerators provide pre-built inte
grations from Oracle or third-party integrators that you can easily customize.
And now that the project feature has been added to OIC, all of the newly develop
ed accelerators will be available for now on to install from the integration store a
s a project that contains one or more version deployments. And to customize wit
hin the project, you simply add an extension group to the flow of the pre-built int
egration.
And finally, with projects, you can restrict the users and groups who are allowed
to edit, view and monitor your integrations using role-based access control. In fa
ct, designing integrations within a project is really the only way to control develo
pment time access at this fine grained level.
To add a new project into your OIC environment from the main navigation pane, j
ust click to open the Projects page and click Add. You can either import an existi
ng project that already contains integrations and all of their assets that were pre
viously exported from another system and saved, or you can create a new empty
project. You can use any name, but the project identifier must be unique in this e
nvironment.
Optionally, you can add some keywords as tags to allow others to help search for
your project. Also notice that by default, the project will be private to only you, u
nless you choose to make it public to everyone. However, whether your project s
tarts off as public or private, you can then later modify project sharing options at
any time. Just click the Share Edit icon shown here. You can specify the users an
d groups that can edit, view or monitor integrations within the project using role-
based access control and even change or add project owners.
Once you click the Share button, your project page will be updated to reflect thos
e permissions, as shown here. While project permissions are similar to the OIC se
rvice roles such as service developer or service monitor, project permissions are
essentially a layer of permissions on top of those service roles. Therefore, project
access is restricted based on a user's OIC service role plus their project permissio
ns.
So in this example, even though Samvit has edit permissions in this project, if he
only had OIC service monitor permissions, he would only be able to monitor. Like
wise, even if OIC learners 1 and 2 were assigned the OIC service developer role, t
hey still could only monitor in this project.
Once a project is open, there are three sections-- Design, Deploy and Observe. It
is here on the Design page where you create and access your integrations and th
eir dependent components, connections, lookups and JavaScript libraries. After y
ou've created various components, you can add more by clicking the correspondi
ng Plus icon. Also, you access the top dropdown Action menu to manage the com
ponents such as viewing, editing or activating an integration in this example.
On the deploy page, you can create one or more project deployments to further
organize certain groupings of your integrations. Think of a project deployment as
a snapshot of all the integrations that must be deployed together and should be
activated as a group. This way, when you export your project, you can specify th
e intended deployment version.
As an example, consider this project with five integrations. Two of them represen
t an initial version of a deployment, but there is also a new utility integration, alo
ng with updates to the other two integrations that now represent a second deplo
yment. So as I mentioned earlier, when you export your project on the Design pa
ge to be used and perhaps in another environment, you can indicate which deplo
yment to export.
Additionally, even in your own environment, rather than having to explicitly activ
ate or deactivate each and every integration in the project one at a time. From t
he Design page, you can now activate or reactivate a full project deployment. Ov
er in the Observe section, you have a single workspace to monitor all project sco
ped components.
On this Integrations page, you can view the message processing status of your a
ctivated integrations, including how many messages have been received and pro
cessed, how many successful messages or errors have occurred, and how many
messages have been canceled. In addition to information details, when you click
on various numbers, if you hover over the integration row clicking View Statistics
shows aggregated instance metrics for that integration.
On the Instances page, you can filter and track the status of integration instance
s. You can also view the activity stream and message payload of an instance you
are tracking, and you can also replay integration instances configured as replaya
ble. Clicking on Chart View allows you to see timelines for instances grouped by i
ntegration, by default. The scale is shown in minutes, but you can change that.
And of course, if any integrations have an error status, just hover your mouse ov
er the instance row and then click View Details to directly access the activity stre
am so you can start troubleshooting. On the Future Runs page, you can view a ca
lendar of all runs scheduled to trigger in the future across all schedule pattern int
egrations within the project whose schedules have started. And finally on the Au
dit page, you can view and even download the log of design time actions that ha
ve been performed by various users in your project.
And so to wrap up, there are a number of features associated with projects. The
bottom line is this that Oracle now recommends that you create your integration
s and projects, since this provides a single workspace for designing, managing, a
nd monitoring integrations. Using projects makes it easier to perform release ma
nagement control and access to your integrations and keep everything more org
anized. Thanks for watching.
Getting Started with Integrations
Welcome. In this lesson, we'll take a high-level look at the basic workflow for crea
ting, deploying, and testing an integration using a specific example for illustratio
n. Let's get started.
While there are many tasks and activities involved, depending on the use case, I'
ve distilled this development workflow into five high-level steps. First, before I st
art to create a new integration, I need to have an idea for what my use case will
be. Then if I don't already have a project, I need to create one. Then based on th
e use case, I'll create the necessary connections.
For this example, my use case is to allow REST API clients to retrieve specific info
rmation about accounts into Oracle ERP Cloud based on a provided party ID.
I'll need an invoke connection to Oracle ERP and a REST trigger connection to be
used as the interface for clients. I'll now demonstrate creating the project and cr
eating those two connections.
Within the OIC console, underneath Home, I click on Projects. And we click Add to
add a new project. I'll simply create it with the name Getting Started. Now inside
of that project page, let's go ahead and click to add a new connection. We'll sear
ch for the ERP Cloud adapter. And I'll give it a simple name and indicate the role,
in this case, will be for an invoke.
For its properties, it needs the ERP Cloud host. And, of course, I'll need credential
s to connect to it. We test that connection, and now the connection is saved.
Let's close that connection and create another one. This time, when we click the
plus sign, I'll search for REST for that REST adapter, give it a simple name. And in
this case, the role is a trigger role. For this demo, I'm going to change the securit
y to basic authentication. We'll test it, save the connection, and close it.
Now it's time to actually create the integration. For this use case, since I've decid
ed to provide a synchronous message exchange pattern for my clients, I'll be cre
ating an application pattern integration.
So let's do that now. Under integrations, I click Add, then click Create, choose the
application pattern, and then provide a meaningful name, get ERP account info,
and click Create. This brings me to the design canvas.
The third high-level step is to configure the required connections. Since this is an
application pattern, in addition to configuring the invoke connection, I must first
configure the trigger.
In the REST Adapter Configuration Wizard, I'll call this endpoint GetInfo, then pro
vide a meaningful description of the purpose and functionality of this trigger con
nection. I'll now create a URI, which includes a template parameter for this HTTP
Get and check the box to configure the response.
With nothing more to configure for the request, I click Continue and then select J
SON as the response format where I am pasting this simple design of an object t
hat will be returning these four fields of data to our client. And
I'll now review a summary of our endpoint and click Finish.
Now, to configure our ERP invoke connection. In the Adapter Wizard, I'll call it Ge
tAccount and once again, add a description. This GetAccount use case will levera
ge the first option.
The wizard allows me to search for business objects where I select account, then
locate and choose the appropriate operation, GetAccount. On the Summary page
. I click Finish and we're done.
It's now time to map the data. I'll first specify a business identifier. Then for this
use case, I'll need to map the data used to invoke the ERP Cloud as well as the d
ata to be returned to the client.
For the business identifier. I click up here to open the configuration pane. Then fo
r this integration, I'll choose the requested account party ID that was sent in as a
template parameter.
Next, I click Edit to map the data for the GetAccount invoke. In the map editor, I
drag and drop that template parameter over to the required input into the ERP Cl
oud request, click Validate, then close the mapper where now the map icon show
s color since we've implemented the mapping.
Now to edit the response mapping. In this case, all of the data I need can be loca
ted in the GetAccount response from ERP Cloud within the result object.
First, the organization name, the owner name, the name of the primary contact,
and the primary contact's email address. Once again, I click Validate, then close t
he mapper. And we're all done. So I'll click to save this integration implementatio
n.
With our integration completed, since we'll be testing and potentially troubleshoo
ting, I'll activate it using the debug tracing level, then use the REST test client bu
ilt into OIC.
And so to deploy, I click the dropdown menu next to the integration, click Activat
e. And here's where I select the debug tracing level, then click the Activate butto
n. It takes just a few seconds until I notice that the integration status is now activ
e.
Now, to test, from the menu, I click Run, which, in this case, opens an OIC REST t
est client. I'll paste in a valid account party ID, click the Run button. And in a mo
ment I can now see the returned response below.
Now, over on the right pane, the activity stream is shown where I can drill down i
nto the details of this instance. For example, I can expand the response from ERP
Cloud to see all of the other data contained within that returned account busines
s object.
Finally, clicking over here on the project observe tab, the Integrations page provi
des a summary of the instances that have run. Of course, just one so far. Then o
n the Instances page, in addition to the summary donut chart, I can locate instan
ces by their primary business identifier, allowing me once again to troubleshoot i
nto the activity stream.
So to review, while every integration scenario will be unique based on the use ca
se, you now have a general idea as to the basic workflow for developing new inte
grations from scratch. Thanks for watching.
Enterprise adapters consist of Oracle E-Business Suite Adapter, Oracle
JD Edwards EnterpriseOne Adapter, Oracle Siebel Adapter, and SAP
Adapter.
Which Oracle Integration (OIC) Integrations feature component is not
available for import within an OIC project?ans packages
Adapters and Connections
Welcome back. Now that you have a better understanding of OIC adapters in this
and subsequent lessons, I'll show you how connection resources are created. Ho
wever, before we begin, let's revisit the difference between creating a connectio
n resource versus configuring a connection within an integration to support a spe
cific use case.
Once you have created or defined a connection based on a specific type of adapt
er, it can then be used by multiple integrations to satisfy a wide variety of use ca
ses. In fact, most of the time, it is the configuring of a connection that will compri
se the bulk of your integration implementation work, leveraging the Adapter Con
figuration wizard when you add the connection to the integration. In almost all cir
cumstances, creating a connection resource involves associating it with a specifi
c external application, service, or system to which OIC will be communicating wit
h at runtime.
While most of the time you only need to create one connection for each external
application or service, which can then be used in multiple integration configurati
ons. However, there are circumstances where you should create more than one c
onnection resource for accessing the same system depending on the intended us
e cases. Sometimes by design, the connection is created at the project scope. So
if it is not marked as global, other developers and other projects will need to crea
te their own connections.
Another common case is when different credentials need to be used. For exampl
e, to access a database, you might create a connection using user credentials th
at have read-only access to a certain schema. But then another connection can b
e created to leverage different database user credentials that have both read-
and-write permissions. Likewise, many SaaS applications are set up to restrict ac
cess permission based on assigned user roles. You may have use cases that requ
ire a particular role to perform certain operations in the app, while other scenario
s require a connection associated with a user with different access permissions.
So here is the workflow for creating a connection resource. Step 1 is to select the
appropriate OIC adapter, which involves ensuring the prerequisites have been m
et. Next in the UI, provide basic information to include the role in which the conn
ection will be used for configuration in the integration. You'll then be presented w
ith options for defining the connection properties as well as defining security pro
perties. Both of these will be specific to the options associated with that particula
r type of adapter. Finally, you test the connection, validating the connection and
security properties. We'll start with the selection of an adapter.
The biggest part of the adapter selection process is to determine if all prerequisit
es have been completed. This is where it's critical that you review the online doc
umentation. The layout is very similar for every adapter, as shown here in this ex
ample for the NetSuite adapter. Early on, you'll find general prerequisites as well
as specific requirements for certain security policies, along with other informatio
n related to creating a new connection.
And depending on the adapter, these tasks will likely include discovering the end
point URL of the application, creating or obtaining the appropriate credentials, pe
rhaps updating role access permissions within the target application. Some adap
ters require setting up a confidential client application in the OCI tenancy for the
OIC instance. And for some external applications, their SSL certificate will need t
o be uploaded into OIC.
In addition, for those applications or systems that are located in your on-
premises data center or for services located in a private cloud network, and OIC
connectivity agent will need to be downloaded and installed. Of course, dependin
g on the task, it will obviously require someone with the appropriate privileges, s
uch as an administrator for the target system or application, also an OCI adminis
trator, and someone assigned to the service administrator role for your OIC insta
nce.
Now that you've selected the adapter, the UI will present the Create Connection
page, where you'll provide a meaningful name which will then automatically gen
erate a unique identifier, but you can change that if you wish, and optionally, pro
vide a description for this connection resource. But most importantly, you must i
ndicate how this connection can be used in integrations. If the adapter supports
both trigger and invoke roles, you can choose both if the intent is to use it for mo
re than one integration in both roles. Otherwise, choose just trigger or just invok
e based on the intended use case. Also note, since some adapters only support t
he invoke role, that will be your only option.
Now it's time to fill in those connection properties and choose a security policy a
nd fill in those property values as well. At this point in the workflow, what is show
n on the connection resource edit page will depend on the specific adapter. How
ever, since there are just too many adapters to cover the specific options and det
ails for each one regarding those connection and security properties, I'll stop her
e. But I will continue on in our next few lessons to look at some examples across
each of these general categories. See you then, and thanks for watching.
Cretaing Donnections
Welcome back. Now that you have a better understanding of OIC adapters in
this and subsequent lessons, I'll show you how connection resources are created.
However, before we begin, let's revisit the difference between creating a connect
ion resource versus configuring a connection within an integration to support a s
pecific use case.
Once you have created or defined a connection based on a specific type of adapt
er, it can then be used by multiple integrations to satisfy a wide variety of use ca
ses. In fact, most of the time, it is the configuring of a connection that will compri
se the bulk of your integration implementation work, leveraging the Adapter Con
figuration wizard when you add the connection to the integration. In almost all cir
cumstances, creating a connection resource involves associating it with a specifi
c external application, service, or system to which OIC will be communicating wit
h at runtime.
While most of the time you only need to create one connection for each external
application or service, which can then be used in multiple integration configurati
ons. However, there are circumstances where you should create more than one c
onnection resource for accessing the same system depending on the intended us
e cases. Sometimes by design, the connection is created at the project scope. So
if it is not marked as global, other developers and other projects will need to crea
te their own connections.
Another common case is when different credentials need to be used. For exampl
e, to access a database, you might create a connection using user credentials th
at have read-only access to a certain schema. But then another connection can b
e created to leverage different database user credentials that have both read-
and-write permissions. Likewise, many SaaS applications are set up to restrict ac
cess permission based on assigned user roles. You may have use cases that requ
ire a particular role to perform certain operations in the app, while other scenario
s require a connection associated with a user with different access permissions.
So here is the workflow for creating a connection resource. Step 1 is to select the
appropriate OIC adapter, which involves ensuring the prerequisites have been m
et. Next in the UI, provide basic information to include the role in which the conn
ection will be used for configuration in the integration. You'll then be presented w
ith options for defining the connection properties as well as defining security pro
perties. Both of these will be specific to the options associated with that particula
r type of adapter. Finally, you test the connection, validating the connection and
security properties. We'll start with the selection of an adapter.
The biggest part of the adapter selection process is to determine if all prerequisit
es have been completed. This is where it's critical that you review the online doc
umentation. The layout is very similar for every adapter, as shown here in this ex
ample for the NetSuite adapter. Early on, you'll find general prerequisites as well
as specific requirements for certain security policies, along with other informatio
n related to creating a new connection.
And depending on the adapter, these tasks will likely include discovering the end
point URL of the application, creating or obtaining the appropriate credentials, pe
rhaps updating role access permissions within the target application. Some adap
ters require setting up a confidential client application in the OCI tenancy for the
OIC instance. And for some external applications, their SSL certificate will need t
o be uploaded into OIC.
In addition, for those applications or systems that are located in your on-
premises data center or for services located in a private cloud network, and OIC
connectivity agent will need to be downloaded and installed. Of course, dependin
g on the task, it will obviously require someone with the appropriate privileges, s
uch as an administrator for the target system or application, also an OCI adminis
trator, and someone assigned to the service administrator role for your OIC insta
nce.
Now that you've selected the adapter, the UI will present the Create Connection
page, where you'll provide a meaningful name which will then automatically gen
erate a unique identifier, but you can change that if you wish, and optionally, pro
vide a description for this connection resource. But most importantly, you must i
ndicate how this connection can be used in integrations. If the adapter supports
both trigger and invoke roles, you can choose both if the intent is to use it for mo
re than one integration in both roles. Otherwise, choose just trigger or just invok
e based on the intended use case. Also note, since some adapters only support t
he invoke role, that will be your only option.
Now it's time to fill in those connection properties and choose a security policy a
nd fill in those property values as well. At this point in the workflow, what is show
n on the connection resource edit page will depend on the specific adapter. How
ever, since there are just too many adapters to cover the specific options and det
ails for each one regarding those connection and security properties, I'll stop her
e. But I will continue on in our next few lessons to look at some examples across
each of these general categories. See you then, and thanks for watching.
Connection and Security Properties (Part I)
Welcome back. Let's pick up where we left off in the previous lessons creating co
nnections with part 1 of connection and security properties. Now that you've sele
cted the adapter and addressed any prerequisites, provided a unique name and
determined the role for the connection, you'll be on the page where you must no
w define connection and security properties. As promised, we're going to look at
several examples across these various categories of adapters, starting with Oracl
e Fusion Cloud Applications.
Regardless of which one, ERP Cloud, HCM Cloud, or the CX Sales and B2B Service
Cloud, these adapters support the configuration of connections in either the invo
ke or trigger role. The connection property is simply the host name URL for your
application instance. And for security, you indicate the desired policy. One option
is to use OAuth authorization code credentials, assuming someone has complete
d those prerequisites defined in the adapter documentation or simply provide a v
alid username and password. Incidentally, you'll use this option later on if you ch
oose to do the hands-on lab exercises for this course.
And for those ERP and HCM Cloud connections that will also need to upload files
directly to Oracle WebCenter Content, commonly known as UCM, or Universal Co
ntent Management, there is also the option to upload the public and private keys
required for PGP encryption support. In addition to those Oracle Fusion Cloud app
s, there are adapters for a host of other Oracle Cloud Applications along with the
se Oracle on-premise apps. Suffice it to say that each of these will present their o
wn security options as well as requirements for connection property details.
Let's now shift to third party SaaS applications, starting with the Salesforce Custo
mer Resource Management platform. This adapter supports the configuration of
connections in either the invoke or trigger role. And as a reminder, you will need
to verify that all required prerequisite tasks have been performed. There are a n
umber of them, depending on how you intend to use this connection resource. Yo
u'll first select the application instance type production, sandbox, or government.
Then enter which API version your instance uses. Under optional properties, a cu
stom domain name can be provided, which is actually required when you are usi
ng Salesforce Government Cloud.
Then below, you select one of these security policies, providing an authorized Sal
esforce application username and password, or assuming that OAuth three-
legged prerequisites have been completed in Salesforce, provide the client ID an
d secret for the authorization code credentials policy, or select this to add the ide
ntity of a resource owner in addition to the OAuth client authorization. For this ex
ample, we'll look to define a connection using the ServiceNow adapter, which can
also be used in either the invoke or trigger role. The connection property just nee
ds the instance name URL that is received once someone has purchased a Servic
eNow subscription. Then for security, similar to Salesforce, you can provide eithe
r a username password for basic authentication or, assuming the necessary prer
equisite tasks are complete, use the authorization code or resource owner passw
ord credential policies.
The next example is the cloud-based e-commerce application known as Shopify. I
n addition to invoke role use cases, this adapter also supports trigger role connec
tions so integrations can perform various types of actions against events receive
d from certain Shopify modules. The connection properties include the Shopify h
ost name, the appropriate Shopify API version, and other optional properties. You
can add a comma-separated list of related Shopify connection IDs, which is actua
lly required for trigger role connections so that a single integration can connect t
o any number of Shopify stores.
In addition to basic authentication, security policy requiring a valid username an
d password, you can use either the Shopify access token policy, which requires o
nly an admin API access token or the Shopify security policy, which in addition to
a username, password, and requires a shared secret that was obtained from the
prerequisite tasks. And of course, there are many others, but you now get the ge
neral idea of how the adapters create connection page, presents the connection,
and security policy options uniquely for each application.
And now it's time to look at defining connections to database systems. And we'll
start with Oracle's most advanced databases, Autonomous Transaction Processin
g and Autonomous Data Warehouse. As with all Oracle databases, one of the key
prerequisites is for a database administrator to have downloaded the client crede
ntials wallet, which contains all the connection information needed for that datab
ase instance. The JDBC over SSL security policy is easy to configure as you just u
pload that wallet and provide the wallet password. Then indicate the credentials
of the database user you wish to use for this connection resource, which will then
provide access based on that user's permissions.
The JDBC with OCI signature security policy also requires the wallet along with da
tabase user credentials. However, the policy requires additional information abou
t OCI Object storage, along with the credentials needed to access the object stor
age service in a particular OCI region and compartment. This policy is required if
you want to use this connection in an integration that will be using the bulk data
import operation directly, which means it isn't using a connectivity agent for acc
ess.
And while this JDBC basic authentication security policy doesn't require the walle
t to be uploaded, you will be able to ascertain the connection properties from the
tnsnames.ora file located within that wallet to complete this configuration. Of co
urse, as with the other policies, you'll need to provide credentials for a database
user. As to other Oracle databases, such as Oracle Database Cloud Service, Exad
ata, Database Cloud Service, or even an on-premises Oracle database, defining t
he connection can use the Oracle Wallet security policy, where you upload the w
allet containing all the connection information or use the username-password tok
en policy, which will require you to obtain that connection information from the t
nsnames.ora file. In addition for on-premises Oracle Databases, you will need to
associate access with an appropriate connectivity agent.
Let's now take a look at a third party database example, Microsoft SQL Server. T
his adapter allows you to create a connection to either a SQL server instance run
ning in your on premises data center, or you can connect to an Azure SQL databa
se in the Cloud. Here there is only the username password token policy, where y
ou provide the credentials of an authorized SQL service user. And of course, you'l
l obtain the connection information from the SQL server administrator.
For the access, the only option is to associate the connection with a connectivity
agent, either deployed in your on-premises data center or deployed in a cloud ne
twork that has access to the Azure instance. And of course, there are other datab
ase systems both in the cloud and on-premises that are supported by these OIC
adapters. Once again, the connection details and security policy optio
ns are specified accordingly in the adapter documentation.
Welcome back to part 2 of connection and security properties. In the last video, I
concluded with some database examples. Moving now to messaging systems. W
e'll start with the OCI streaming service since it is easily available to you as long
as you-- or someone with the appropriate permissions provision a stream in your
OCI tenancy. You'll need to obtain the URL for the stream pool bootstrap server,
which includes the appropriate OCI region. There is just one security policy-- SAS
L stands for Simple Authentication and Security Layer.
The username is a combination of the tenancy name, the OCI username that has
permissions to the stream, and the OCID of the stream pool separated by forwar
d slashes, as shown here. The password is actually an OCI authentication token t
hat was generated for that user. And optionally, you can upload a JKS file created
when you generate a TrustStore from the root certificate using the key tool utility
. Detailed information for all of this is once again provided in the adapter docume
ntation.
Finally, if you intend to use this connection to consume new messages as a trigg
er into an integration, you'll need to associate it with an installed connectivity ag
ent. Since the Kafka cluster can consist of more than one bootstrap server, you'll
provide the host and port for each of those Kafka brokers. And as you can see, th
e requirements for security is similar to OCI streaming, but only if you choose the
SASL plain over SSL security policy.
Naturally, the structure for the SASL username will be defined by the target syste
m. What's different here is that since the external Kafka messaging system you
wish to connect to could be anywhere and have different security requirements.
You have these other options to choose from to include no security policy. And ju
st like OCI streaming, trigger connections will need to be associated with a conne
ctivity agent.
To connect to an Azure Event Grid messaging system, the prerequisite section of
the adapter documentation shows how to find your subscription ID, API version a
nd how to create a resource group. You'll then register an application in the Azur
e portal and obtain the client ID secret and tenant ID.
And for trigger role connections, you'll need to add a shared secret value that yo
u obtain from Azure, then click the Provide Consent button to register the grant f
or OIC to authorize the client. As to access type, you'll need to use a connectivity
agent only if that Azure Event Grid is in a private network. Otherwise, the public
gateway is fine. And while there are other messaging systems supported, definin
g these adapter connections will be very similar to the three examples we just sa
w.
Let's now look at some examples for social and productivity adapters. First, Even
tbrite, a popular cloud application used by event organizers. When defining this c
onnection, you'll notice that only the invoke role is supported, which makes sens
e. And as a reminder, check those prerequisites mentioned in the documentation
. In this case, you'll need to ensure that an Eventbrite application management a
ccount has been created, as well as an application key.
Also, an OIC service administrator will need to upload the trusted Eventbrite publ
ic certificate into your OIC environment. Now, for security, there are these two po
licies to choose from. This generic OAuth policy only requires the security token,
which is displayed on the application management page in Eventbrite, while this
custom policy requires both the client ID, which is the application key along with
the secret, which is that same security token.
Another example is to create a connection using the Google Calendar adapter, w
hich of course, is also used only in the invoke role. There is only this one security
policy, but of course, we need to review the host prerequisites. In this case, you
need to ensure that an account and a Google project has been created. Then wit
hin the library section, the calendar API has been enabled. Then OAuth client cre
dentials need to be created, which is where you get the client ID and secret.
And for the scope, you indicate either full access or read only. Finally, an OIC ser
vice administrator will need to upload the GeoTrust Global CA certificate so the a
dapter can connect securely. Defining a connection using the Slack adapter is ve
ry similar to Google Calendar in that there is only one custom security policy, but
again, there are specific prerequisites. Someone needs to sign up for a Slack dev
eloper account, then create an OAuth application. From there. Slack automaticall
y generates a client ID and client secret, which you'll need to provide here.
Also, one or more OAuth authorization scopes must be added for that Slack appli
cation, as shown here. And these correspond to the operations supported by the
Slack adapter. And here's where you'll explicitly choose which ones will be neede
d for your connection. Of course, you may need to review the documentation on
the Slack.com website for details about these scopes.
And in addition to those three examples, there are several other adapters, each
providing the appropriate documentation for defining connectivity and available
security policy options. Generic technology adapters include the REST adapter, w
hich can be used in the invoke role to access an external web service or in the tri
gger role to define an interface for an integration, which can be called by a REST
client.
In a similar manner, the SOAP adapter can be used in the invoke role to call a SO
AP web service or in the trigger role to define an interface for an integration base
d on a WSDL, which can then be called by a SOAP client. The FTP adapter is used
only in the invoke role as it can upload or download files from an SFTP or FTP ser
ver.
And finally, the file adapter which is always configured in conjunction with an OIC
connected agent. When used in the invoke role, it can read or write files to an on
-premises file system or when used in the trigger role, the connectivity agent will
pull for files to be delivered to the integration.
As to defining and configuring connections with these technology adapters, since
they are used in so many integration solution use cases, I'll be covering each of t
hese in more detail in other lessons. So now returning to our workflow. Once you
have defined all of the required connection and security properties, it's time to te
st. In fact, until you have performed a successful test, your connection resource
will continue to remain in a draft status and won't be available to use in integrati
ons.
Testing is easy. At the top of the page next to the Save button, you click Test. Thi
s can take a few seconds or perhaps even a minute or two, depending on the typ
e of adapter and external system. Now, something is wrong, an error message wi
ll pop out, similar to this one. Oftentimes, the issue is with invalid credentials or
perhaps incorrect connection information. Now, after you've resolved the issue, j
ust click Test Again. And once the test is successful, the connection resource will
now be in the configured status. You save it, and now it can be used in your integ
rations.
So to wrap up, regardless of which type of adapter you're going to be using to de
fine your connection resource, it's important that you ensure that all prerequisite
tasks have been handled by those individuals with the appropriate permissions,
and that you explore the online documentation for that particular adapter to lear
n more details about all the various connectivity and security properties that nee
d to be defined. That's it for this lesson. Thanks for watching.
Defining SOAP Adapter Connections
Welcome. In this lesson, we'll look at the options you have for defining connectio
ns using the generic SOAP technology adapter. Let's get started. First, as with m
ost connections, there are two high-level use cases. You can create a new integr
ation and design an interface based on a WSDL for integration clients by defining
a SOAP adapter connection in the trigger role. Or you may need to access an ext
ernal SOAP-based web service from your integration. If so, you need to define a S
OAP adapter connection to designate that service in the invoke role. In either cas
e, SOAP adapter connections are limited to only HTTP-based SOAP, so no other S
OAP transport protocols are supported.
We'll start with what is likely to be your more common use case, the need to call
some external web service. The invoke role connection will send a SOAP payload
to the external SOAP endpoint. Then any response received becomes available w
ithin your integration for further processing. Here are some adapter capabilities a
nd limits.
For invokes, the adapter will ensure that an outgoing structured payload based o
n an XML schema does not exceed the size limit which is currently 100 megabyte
s or, when using an on-premises connectivity agent, 50 megabytes. As to sendin
g binary or non-binary content as an MTOM attachment, that limit is now 1 gigab
yte. The same supported limits are enforced for content structured or non-
structured when returned as a response from the invoked web service.
Support is also provided for any other header property values that may be requir
ed or expected as part of the request message or that may be returned in the re
sponse, whether they be HTTP or SOAP standard or custom headers. For security
, in addition to typical SSL over HTTP invocations, if the external service also req
uires a client certificate, the adapter can support that two-way SSL handshake. A
s to security policies, the adapter connection can be configured to support whate
ver is required by the external service, a username password sent in the HTTP he
ader or in the SOAP header or providing client credentials or authorization code c
redentials using OAuth. Also, if the service has no security requirement, you can i
ndicate that no security policy will be used.
The adapter connection will also support whatever message exchange patterns a
re indicated by the external services WSDL, including synchronous request respo
nse, one-way request, or asynchronous request with callback support using the a
ddressing SOAP header. Another feature is the ability to support the dynamic dis
covery of SOAP endpoints. Now, this is useful for scenarios in which the endpoint
invoked by the SOAP adapter must be dynamically configured within the integrati
on flow based on runtime logic.
So once you've provided a name for the connection and selected the invoke role,
the only required connection property is to provide the URL to the external servic
es WSDL, or you can upload the WSDL if you have a copy of the file. In the securi
ty section, you choose the security policy that corresponds with the requirement
s of that service. For the OAuth client policy, provide the access token along with
the client credentials. And for the OAuth authorization code policy, in addition to
those property values, you'll also provide the authorization code and scope.
In both scenarios, since the adapters default behavior is to send those client cred
entials in the SOAP header, you'll only need to use the optional security section if
the service's requirements are to send those credentials on either the SOAP body
or in an HTTP header. Finally, you'll need to indicate how the OIC adapter will be
accessing the web service. In most cases, the web service will be publicly availab
le on the internet, so you'll use the default public gateway. However, if the servic
e is running in a private cloud network, you can connect directly, but only if your
OIC service administrator has set that location as a private endpoint for your OIC
instance.
Otherwise, the only other way to access a private service either in the cloud or o
n-premises is via an installed connectivity agent. In this case, you select that opti
on, then indicate which agent group will be used. And that wraps up part 1 of our
lesson. In part 2, we'll look at the trigger role use case. See you in the next video
.
Welcome back. Let's continue now with part 2 of defining SOAP adapter connecti
ons. As you recall, we have two types of use cases for SOAP adapter connections.
And since we've already covered the invoke role in part 1, let's now switch gears
to the other use case.
And in all fairness, this one is not that common anymore, since most of the time
when you're looking to expose an integration as a service, you're likely going to c
hoose a REST adapter trigger rather than a SOAP trigger. However, there are still
times when this may be your business requirement. So let's explore this use case
.
When the trigger role is selected, you're essentially looking to define an interface
for SOAP clients, and the capabilities of the adapter are very similar to those I art
iculated when it is used in the invoke role. The payload limits for incoming reque
sts and the return response is the same. The only difference is an MTOM attachm
ent cannot be accepted in the request, but only as a response.
You can also process any header property values that were sent by the client or t
hat you wish to send back to the client in the response. Likewise, since you can c
hoose any valid WSDL file to define the interface, all three SOAP message excha
nge patterns can be supported.
As for security, one difference for a trigger interface is that it can only be configu
red as an HTTPS protocol-based endpoint. You can also choose to enforce two-
way SSL, which will require an administrator to ensure valid client certificates are
uploaded into the OIC environment.
And for security policies in addition to HTTP or SOAP header-based username/
password options, there are a variety of additional OAuth 2.0 grant types. And th
e other difference is that you can choose to instead accept the SAML token from
the client to access the integration via the trigger configuration.
So then once you've provided a name for the connection and selected the trigger
role, in this scenario, you need to upload an abstract WSDL that you or someone
else has already designed to describe this interface. Now, if you're not familiar wi
th SOAP, an abstract WSDL document describes what the service does, but not h
ow to contact it. It defines the operations provided by the web service, as well as
the input/output and fault messages used by each operation to communicate wit
h the web service and their format.
Much later after integration that is using this trigger connection has been activat
ed, a concrete WSDL will be generated by OIC, which you can distribute to clients
as it will contain the same information, along with the communication protocol to
use, which will be HTTP and the URL that must be used to contact the web servic
e. So essentially, most of the work for creating a SOAP adapter trigger connectio
n will be to design and create the file using a WSDL editor such as XMLSpy or the
extension available in Oracle JDeveloper.
Also in secure web services transactions, a timestamp can be inserted into a WS
security header to define the lifetime of the message in which it is placed by defa
ult, the adapter will process this header. But if yes is selected here, no timestam
p is required to be sent by the client.
In the security section, you'll need to decide how clients will be required to provi
de their credentials. With the username/password token policy, clients must send
a username and password as part of the WSSE SOAP header, while the basic aut
hentication policy requires clients to send the username/password as HTTP head
ers. SAML, of course, expects a valid SAML token from the client. And finally, the
OAuth 2.0 policy.
OIC supports several OAuth grant types and each of them will require different s
etup tasks to be handled by an OCI administrator, all of which are spelled out in t
he adapter documentation. Now, we won't detail all those tasks here in this lesso
n, but for now, let's review those supported grant options. The authorization cod
e grant type is used by web and mobile applications and differs from most of the
other grant types by first, requiring the application to launch a browser to begin t
he integration.
The resource owner password credentials grant type is only suitable for cases wh
ere the resource owner has a trust relationship with the OAuth client. And since t
he credentials can be used directly as an authorization grant to obtain an access
token. However, Oracle does not recommend you use this grant due to several ri
sks that you can read about in the documentation. Probably the most important
one is that OIC has already announced that support for this grant type is now in
a deprecated state.
OK, so the client credentials grant uses an OAuth flow where the client first auth
enticates with the authorization server and requests an access token from the to
ken endpoint. This grant is typically used by clients to obtain an access token out
side of the context of a user, for example, to access resources about themselves
rather than to access a user's resources.
And finally, the preferred and recommended grant type is to enable JSON web to
ken or JOT user assertion. Here, the user assertion is used directly as an authoriz
ation grant to obtain an access token. The client details are provided either as an
authentication header in the request or as a client assertion. The user can either
represent a person or a service integration account created for identifying a spec
ific calling application. Oracle recommends the use of this grant type for applicati
ons that must programmatically start the integration without any user interventi
on.
And so to wrap up, in this two-part lesson, we covered the two general use cases
for creating connections with a SOAP adapter and the trigger role to serve as a W
SDL interface for SOAP clients to an OIC integration, or in the invoke role used to
identify and access an external web service. That's it for this lesson. Thanks for
watching.
Welcome. In this lesson, we'll look at the options you have for defining connectio
ns using the generic REST technology adapter. Let's get started. First, as with mo
st connections, there are two high-level use cases. You can create a new integrat
ion and expose it as a REST API by defining a REST adapter connection in the trig
ger role. Or, you may need to access an external RESTful web service from your i
ntegration. If so, you need to define a REST adapter connection to designate that
service in the invoke role.
We'll start with the invoke role use case where you can define a REST adapter co
nnection to consume any external REST API. Here are some adapter capabilities
and limits. For invokes, the adapter will ensure that responses containing attach
ments do not exceed 1 gigabyte. These can be multipart mixed or form-data, or
application octet-stream.
For structured data, which is any content type header containing JSON, XML, HTM
L, or YAML. The limit for both requests and responses is 100 megabytes or 50 me
gabytes when using a connectivity agent. As to receiving an unstructured respon
se payload multipart form-data or binary octet-stream, that limit is also 1 gigabyt
e.
When configuring the connection in the integration flow, you indicate the relative
resource URI and HTTP method either get, put, post, delete, or patch, support is
available for template parameters, as well as one or more optional query parame
ters. And you'll have the opportunity to define any structured request or respons
e payloads.
There, you can use a sample JSON file of up to 100 kilobyte to specify the data ty
pe of the request or the response. Or, you can create a data definition from an X
ML document if it is less than 3 megabytes. Support is also provided for any head
er property value that may be required or expected as part of the request messa
ge or that may be returned in the response, both standard or custom headers.
To configure manually, you just provide the URL for the REST API endpoint, or yo
u can define the connection to any REST API that is described using an Open API
document. At design time, the REST adapter can automatically discover and pres
ent all of the available resources and operations present in that document for co
nfigurations to include operations specific request and response message types.
For security, in addition to typical SSL over HTTP invocations, if the external servi
ce also requires a client certificate, the adapter can support the two-way SSL han
dshake. As to security policies, the adapter connection can be configured to supp
ort whatever is required by the external service, anything from no credentials or
just basic authentication to a variety of OAuth client policies and Amazon web se
rvices signature policy, and OCI signature, or support for the resource principal s
ession token for invoking OCI services.
This connection also allows you to dynamically change the endpoint configuratio
n from within the integration flow, which is useful if the endpoint is not known at
design time, but can be determined at runtime. To define the connection, once y
ou have indicated the invoke role next on the connection page, you can either se
lect to provide the base URL for the web service endpoint. Or if the service provi
des an Open API description document, you can indicate that URL.
Either way, it is recommended that you do not select a value for transport layer s
ecurity, since OIC will automatically use the latest TLS version for SSL communic
ation. And if the service requires two-way SSL, you enable this option by selectin
g Yes, then enter the key alias name from the keystore file that was specified by
the administrator when importing the identity certificate.
As to selecting a security policy, you need to select one that corresponds to one
of the security options that are supported by the web service provider after revie
wing their documentation. So, for example, if they support basic HTTP authentica
tion, you could choose this and just provide a username password. Or if the servi
ce requires no authentication, just select no security policy. However, most use c
ases will likely involve selecting one of these OAuth grant types, again, dependin
g on the requirements of that external service.
Suffice it to say that each of these will present, required an optional security field
s that you'll need to fill in, and you should consult the OIC adapter documentatio
n to explore those property details. Here's an example showing the UI for the OA
uth custom three-legged flow security policy.
For use cases where you need to invoke an OCI REST API, you can create an API s
igning key using OpenSSL to pass as a specific credential using this OCI signatur
e policy. Or another option is to use the OCI service invocation policy by using a r
esource principal session token and creating a dynamic group in OCI to identify y
our OIC instance as a trusted user.
In the case of Amazon web service API, you specify AWS security credentials and
other required fields such as the AWS region using this security policy. And for m
any other third-party web services that use paid subscriptions, this basic API key
based authentication policy can be used.
To summarize, selecting the appropriate security policy and defining security pro
perties will require you to consult both the documentation for that external web s
ervice, as well as reviewing the OIC REST adapter documentation.
Finally, you'll need to indicate how the OIC adapter will be accessing the web ser
vice. In most cases, the web service will be publicly available on the internet, so
you'll use the default public gateway. However, if the service is running in a priva
te Cloud network, you can connect directly. But again, only if your OIC service ad
ministrator has set that location as a private endpoint for your OIC instance. Oth
erwise, the only other way to access a private service either in the Cloud or on-
premises is via an installed connectivity agent. In this case, you'd select that opti
on, then indicate which agent group will be used.
Let's pivot now quickly to the trigger role use case. Defining a REST trigger conn
ection is quick and easy since there are no connection properties, nor are there a
ny security properties. You only need to decide how clients will be required to au
thenticate when accessing the integration by selecting a security policy, basic HT
TP username and password authentication, OAuth2 grant types, or support for bo
th.
The reason it is as simple is that designing the actual REST API interface will be h
andled later on when you are configuring this connection as a trigger for a specifi
c integration. There, you will leverage the Adapter Configuration Wizard to assist
you with that design implementation.
However, regardless of which policy you select, as always, there are other relate
d prerequisites to be considered, all of which are explained thoroughly in the ada
pter documentation. To facilitate client access if you do select OAuth2, you'll nee
d to ensure that an administrator has specified and configured support for the va
rious OAuth2 grant types in the Oracle Identity Cloud Service application associat
ed with this OIC instance.
And for either policy, one or more users will need to be added to the OCI identity
and access management service and assigned to the OIC service user role. This
could represent an actual business user or it could represent a service integratio
n account used by an external client application.
And so to wrap up, we covered the two general use cases for creating connection
s with the REST adapter in the trigger role to serve as a REST API interface for cli
ents to access an OIC integration or in the invoke role used to identify and acces
s an external web service. That's it for this lesson. Thanks for watching.
Connecting to Private Resources
Welcome. In this lesson, you'll learn about two options available for accessing ap
plications and services that are located in private networks. Many business use c
ases require integration with applications and resources residing in an on premis
es data center or a private Cloud Network to facilitate access.
Oracle integration provides two options, configuring a private endpoint for acces
sing resources within an OCI private subnet or installing one or more connectivity
agents within private networks, either on premises or in the Cloud. Which approa
ch you choose will depend on these considerations, since each option involves ve
ry different architectural considerations. I'll discuss and contrast each of these ar
eas in this lesson.
Let's start with the private endpoint. This option is limited to resources that are l
ocated within an OCI Virtual Cloud Network. Once your administrator has configu
red this private endpoint for your OIC instance using the OCI console, you can no
w associate an adapter connection resource to that private endpoint.
In this example, at runtime, the integration uses the ATP connection to access th
e database located in that OCI subnet. And notice that the request and response
traffic never goes through the public internet. And while IPsec tunneling and Fast
Connect are not supported for use with private endpoints, as you can see from th
is architecture, there really is no need since all traffic is on this private channel w
ithin Oracle Cloud.
In addition to that ATP example, other application and technology adapter types
are supported. As you see, your integrations could invoke any of these directly, s
uch as a private FTP server or a web service hosted on a compute instance, as w
ell as accessing a privately hosted Oracle Application, messaging service, or data
bases. Now, while this diagram represents our current support for the private en
dpoint, keep in mind that supported OIC adapter types are always growing. So co
nsult our online documentation for the latest list.
Configuration is a one time initial task, which is done in the OCI Console. You nav
igate to the OIC instance, under the Resources section, click Create Private Endp
oint, which will open this Configuration pane. Notice that you must have the appr
opriate administrative permissions to create this resource. From there, you locat
e and select the Virtual Cloud Network and then select the private subnet that th
e OIC instance will be connecting to.
Then at the bottom, click Create Private Endpoint. Within 3 to 5 minutes, you can
refresh the page to see that the private endpoint is now configured. Now, when a
n OIC developer wishes to define a new connection, if the application or service i
s located inside that private subnet, they simply select private endpoint as the a
ccess type.
Switching now to connectivity agents. Here, the agent is deployed on a compute
instance within that private subnet. Then an OCI service gateway is added to the
VCN and configured to route traffic to the Oracle Services Network. The differenc
e is that OIC is not directly invoking the private resources. Instead, the agent use
s a pulling mechanism to OIC, which allows it to invoke the resource locally on be
half of the integration.
So technically, there is no outbound traffic from an integration. The connectivity
agent maintains a secure connection to OIC, retrieves the request, invokes the a
pplication or service, then returns a response. This architecture also allows privat
e resources to access other OIC integrations directly rather than having to use th
e public internet.
However, because the connectivity agent can use the public internet, unlike priv
ate endpoints, the agent can be deployed on a virtual machine in any private Clo
ud Network such as Google, Azure, or AWS. Likewise, agents can be deployed on
virtual machines or physical servers located in your on premises data center. Thi
s works the same way as with private Cloud networks, in that the agent is respon
sible for fetching the requests from OIC, then invoking the on premises applicatio
n.
This means that you don't have to open firewalls to access applications on your p
rivate network. In addition, all messages between the agent and Oracle Integrati
on are encrypted. Of course, there is a bit more to learn about connectivity agent
architecture and behavior, as well as how to install, configure, and monitor agent
s. I encourage you to watch these video lessons as well to dive into those aspect
s a bit deeper.
With regard to adapter support, the connectivity agent can be used with all these
various types of applications, services and technologies, whether they are deploy
ed on premises or in the Cloud. All of these can be invoked by the agent on behal
f of a configured integration flow. But as you can see, many of these can also be
configured and used as a trigger for an integration where the agent will be respo
nsible typically for pulling the resource, then sending the message to OIC, which
will then launch the integration instance.
So let's wrap up this lesson by contrasting the differences between these two opt
ions across each of these four general areas. The private endpoint is limited to re
sources within a single OCI subnet, while connectivity agents can be installed an
d deployed within any Cloud Network to include OCI or your on premises data ce
nter. As to security, the private endpoint remains within the Oracle Services Net
work using a private channel to a dedicated VNIC in that OCI subnet.
And while the connectivity agent typically connects to your OIC instance through
the public internet, when deployed to an OCI subnet, it can use the VCN service
gateway. Or for other private networks, if required, you can leverage oci, FastCo
nnect or IPsec tunneling services to further isolate network traffic. We'll explore t
hat a bit further in another lesson.
As we saw, an OCI administrator configures and enables the private endpoint, as
sociating that OAC instance with just one OCI subnet. However, that is a one tim
e task with no additional management required. Now setup of a connectivity age
nt is handled by an OIC administrator that has access to any physical or virtual m
achine within that private network with up to five separate agent groups allowed.
However, since there are Java machine processes involved, the connectivity age
nt requires some maintenance and management. For example, you must still ma
nage the host machine as well as the upgrade cycles of the agent itself. Now, for
connectivity, the private endpoint can only be used from integrations using invok
e role connections to access a private resource, and there is a more limited num
ber of supported adapters.
The connectivity agent can facilitate both invoke role and trigger connections us
ed within OIC integrations. And there are several more adapters that are support
ed to include, of course, on-premises applications. And as I mentioned earlier, sin
ce there is so much more to learn about connectivity agents, there are additional
lessons in this course covering its architecture and usage. I'll see you in the next
video.
Connectivity Agent
Welcome back. In this lesson, you'll learn more about connectivity agent architec
ture and capabilities to include deployment patterns. Let's pick up where we left
off in the previous lesson where I was discussing the basic public internet pattern
. The connectivity agent always maintains a secure connection to OIC, in this cas
e using an outbound public internet connection. And with a polling strategy to ret
rieve requests, it can invoke the private resource on behalf of an integration flow
.
However, there are other patterns that can be used when greater security and hi
gher speed performance is required. Here, we have selected to configure an excl
usive connection using FastConnect, which provides a faster, more reliable netw
orking experience compared to the public internet. FastConnect leverages indust
ry standard BGP routing, that's Border Gateway Protocol, to manage the exchang
e of routes between Oracle Cloud and your networks. In this case, both the inbou
nd and outbound traffic to OIC goes through the FastConnect link, which contains
the public IP address of your OIC instance. Notice that with the public peering pat
tern, you must deploy the connectivity agent in your private network or on-
premises data center.
The private peering pattern provides additional security to prevent traffic analysi
s. And you can deploy the agent in the cloud or in your data center. In this exam
ple, you provision an OCI Virtual Cloud Network with a private subnet. Then add
and configure a service gateway to route the traffic from the VCN to Oracle Integ
ration. And of course, with the private peering option, the FastConnect link contai
ns the private IP address of the VCN. This pattern also supports virtual private ne
tworks where the architecture is identical, except that the FastConnect private p
eering link is replaced with Oracle's site-to-site VPN service.
Another private peering option is to deploy the connectivity agent to a virtual ma
chine within that private subnet instead of in your data center. The configuration
is almost the same. Note that this approach also allows the connectivity agent to
access any other resources that may be deployed in that same private subnet, s
uch as an Oracle Database Cloud Service or an Apache Kafka messaging cluster.
Let's now reverse the diagram to discuss deployment. First, within your OIC insta
nce, an OIC administrator defines a connectivity agent group which has a unique
identifier. Then the OIC admin downloads the agent installer as well as the config
file for that group, then installs the agent on a physical or virtual machine host,
where it will immediately start running and establish a connection to OIC. Note th
at the agent can be installed on any host machine from which it can establish a T
CP/IP connection to the applications and services it needs to reach. Now for high
availability, you can add one additional agent to that same agent group. Of cours
e, you'd typically install it on a separate host.
Additional agent groups can be used for functional process or organizational leve
l isolation, as well as access to other data centers or private cloud networks. In fa
ct, an OIC environment can have up to five agent groups defined with a maximu
m of two agents per group. Here are some other points to keep in mind. No ports
are opened on the firewall for communication since connections are established f
rom the agent. And all communication is secured using SSL and is initiated by th
e connectivity agent. In fact, it has no listening port and does not permit any exp
licit inbound connections. And since the agent functions as a lightweight stateles
s daemon service, there is no data ever persisted in the agent.
So let's now pivot to learn how the agent operates. Once deployed, the agent po
sts a regular heartbeat to the internal OIC SaaS agent to signal that it is alive an
d well. This is how OIC administrators can keep track of the health status of all co
nnectivity agents. Also, don't be concerned with the name of that background se
rvice. We call it a SaaS agent, but it has nothing to do with external SaaS applica
tions. It is only used to facilitate communications with connectivity agents.
Additionally, there is an internal message queue embedded within the OIC instan
ce, and it is the connectivity agent that continuously polls for any design time an
d runtime work that needs to be processed. Now design time work requests are d
elivered as a message to the queue via the SaaS agent, such as testing a connec
tion or using the configuration wizard on the integration design canvas. Then the
connectivity agent pulls that request from the queue, sends it on to the private r
esource, then delivers a response back to the queue, which is then picked up by
the SaaS agent and delivered to the design canvas.
The runtime work involves processing invoke messages from integration, instanc
es that need to be sent to private resources, such as databases, file systems, e-
business suite, Siebel, or any other private SOAP or REST endpoints. So when the
runtime invoke is made, it is sent to the SaaS agent, which queues the request m
essage, which is then pulled by the connectivity agent and sent to the resource.
Once there is a response, the agent sends it back to the queue where it is then d
elivered to the awaiting integration instance. If you're concerned about performa
nce, trust me, it looks way more complex than it is as there is very little latency
because under the covers, each of these requests and responses are handled as
ynchronously, which allows the agent to process messages very quickly. In additi
on, the agent is multithreaded, which allows it to process numerous concurrent r
equests while waiting on each thread for a response from the local resource.
Also, be aware that OIC will wait for a maximum of 240 seconds after it has poste
d a request for the agent. If no response or fault message is received within 4 mi
nutes, the flow instance times out and fails with a timeout error message. Finally,
for those use cases where the trigger role is used with a connection that is associ
ated with a connectivity agent, once the integration is activated, that agent will b
e responsible for pulling the resource, such as in this example with Apache Kafka
. It then sends that message to the internal queue, which will then cause the Saa
S agent to launch that integration instance with that trigger message.
Finally, let's briefly look at four example topologies, starting with this scenario, w
here all your private databases and applications are running in your data center.
And as we saw earlier, the agent can simply be installed in that same private net
work. On the other hand, if your private resources are all running in private cloud
networks, in this case, you could use two different agents to be deployed within t
hose OCI subnets dedicated to each resource. Then, of course, another agent ca
n be deployed to a virtual machine in that third party private cloud network.
To configure high availability for the agents, in this case, we can install two agen
ts assigned to the same agent group handling all inbound traffic for the data cent
er resources. Then for the OCI private resources, we could use a public subnet, a
dd two virtual machines, each hosting an agent, with both assigned to the same
group with routing configuration to access to both private subnets.
In this last scenario, we consider that the applications and databases themselves
have been configured for high availability. And this is most often achieved with lo
ad balancers placed in front of those resources, both in the cloud and on-
premises. So once again, as in the last scenario, we only need to configure high
availability by deploying two agents per agent group, both in the cloud and in th
e data center, which each enable to access all of their respective resources. Of c
ourse, if necessary, you could add additional agent groups that are dedicated to
each load balancer.
Well, that's it for this lesson. But as a reminder, in the OIC administrator tasks m
odule, there are these two additional videos. Thanks for watching.
Connectivity Agent Architecture
Welcome back. In this lesson, you'll learn more about connectivity agent architec
ture and capabilities to include deployment patterns. Let's pick up where we left
off in the previous lesson where I was discussing the basic public internet pattern
. The connectivity agent always maintains a secure connection to OIC, in this cas
e using an outbound public internet connection. And with a polling strategy to ret
rieve requests, it can invoke the private resource on behalf of an integration flow
.
However, there are other patterns that can be used when greater security and hi
gher speed performance is required. Here, we have selected to configure an excl
usive connection using FastConnect, which provides a faster, more reliable netw
orking experience compared to the public internet. FastConnect leverages indust
ry standard BGP routing, that's Border Gateway Protocol, to manage the exchang
e of routes between Oracle Cloud and your networks. In this case, both the inbou
nd and outbound traffic to OIC goes through the FastConnect link, which contains
the public IP address of your OIC instance. Notice that with the public peering pat
tern, you must deploy the connectivity agent in your private network or on-
premises data center.
The private peering pattern provides additional security to prevent traffic analysi
s. And you can deploy the agent in the cloud or in your data center. In this exam
ple, you provision an OCI Virtual Cloud Network with a private subnet. Then add
and configure a service gateway to route the traffic from the VCN to Oracle Integ
ration. And of course, with the private peering option, the FastConnect link contai
ns the private IP address of the VCN. This pattern also supports virtual private ne
tworks where the architecture is identical, except that the FastConnect private p
eering link is replaced with Oracle's site-to-site VPN service.
Another private peering option is to deploy the connectivity agent to a virtual ma
chine within that private subnet instead of in your data center. The configuration
is almost the same. Note that this approach also allows the connectivity agent to
access any other resources that may be deployed in that same private subnet, s
uch as an Oracle Database Cloud Service or an Apache Kafka messaging cluster.
Let's now reverse the diagram to discuss deployment. First, within your OIC insta
nce, an OIC administrator defines a connectivity agent group which has a unique
identifier. Then the OIC admin downloads the agent installer as well as the config
file for that group, then installs the agent on a physical or virtual machine host,
where it will immediately start running and establish a connection to OIC. Note th
at the agent can be installed on any host machine from which it can establish a T
CP/IP connection to the applications and services it needs to reach. Now for high
availability, you can add one additional agent to that same agent group. Of cours
e, you'd typically install it on a separate host.
Additional agent groups can be used for functional process or organizational leve
l isolation, as well as access to other data centers or private cloud networks. In fa
ct, an OIC environment can have up to five agent groups defined with a maximu
m of two agents per group. Here are some other points to keep in mind. No ports
are opened on the firewall for communication since connections are established f
rom the agent. And all communication is secured using SSL and is initiated by th
e connectivity agent. In fact, it has no listening port and does not permit any exp
licit inbound connections. And since the agent functions as a lightweight stateles
s daemon service, there is no data ever persisted in the agent.
So let's now pivot to learn how the agent operates. Once deployed, the agent po
sts a regular heartbeat to the internal OIC SaaS agent to signal that it is alive an
d well. This is how OIC administrators can keep track of the health status of all co
nnectivity agents. Also, don't be concerned with the name of that background se
rvice. We call it a SaaS agent, but it has nothing to do with external SaaS applica
tions. It is only used to facilitate communications with connectivity agents.
Additionally, there is an internal message queue embedded within the OIC instan
ce, and it is the connectivity agent that continuously polls for any design time an
d runtime work that needs to be processed. Now design time work requests are d
elivered as a message to the queue via the SaaS agent, such as testing a connec
tion or using the configuration wizard on the integration design canvas. Then the
connectivity agent pulls that request from the queue, sends it on to the private r
esource, then delivers a response back to the queue, which is then picked up by
the SaaS agent and delivered to the design canvas.
The runtime work involves processing invoke messages from integration, instanc
es that need to be sent to private resources, such as databases, file systems, e-
business suite, Siebel, or any other private SOAP or REST endpoints. So when the
runtime invoke is made, it is sent to the SaaS agent, which queues the request m
essage, which is then pulled by the connectivity agent and sent to the resource.
Once there is a response, the agent sends it back to the queue where it is then d
elivered to the awaiting integration instance. If you're concerned about performa
nce, trust me, it looks way more complex than it is as there is very little latency
because under the covers, each of these requests and responses are handled as
ynchronously, which allows the agent to process messages very quickly. In additi
on, the agent is multithreaded, which allows it to process numerous concurrent r
equests while waiting on each thread for a response from the local resource.
Also, be aware that OIC will wait for a maximum of 240 seconds after it has poste
d a request for the agent. If no response or fault message is received within 4 mi
nutes, the flow instance times out and fails with a timeout error message. Finally,
for those use cases where the trigger role is used with a connection that is associ
ated with a connectivity agent, once the integration is activated, that agent will b
e responsible for pulling the resource, such as in this example with Apache Kafka
. It then sends that message to the internal queue, which will then cause the Saa
S agent to launch that integration instance with that trigger message.
Finally, let's briefly look at four example topologies, starting with this scenario, w
here all your private databases and applications are running in your data center.
And as we saw earlier, the agent can simply be installed in that same private net
work. On the other hand, if your private resources are all running in private cloud
networks, in this case, you could use two different agents to be deployed within t
hose OCI subnets dedicated to each resource. Then, of course, another agent ca
n be deployed to a virtual machine in that third party private cloud network.
To configure high availability for the agents, in this case, we can install two agen
ts assigned to the same agent group handling all inbound traffic for the data cent
er resources. Then for the OCI private resources, we could use a public subnet, a
dd two virtual machines, each hosting an agent, with both assigned to the same
group with routing configuration to access to both private subnets.
In this last scenario, we consider that the applications and databases themselves
have been configured for high availability. And this is most often achieved with lo
ad balancers placed in front of those resources, both in the cloud and on-
premises. So once again, as in the last scenario, we only need to configure high
availability by deploying two agents per agent group, both in the cloud and in th
e data center, which each enable to access all of their respective resources. Of c
ourse, if necessary, you could add additional agent groups that are dedicated to
each load balancer.
Well, that's it for this lesson. But as a reminder, in the OIC administrator tasks m
odule, there are these two additional videos. Thanks for watching.
Configuring Connections Module Overview
Welcome now to module 3, configuring connections. As the title indicates, these l
essons explain how to add a connection to an integration flow and configure it ba
sed on two separate scenarios. A trigger role connection, which serves as the ent
ry point for an application pattern integration and an invoke role connection, whi
ch can be used at any point in any integration flow to access some external syste
m or application.
You'll also see demos that show some examples of doing those configurations. A
nd once you complete these videos, don't forget to take the module 3 skill check.
Keep going strong.
Configuring Trigger Connections
Welcome. While this module is all about configuring connections within an integr
ation flow, in this lesson, we'll start by discussing the configuration of the trigger,
which is required for application pattern integrations. But first, since the integrati
on will be essentially deployed as a service, we need to review the general conce
pts regarding message exchange patterns for web services that receive requests
from clients, there are three basic patterns-- synchronous, which involves a requ
est that is sent to the service while the client blocks waiting for a response, eithe
r a reply or a fault message.
A one-way asynchronous pattern receives the request from the client. But instea
d of waiting for a response, the client immediately receives an acknowledgment
at the network socket layer that the request was received by the service, often c
alled an ACK, so there is no response. A two-way asynchronous pattern combines
an initial async request along with information as to where to send a callback to t
he client once the processing has been completed.
The other event-based patterns are always one way since there is not a response
message involved. But instead, there is a mechanism for the service to consume
the message, such as pulling a database or a messaging system or a file server,
or subscribing to receive an event-based message from an external system or ap
plication.
OIC can accommodate all these exchange patterns. However, which pattern your
new integration service will use will be determined by two things, the adapter ty
pe of your chosen trigger connection and, for most adapters, how you decide to c
onfigure that connection as the integrations trigger. Some adapter connections i
n the trigger role can only support event based polling such as with on premise fi
le systems or database triggers, while others can only register as a message sub
scriber on queues and topics such as with these adapters. Other types offer one
or more web service patterns for generic SOAP or REST clients, as well as various
application clients. Well, some adapter trigger connections can be configured as
a web service interface or as an event subscriber.
So revisiting the high-level development workflow that we discussed in an earlier
lesson, essentially, after you create the integration, if you choose the application
pattern, you must now select and configure the inbound trigger connection. Here
's how it works. When creating a new integration, once you select the application
pattern, you then provide a name. And when you click create, the design canvas
for your new integration will open, and you'll now be required to select one of the
trigger connections that is available to your project.
Selecting a connection will immediately launch the Adapter Configuration wizard,
allowing you to configure how the integration will be triggered. Of course, depen
ding on the adapter type, so as a REST API, or a SOAP web service or upon receiv
ing a business event, or perhaps the delivery of data from a connectivity agent p
ulling a file system or a messaging queue or even a database trigger. But once a
gain, as I mentioned in an earlier lesson, the options you have and the steps you
need to take with the Adapter Configuration wizard will very much depend on wh
ich adapter was used to define the trigger connection.
However, regardless of the adapter type, the workflow always starts with this co
nfigure basic info page popping in from the right side of the design canvas, wher
e you provide a name for this trigger endpoint and optionally, a meaningful descr
iption. Clicking the Continue button at the bottom will progress the Configuration
wizard to the next page. For some adapter types, such as with these Oracle SaaS
applications, this will take you to the Configure Request page, where you'll be pr
esented one or more options to progress with the configuration.
For other adapters, the next page will be different, such as the Configure Operati
ons page for a SOAP trigger or the REST trigger's Configure Resource Configurati
on page. Other types of adapters will present configuration pages corresponding
to that technology. The key point to remember is that, in most cases, the Adapte
r Configuration wizard is actually making a design time connection to that extern
al application, resource, or system, which is how it is able to not only present con
figuration pages specific to that adapter type, but is able to display options such
as custom business objects, events, or other unique metadata specific to that ext
ernal system.
So since we can't possibly cover the details for every adapter type in this course,
although we do show several examples, much less illustrate the myriad of unique
use cases associated with each adapter, it's important that you always consult th
e online documentation for that adapter. And there, you'll discover many additio
nal details and options related to configuring trigger connections. And so once th
e trigger connection is complete, you'll see the design canvas for your integratio
n flow with a layout depending on the integrations message exchange pattern. H
ere's an example of a trigger that will subscribe and receive a business event, ot
her adapter types pull for new messages such as this example for OCI streaming,
or it could be an asynchronous one way REST or SOAP-based web service.
What all of these have in common is that in addition to the trigger icon, the integ
ration design canvas will now display a stop action to indicate the end of the flow
. And you can now add additional actions and invokes to implement your integrat
ion flow logic. If the message exchange pattern, however, is a synchronous requ
est response web service, either REST or SOAP, instead of a stop action to indicat
e the end of the integration flow, a reply action is provided along with a map acti
on, which must be implemented to map the response data back to the client.
And to make it easier to add the implementation logic, you should know that reg
ardless of the actual format of the incoming data, whether it's JSON, XML, or a CS
V file or just template and query parameters, the source data or message will als
o be represented internally as an XML schema. And the same is true for any stru
ctured data that will be returned in the response.
Now, this is quite helpful later on when editing and the mapping canvas or some
other integration action that requires access to data within your integration flow.
We'll learn more about data mapping in future lessons. So to wrap up, once you'v
e selected a previously defined trigger connection to start your application patter
n integration, the Adapter Configuration wizard will launch a series of configurati
on pages to help you complete its configuration. That's it for this lesson. Thanks f
or watching.
REST Trigger Configuration
Welcome. In this lesson, we'll take a closer look at options for configuring REST tr
igger connections. How you will configure, though, depends on the use case. Wh
at will your integration do? Essentially, you're creating a REST API that will be us
ed by one or more external REST client applications. So what sort of operation wi
ll it be-- get, post, delete? What data, if any, do you need from the client? Will th
ey be sending an attachment? What data, if any, will you return? And will you ret
urn an attachment? Do you need to process any standard or custom headers sen
t by the client or perhaps define specific headers to send with the response?
So let's look at these options as the Adapter Configuration wizard presents seque
ntial configuration panes to allow you to define these various configuration optio
ns, starting with a relative resource URI for the operation and which HTTP metho
d action will be used. For example, a get method to retrieve a list of all products
might simply be /products. Decide if you need any required template parameters
. For example, a get operation to obtain info for a product might use a relative re
source URI of /product and prodID within curly braces for the template parameter
.
On the Configure Request Parameters pane, you may also need to define one or
more optional query parameters that can be sent and processed with a request.
For example, a department string to indicate the context of information that nee
ds to be returned. Also, notice on this pane that you can change the desired data
type of any template parameter you've already defined.
For put, post, and patch requests, you most often will need to define the request
payload. Just click this box which will enable this edit request configuration pane
where you have options such as providing a sample JSON file or indicating an XM
L schema. Likewise, unless you intend for an asynchronous message exchange p
attern, you'll want to define the schema for the response payload. By the way, if
you do wish to define a one way interface where the client only receives a netwo
rk acknowledgment when the request is received and no response, simply leave
this box unchecked. Otherwise, checking this box will enable this edit response p
ane, where once again your options include JSON, XML, or some other binary uns
tructured content.
You also have the option to specify if this integration should expect an attachme
nt from the client to be processed in addition to the request payload. Likewise, y
ou can set up the integration to return an attachment along with the response pa
yload. In fact, we'll see an example of this in the next demo video. Additionally, if
you select any of these checkboxes, the Adapter Configuration wizard will presen
t additional configuration panes, providing the opportunity for you to indicate an
y standard or custom HTTP headers you expect to process from the client reques
t or that you wish to return to the client in the response.
And if you select this checkbox, the wizard will add the Edit CORS Configuration
pane where you can indicate one or more allowed domains. By the way, if you're
unfamiliar, CORS stands for Cross Origin Resource Sharing, which defines a way i
n which a browser and a server can interact to determine safely whether or not t
o allow the cross origin request.
Finally, you can also add additional REST operations to the connection if you sele
ct this checkbox when you get started with the configuration wizard. What happe
ns is when you're done configuring the first one, you check to add another operat
ion, then configure it. Then at the end, you can do it again with support for up to
11 operations. Obviously, the only requirement is that each one must be a uniqu
e combination of resource URI and HTTP method. As in this example, this feature
eliminates the need to have to create multiple integrations with each one only ha
ving one operation defined.
When multiple operations are defined, once you exit the configuration wizard, th
e integration flow in the design canvas will automatically display a special pick tri
gger similar to a switch action, allowing you to define specific implementation log
ic within multiple branches corresponding to each defined operation. Of course, a
t runtime, only one branch will execute for any particular request. Notice here in
this example, these three operations are configured to return a response to the c
lient. While this delete operation was defined to have no response.
So to wrap up and review, it is totally up to you to consider your integration use c
ase designed to help guide you on the various options you have for implementin
g the configuration of its REST adapter trigger connection. That's it for this lesson
. Thanks for watching.
File Handling Fundamentals
Welcome. In this lesson, we'll cover the basic options you have for handling files
as you learn about some fundamental capabilities. When files arrive to your integ
ration flow instance, they are temporarily stored into a virtual file system. And in
some circumstances, they are also parsed and brought into memory, but more o
n that later.
The virtual file system stores all received files as well as new ones you may creat
e within the integration, but only for that instance. Other instances that may be r
unning at the same time or later on will have their own VFS. So then while you us
e it to store files that you create or have downloaded, essentially this storage is e
phemeral, and your files are not persisted beyond the life of that instance. Now f
or access, the stage file action has eight different file operations that you can us
e to work with files located in the VFS, and we'll look at those in just a moment.
So let's now pivot to talk about how we can receive files from external sources. T
here are several options. The most common pattern for retrieving files is to defin
e a schedule pattern integration with a configured FTP adapter connection used t
o access an external FTP server or even the embedded file server. So based on a
schedule, a new run will kick off and the FTP invoke connection will be used to re
trieve one or more files to be further processed. Or instead of a schedule to trigg
er the flow, another pattern is to implement a REST adapter connection as the tri
gger with the interface designed to expect one or more file attachments. So then
, when invoked by a REST client, those attachments are received into the integra
tion and can be processed as required.
On the other hand, if the file is located in a shared file system along with an insta
lled connectivity agent, you can configure a file adapter connection to be the trig
ger. The agent will pull the file system. And when a new file arrives, it will be deli
vered to OIC, triggering a new integration instance. However, regardless of how
your integration is designed to start, once it does, you can retrieve files at any ti
me. We just looked at the FTP adapter. And likewise, the file adapter can be used
in the invoke role to fetch a file whenever you want to retrieve it.
Or perhaps there is a RESTful web service that allows you to request files, which
can then be sent as an attachment in the response, or using the SOAP adapter to
invoke a SOAP-based web service that returns a file as an attachment, as a respo
nse. Additionally, there are some SaaS applications such as Oracle Commerce Cl
oud and Oracle Logistics Cloud that can respond with a file attachment when inv
oked from your integration. Another scenario would be to use the new object stor
age action to retrieve a file that has been staged in an OCI Object Storage bucket
.
But what about those use cases where you need to send processed files to exter
nal systems? And it doesn't really matter how your integration flow was triggered
or how it started. The same options apply. Again, the most common use case is l
everaging the FTP adapter to write the file to an external FTP server or the embe
dded file server. Or if it needs to be sent to a shared file system serviced by a co
nnectivity agent, you use the file adapter, or perhaps there is a RESTful web serv
ice that is looking to receive the file as a multi-part attachment, or if it is SOAP-
based, send it as an attachment using the SOAP adapter. Again, certain applicati
ons can receive file attachments when invoked, such as Oracle Taleo Enterprise
Cloud, receiving a resume or a candidate picture. Another use case is to send the
file to be stored in an OCI object storage bucket using the object storage action.
As to processing a received file or to create a new transformed file, as mentioned
earlier, you will use one or more stage file actions to accomplish your implement
ation. These operations are used on files that have been received with the read o
perations, bringing the contents into memory so they can be parsed. These oper
ations are used just prior to sending a file out to an external system. But as we'll
learn in other lessons, there is overlap of processing capabilities between the sta
ge file action and configured adapter connections for several of these operations.
For example, the FTP adapter also provides the capability to decrypt and encrypt
files.
And finally, throughout our documentation and in these trainings, we call out the
difference between structured files as opposed to opaque files. The reason is tha
t when sending or receiving files by way of the various adapters, there are limits
and different behaviors. For opaque files, you can download or send files of up to
one gigabyte in size. Structured files have a limit of 100 megabytes. Or if the ada
pter is being used in conjunction with a connectivity agent, the limit is 50mb.
And while both types of files will be staged in the virtual file system, structured fil
es will also be parsed into the integration instance memory, so their contents can
be exposed. The actual structured files themselves are those that have had their
contents defined by an XML schema, while opaque files can be unstructured such
as PDFs, image files, or a zip archive, or they could be larger structured files, but
the structure has not yet been defined. And that is why we can download or send
those files up to 1 gigabyte.
In other words, undefined structured would be opaque as opposed to defined str
uctured. Later, we'll learn how we can download or receive a large undefined str
uctured file, then bring it into memory in define structured segments to be proce
ssed. Or of course, a zip archive could contain one or more structured files that c
ould later be brought into memory to be processed as well.
And that brings us to the end of this lesson on file handling fundamentals. But th
ere is more to learn, so be sure to take a look at the additional videos that are in
this module. Thanks for watching.