9 Run-Time System Concepts and Components

Agent and Bridge Combination

Adapters are the run-time component for OracleAS Integration InterConnect. Adapters have the following features:

• Application Connectivity: Connect to applications to transfer data between the application and OracleAS Integration InterConnect. The logical subcomponent within an adapter that handles this connectivity is called a bridge. This protocol/application-specific subcomponent of the adapter 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 subcomponent does not know which APIs to call but only how to call them.

• Transformations: Transform data to and from the application view to common view as dictated by the repository metadata. In general, adapters are responsible for carrying out all the run-time instructions captured through iStudio as metadata in the repository. Transformations are an important subset of these instructions. The logical subcomponent within an adapter that handles the run-time instructions is called an agent. This is the generic run-time 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 subcomponent. For example, in a database adapter, the agent subcomponent knows which SQL APIs 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 each adapter.

Adapters can be configured to cache the metadata at run time 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 startup time, the adapter will cache all its relevant metadata. This setting is recommended for a production environment.

  
  

  Note: For more information about the adapters provided by OracleAS Integration InterConnect, refer to Oracle Application Server InterConnect Installation Guide.

  
  

Adapters are stateless by default. As a result, in case an adapter is not working, the message is either with the application or in the OracleAS Integration InterConnect Hub.

Content-Based Routing

Content-based routing enables 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 a message at run time, the OracleAS Integration InterConnect run-time component determines the bank code value based on metadata stored in the repository, and routes the message to the corresponding recipient system.

Partitions

OracleAS Integration InterConnect uses partitioning to manage load balancing across different instances of the same adapter. At run time, it is possible that the adapter attached to a particular application becomes a performance bottleneck. You can detect this by monitoring the message throughput information using the InterConnect Manager.

You can create multiple partitions of an application to enable an adapter to share the message load at run time. Partitions are always bound to specific events or procedures. We can create partitions on one or more events and procedures.

For example, application AQAPP is publishing the Create_Customer event and subscribing to the Delete_Customer event. You can create two partitions P1 and P2 on AQAPP. You can specify that partition P1 handles all the messages from the Create_Customer event and partition P2 handles all the messages from the Delete_Customer event. In partitioning, the messages are processed in same order in which the publishing application sends the messages. If there is only one instance of each partition, then the order of the messages is maintained on per-event or per-procedure basis. Perform the following steps to create multiple partitions of an application:

Design Time:

Perform the following design time steps in iStudio to create a partition:

1. Click the Deploy tab.

2. Click Applications, ApplicationName, and then click Routing.

3. Right-click Message Capability Matrix and select Create Partition.

4. Enter the name of the partition in Partition Name field.

   
   Description of the illustration 9_3_5_1b.gif
   
   

5. In the Available Events list, select each of the events that you want to include.

   
   Description of the illustration 9_3_5_1c.gif
   
   

6. Click the right-arrow button and then click Add.

Run Time

Perform the following run-time steps to create a partition:

1. Use the copyAdapter script to make a copy of the existing adapter in the same Oracle home. Enter the following command:

   c:\> cd ORACLE_HOME\integration\interconnect\bin
   c:\> copyAdapter AQAPP AQAPPTEMP
   

2. Edit the adapter.ini file of each adapter located in ORACLE_HOME/integration/interconnect/adapters/ADAPTERNAME directory.

   • Change the application parameter value to the old application name. For example, AQAPPTEMP to AQAPP.

   • Delete the comment tags before the partition parameter and specify the partition name.

   • Specify the application name followed by the partition name in the agent_subscriber_name parameter. For example, AQAPPP1.

   • Specify the application name followed by the partition name in the agent_message_selecter parameter.

   
   

   Note: The name of the application in the adapter.ini file and iStudio should be same.

   
   

Instances

You can create multiple instances of an adapter to share the message load. Instances are always bound to an application. If an adapter is receiving a large number of messages and is not able to process these messages efficiently, then it is recommended that you create multiple instances of the adapter. Messages are shared between the multiple instances. However, the messages are not processed in the same order in which publishing application sends the messages. Therefore, the in-order message delivery is lost.

In partitioning, the adapter subscribes to the hub queue with application_name+partition_name whereas in instances, the adapter subscribes to the hub queue with only application_name. Therefore, all the instances of an adapter that correspond to an application can listen to all the messages for that application. AQ handles delivering the message to only one of them. For example, DB1 and DB2 are two instances of the Database adapter and both instances are bound to an application DBAPP. When publishing a message, both instances publish the messages with the publisher name DBAPP. The adapter instance that reads the message first will publish the message and delete it from the OAI schema. This ensures that the duplicate messages are not published. Similarly, when subscribing to a message, both adapter instances subscribe to the hub queue with the same application name. Although both can listen to all the messages meant for DBAPP, a message will be delivered to either DB1 or DB2.

Perform the following steps to create multiple instances of an adapter:

1. Use the copyAdapter script to make multiple copies of the existing adapter in the same Oracle home.

   c:\> cd ORACLE_HOME\integration\interconnect\bin
   c:\> copyAdapter copyAdapter AQAPP AQAPPTEMP
   
   

2. Edit the adapter.ini file of the each newly created adapter. The adapter.ini file is located in the ORACLE_HOME/integration/interconnect/adapters/ADAPTERNAME directory.

   1. Change the value of the application parameter to the old application name, for example AQAPPTEMP to AQAPP.

   2. Delete the comment tags before the instance_number parameter.

   3. Specify the instance number in the instance_number parameter.

Load Balancing with Multiple Adapters

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 could be attached to the application to meet performance objectives.

Scenario 1

The order in which the messages are sent by application A must be strictly adhered to for the life of the messages. Messages sent by application A must be received by the subscribing applications in the same order across the different event types.

Recommendation In this case, you cannot add more than one instance of the same adapter to Application A for load balancing.

Scenario 2

The order in which messages are sent by Application A must be adhered to but not across different event types. Application A publishes the following messages in order: M1_EventA, M2_EventB, M3_EventA. M1_EventA, and M3_EventA must be ordered with respect to each other because they correspond to the same event type. M2_EventB has no ordering restrictions with respect to M1_EventA and M3_EventA.

Recommendation In this case, you can leverage the partitioning feature enabled through iStudio's Deploy tab. This feature enables you to allocate specific adapters for specific message types, thereby segmenting the run time load processing. For this scenario, you can create two partitions: Partition1 corresponds to EventA and Partition2 corresponds to EventB. Dedicate one adapter to each partition (specified at adapter install time or through modification of adapter.ini after install). The end result: The order of messages is maintained and the processing power has doubled because of two adapter servicing the messages instead of just one. This kind of partitioning is called Message-based partitioning.

Scenario 3

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

Recommendation Two approaches for load balancing are available:

1. One or more adapters are added using the entire message capability matrix. This means that at run time, any one of the adapters would be available to receive any message, though only one of them would actually receive the message. The adapter that is first to request the next message for processing will determine the adapter that will receive the message. This is called Pure Load Balancing partitioning.

2. Message-based partitions are 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, then you could create two partitions, one for handling EventA messages, and the other for handling the other two event types. Now, you can dedicate several adapters to handle the EventA message load only. Fewer adapters can be dedicated to the other two event types.

Adapter Failover Mechanism

In the earlier OracleAS Integration InterConnect releases, the adapters failed over to the next node in the Real Application Clusters environment for any exception. This release changes the adapter failover mechanism. The adapters are designed to fail over only when the corresponding node fails. This means that a normal exception will not cause a failover to be triggered. Instead, the adapter will fail over only when the node itself fails.