Agent simplifies integration between cloud applications and enterprise on-premises applications

This article describes the infrastructure of Oracle's integrated cloud agent, the components it contains, and how to connect to cloud and op applications.

Current/Typical integration methods

The current common way to connect cloud applications/Internet-based applications to on-premises (OP) applications is to penetrate one or more firewalls, using reverse proxies, Oracle API Gateway, or OHS. Implementing these operations requires a variety of expertise, such as firewalls that require open inbound ports, exposing a private soap/rest service, and configuring network routing. Soap/rest services can be implemented with products such as the SOA suite, such as communicating with the CRM system to receive customer information. As shown in the following:

If you use an integrated cloud agent, you will be greatly simplified.

Common cloud and OP application integration patterns

There are three commonly used integration modes for cloud and OP applications, such as using message sending, using proxy services, and using agents.

• Proxy (synchronous/asynchronous)--hybrid cloud
  • Ability to access the OP-side SOA suite through network proxies deployed in the DMZ, such as Apigateway or OHS
  • The op-side SOA suite encapsulates the adapter so that the Cloud app can invoke
  • Integrated cloud service sends messages via proxy
• Message sending (asynchronous)--hybrid cloud
  • The op-side SOA suite fetches messages from the message service (Messaging service)
  • The op-side SOA suite packs the adapter so that messages can be sent
• Agent (synchronous/asynchronous)
  • Agent runs on the user's internal network
  • Agent establishes a communication channel with ICS
  • ICS sends messages to the agent through channels
  • The agent encapsulates the adapter and communicates with the OP application

What is a connection agent?

Basically the agent is a gateway between a cloud application and an OP application. The agent eliminates the security and complexity issues that have previously been encountered when integrating with OP applications from outside the firewall. The agent is able to connect to existing OP applications, such as a database or ERP, using a previous JCA adapter framework.

Message exchange pattern

When the cloud application communicates with the OP application, the agent conforms to several message exchange patterns.

Mode	Case
Synchronization requests sent from the cloud to OP are used to receive data	Get order status from EBS in real time
Event triggering for cloud applications and asynchronous message exchange for OP applications	Create an event in RightNow to raise a service request in EBS
Event triggering for OP applications and asynchronous message exchange for cloud applications	Update for EBS service requests data synchronization via asynchronous message to RightNow
Data synchronization extraction between OP applications and cloud applications	Synchronization of customer data in EBS to CRM

Architectural guidelines

The agent's architectural guidelines were created before it was developed.

• The most important guideline is that you do not need to open the inbound port when communicating with the OP application. This means that there is no need to create rules on the firewall to provide access. This avoids the problem of open ports being abused.
• Guideline two: It is not necessary to use (reverse) proxy, such as Apigateway or OHS, to expose a private soap interface based on a Web service.
• Guideline three: It is not necessary to deploy any OP applications in the DMZ area. The agent is installed on a local network that is able to access the backend system.
• Guideline IV: There is no need to use the existing Java EE container for agent deployment.
• Guideline Five: No IT staff is required to monitor the OP components. The agent is monitored using the monitoring interface in ICS.

Architecture

The agent consists of two components, the Cloud agent is installed on the ICS side, and the local agent is installed on the OP side. It uses the message cloud for message exchange and allows only connections to the Oracle cloud. It does not allow an explicit inbound connection. The agent invokes the OP application endpoint using the existing JCA adapter framework, such as database, file, and ERP (SIEBEL/SAP).

Characteristics

The agent is installed in silent mode and is registered with the integrated cloud service during installation. Once registered, the agent can test the connectivity with the OP application and data source through a ping operation initiated from ICS. When you design the ICS flow, the EIS metadata for the OP app is automatically fetched when the target data source is configured.

The Cloud agent is able to transfer the configuration using activation redirection to the OP locally. This means that the data source (EIS metadata) can be configured in ICS and transferred to the specified local agent. Further, the agent uses run-time redirection, allowing execution to be performed locally on the op. This means that when a target is added to the ICS agent, the message can be sent to the local agent using a message exchange.

ICS supports multiple agents for load distribution and high availability. For example, multiple agents can be used, each agent running on a different host. Agents can be grouped by function, process, or organization level.

Finally, the agent supports a variety of message exchange patterns (Cloud <-> local), such as synchronous request/response and post-launch regardless.

Components packaged together with the agent

The agent can be downloaded from ICS and installed locally.

The components included in the agent installation package are:

• WebLogic Server
• JRF
• Agent & Messaging Cloud Service (omsc) client
• OP Adapter

Finally, you will get a fully installed WebLogic server with domain, managed server, necessary client and JCA adapter.

Connecting the agent to ICS is simple, and during installation, users only have to provide the user name and password for the ICS authentication on the installation screen or on the command line.

installation process

The installation of the ICS agent is simple and contains only the following steps:

1, the installation program first for pre-installation inspection

A) version check to see if the installer is valid

b) Obtain the OMCS certificate and register the agent instance on ICS

2, after inspection, installation Weblogicserver

3. The installer executes the OPSS RCU and obtains the OMCS certificate, which is based on the built-in JAVADB implementation

4. OPSS creation and configuration complete, Setup creates a WebLogic domain that contains JRF

5, finally configure the agent, set up home directory and classpath and shared library, start agent

OMCS certification Process

In the third step, the certificate for the message cloud service is fetched and stored in the Certificate library (OPSS). When the user creates an agent instance in ICS, a AppID is created. AppID is used by all agents for authentication. When the user installs the agent, the Setup program receives the AppID and Omcs passwords from ICS.

The installer obtains the certificate to the OP side through an SSL-based rest interface. AppID and passwords are stored in the CSF library (OPSS) of the op-side WebLogic. The agent uses the SSL-based HTTP Basic authentication method with Omcs and ICS for authentication.

What connection does the agent support?

These adapters supported by the agent can establish a direct connection when communicating with ICS. The supported adapters include EBS, Siebel, SAP, Oracle DB, soap, and so on, and the supported adapters will continue to grow.

With the agent, hybrid cloud integration becomes simpler and more secure.

Agent simplifies integration between cloud applications and enterprise on-premises applications