4
Runtime System Concepts and Compents

This chapter describes the runtime concepts, components and processes of Oracle Applications InterConnect.

This chapter discusses the following topics:

• Integration Architecture

• Features

• Components

Integration Architecture

Oracle Applications InterConnect runtime is an event-based distributed messaging system. An event is any action that initiates communication through messaging between two or more applications integrated through Oracle Applications InterConnect. The messaging system can be deployed both within an enterprise or across enterprise boundaries.

The runtime enables inter-application communication through hub and spoke integration. This methodology keeps the applications decoupled from each other by integrating them to a central hub rather than to each other directly. The applications are at the spokes of this arrangement and are unaware of the applications they are integrating with. To them, the target of a message (or the source) is the hub. Since each application integrates with the hub, translation of data between the application and hub (in either direction) is sufficient to integrate two or more applications.

Features

The Oracle Applications InterConnect runtime features are as follows:

• Messaging Paradigms

• Message Delivery

• Message Retention

• Routing Support

• Error Management

• Scalability and Load Balancing

Messaging Paradigms

Oracle Applications InterConnect runtime supports three major messaging paradigms:

• Publish/Subscribe

• Request/Reply (synchronous and asynchronous)

• Point-to-Point

These paradigms can be configured on a per integration point basis. Refer to Chapter 2, "Design Time Concepts and iStudio" for detailed explanation on what these paradigms are and how to configure Oracle Applications InterConnect to utilize a specific paradigm for an integration point.

Message Delivery

Guaranteed delivery

All messages are guaranteed to be delivered from the source application(s) to the destination application(s).

Exactly once delivery

The messages are neither lost nor duplicated. The destination application(s) will receive each sent message exactly once.

In order delivery

The messages are delivered in the exact same order as they were sent.

Message Retention

Messages remain in the runtime system until they are delivered. Advanced Queues in the hub provide the message retention. The messages are deleted when each application that is scheduled to receive a specific message has received that message. For auditing purposes, you can configure the system to retain all messages even after they have been delivered successfully to each application.

Routing Support

The current version of Oracle Applications InterConnect has significant improvements over the previous releases for configuring your routing needs. Routing is a function of the Advanced Queues in the hub. By default, there is only one multiconsumer Advanced Queue configured to be the persistent store for all messages for all applications--oai_hub_queue. This will handle all your standard as well as content based routing needs. Morever, this queue is created automatically when you install the repository in the hub. The only reason to change this configuration is if Advanced Queues becomes a performance bottleneck. For most scenarios, this is unlikely because most of the message processing is done in the adapters, not in the hub. For information on how to address performance bottlenecks in the adapters, see "Scalability and Load Balancing".

Content-Based Routing

Content-based routing allows you to route messages to specific destination applications based on message content. For example, an electronic funds transaction settlement application is designed to transmit bank transactions with a specific bank code to identify the destination bank system. When the electronic funds transfer application publishes each message at runtime, the Oracle Application InterConnect runtime component determines the BankCode value based on objects stored in the repository, and routes the message to the appropriate recipient system.

Error Management

This release has significant improvements to deal with error conditions in your integration environment:

• Central Logging--If there is an error in the system, it is logged centrally in the repository.

• Central Monitoring--These errors can be monitored through the runtime management console.

Resubmission

You can resubmit errored-out messages again into your integration environment for processing after modifying them (if required) using the runtime management console.

Tracing

You can modify the .ini files of adapters to turn up the tracing level to troubleshoot errors. You can view the tracing logs by opening up log files through the runtime management console.

Tracking

Messages can be tracked by specifying tracking fields using iStudio. The runtime system checkpoints state at certain pre-defined points so that you can monitor where the message is currently in the integration environment. This tracking capability can be utilized through the runtime management console.

Scalability and Load Balancing

At runtime, it is possible that the adapter attached to a particular application becomes a performance bottleneck. You can detect this by monitoring the message througput information through the runtime console. For more information, see Chapter 5, "Runtime Management".

Oracle Applications InterConnect addresses adapter scalability through a well-defined methodology:

Multiple adapters can be attached to one application to share the message load. This can be done in several ways depending upon the needs of your integration environment. For example, Application A publishes three different kinds of events--EventA, EventB, and EventC. Three potential scenarios should be examined to determine how one or more adapters should be attached to the application to meet performance objectives:

Scenario 1

• Requirement

  The order in which the messages are sent by Application A must be adhered to strictly for the life of all messages. For example, if Application A publishes messages in a specific order, they must be received by the subscribing applications in the exact same order across all the different event types.

• Solution

  In this case, you cannot add more than one adapter to Application A for load balancing.

Scenario 2

• Requirement

  The order in which messages are sent by Application A must be adhered to but not across different event types. For example, Application A publishes the following messages in order: M1_EventA, M2_EventB, M3_EventA. M1 and M3 must be ordered with respect to each other because they correspond to the same event type. However, M2 has no ordering restrictions with respect to M1 and M3. In addition, EventA messages are transformation/size/computation heavy and EventB and EventC messages are very light.

• Solution

  In this case, you can create message partitions in the Message Capability Matrix. Refer to Chapter 2, "Design Time Concepts and iStudio" for more details on how to configure the Message Capability Matrix. Partition1 can process EventA messages, and Partition2 can process EventB and EventC messages. When you install the adapters, you specify not only the application it is attached to but also the partition it uses. These message partitions can be used to effectively load balance message processing.

Scenario 3

• Requirement

  There is no message order dependency, even within the same event type.

• Solution

  Since there are no ordering restrictions, two approaches for load balancing can be employed:

  • No message partitions are created. One or more adapters are added utilizing the entire Message Capability Matrix. This means that at runtime any one of the adapters would be available to receive any message, though only one of them would actually receive the message. Which adapter receives the message will be determined solely by which adapter is the first to request the next message for processing.

  • Message Partitions can be created based on projections of the number of messages for a particular event type. For example, if there will be three times as many EventA messages than EventB or EventC messages, you could create two partitions--one for handling EventA messages, and the other for handling the other two event types.

Components

There are four major components in the runtime system:

• Adapters

• Repository

• Advanced Queues

• Workflow

Adapters

Prepackaged adapters help re-purpose applications at runtime to participate in the integration without any programming effort.

Agent and Bridge Combination

Adapters are the run-time component for Oracle Applications InterConnect. Adapters have the following responsibilities:

• Application Connectivity--Connect to applications to transfer data between the application and Oracle Applications InterConnect. The logical sub-component within an adapter handles this responsibility is called a bridge. This is the protocol/application-specific piece of the adapter that knows how to communicate with the application. For example, the database adapter is capable of connecting to an Oracle database using JDBC and calling SQL APIs. This sub-component does not know which APIs to call, only how to call them.

• Transformations--Transform data from the application view to common view and vice versa as dictated by the repository metadata. In general, adapters are responsible for carrying out all the runtime instructions captured through iStudio as metadata in the repository. Transformations are an important subset of these instructions. The logical sub-component within an adapter that handles the runtime instructions is called an agent. This is the generic runtime engine in the adapter that is independent of the application to which the adapter connects. It focuses on the integration scenario based on the integration metadata in the repository. There is no integration logic coded into the adapter itself; all integration logic is stored in the repository. The repository contains the metadata that drives this sub-component. In the database adapter example, this is the sub-component that knows which SQL API's to call, but not how to call them. All adapters have the same agent code. It is the difference in metadata that each adapter receives from the repository that controls and differentiates the behavior of each adapter.

Adapters can be configured to cache the metadata at runtime to address performance needs. There are three settings for caching metadata:

• No Caching--For each message, the adapter will query the repository for metadata. This setting is recommended for an early or unstable integration development environment.

• Demand Caching--The adapter will query the repository only once for each message type and then cache that information. For subsequent messages of the same type, it will use the information from the cache. This setting is recommended for a stable integration development environment.

• Full Caching--At start-up time, the adapter will cache all its relevant metadata. This setting is recommended for a production environment.

The following adapters are available with Oracle Applications InterConnect:

• Oracle Database Adapter--Allows you to communicate to an Oracle database using JDBC. The database adapter is certified against Oracle database version 7.x to 8.1.7.

• Oracle Advanced Queue Adapter--Allows you to communicate to an Advanced Queue with Raw, XML, and ADT payloads. This adapter can work on Oracle database version 8.1.6 and 8.1.7.

• HTTP/S Adapter--Allows you to communicate across firewalls with an HTTP/S server using XML payloads.

• SAP Adapter--Allows you to communicate to as SAP system using BAPIs, ABAP modules, and Idocs inbound into SAP and Idocs for outbound. This adapter is SAP certified and can work with all SAP versions 3.1H onwards.

Repository

The repository consists of two components:

• Repository Server--A Java application that runs outside the database. It provides CORBA services to create/modify/delete metadata at design time using iStudio and query during runtime using adapters. Both adapters and iStudio act as CORBA clients to communicate with the repository server.

• Repository Database--The repository server stores metadata in database tables. The server communicates to the database using JDBC.

  

Adapters have the ability to cache metadata. If the repository metadata is modified after adapters have cached metadata, those adapters are automatically notified by the repository server to purge their caches and re-query the new metadata.

Advanced Queues

Advanced Queues provide the messaging backbone for Oracle Applications InterConnect in the hub. In addition to being the store and forward unit, they provide message retention, auditing, tracking, and guaranteed delivery of messages. For more information on Advanced Queues, see the Oracle Database Application Developer's Guide

Workflow

Oracle Workflow facilitates integration at the business process level through its Business Event System. Oracle Applications InterConnect and Oracle Workflow are integrated to leverage this facility for business process collaborations across applications.