You can use OracleAS InterConnect to integrate applications from Oracle, other software providers, or custom-built applications using message-oriented middleware. OracleAS InterConnect enables integration through modeling rather than relying on extensive programming techniques. Integration logic is separate from the integration platform. OracleAS InterConnect components include a hub, adapters, and a Development Kit. Figure 15-1 shows a typical deployment configuration.
The OracleAS InterConnect design and modeling tool, called iStudio, features easy-to-use wizards. Intended for use by business analysts, iStudio largely eliminates the need to write code when creating business rules and transformation integration logic. Users of iStudio can define and map data to be exchanged between applications, and can configure and deploy the integration. Objects can be locked within the tool, thus enabling multiple users to model and design simultaneously. OracleAS InterConnect supports metadata versioning so that multiple versions of the same object can coexist or be active at the same time. If business process collaboration is desired, Oracle Workflow can define the business processes. The iStudio tool is then used to associate semantic maps with these business processes.
Components connected with OracleAS InterConnect and created in iStudio are called application views . Application views include interest in specific messages, internal datatype identification, and information on how a message should be mapped to or from an internal datatype. A common view is a hub view in which each spoke is an application view participating in the integration. Figure 15-2 shows the hub-and-spoke nature of OracleAS InterConnect deployment between the common view and application views.
Common views can contain the following components:
Business objects
A collection of logically related integration pointslogical occurrences that trigger communications between applications
Event
An integration point used to model "publish and subscribe"
Procedure
An integration point used to model "request/reply"
Common datatype
Transformations, sometimes call mappings , are the integration points to application views.
Generated models and designs are stored in the OracleAS InterConnect metadata repository, which is part of a hub. At runtime, the metadata repository is the source of instructions enabling message exchange to occur. Runtime management, which is handled through Oracle Enterprise Manager, includes such management tasks as:
Starting and stopping components
Monitoring message flow
Performing problem detection
Handling error management
OracleAS InterConnect Adapters provide connectivity via a bridge, the protocol/application-specific portion of the adapter. The adapters transform and route messages between an application and the hub. Data is transformed from application views to common views and from common views to application views, as defined in the metadata repository. Figure 15-3 shows the architecture of an adapter.
A number of prepackaged OracleAS InterConnect adapters are available, including:
Technology Adapters
These adapters are used in cases where endpoints don't have APIs. They include Oracle database, Oracle AQ, MQSeries, HTTP/S, SMTP, FTP, and CICS.
Packaged Application Adapters
These adapters are used to integrate JD Edwards, PeopleSoft, SAP, and Siebel applications.
Adapter SDK
The SDK enables the creation of adapters for applications and protocols that aren't supported by other adapters. The kit is a collection of Java JAR and Javadoc files.
Messages are commonly communicated using database adapters, Oracle AQ, or XML messaging, or through the Data Definition Description Language (D3L). All OracleAS InterConnect messages are guaranteed to be delivered exactly once in the order sent. Messages can be load-balanced across multiple adapters using Real Application Clusters (RAC), a clustered Oracle database configuration. Routing of messages can be implemented using business rules based on message content.
OracleAS InterConnect supports two distinct models:
Publish and subscribe
With this model, applications may be subscribers. These subscribers receive messages whenever they are published by specific applications. When this model is used, the publishing application doesn't expect a reply.
Request/reply
Alternatively, an application may publish a message and expect a reply either in synchronous mode (the message can't be received until the reply is sent) or asynchronous mode (the reply is sent after message reception).
Both publish and subscribe and request/reply messaging can behave in a point-to-point manner if the sending application calls out which specific application should receive a message.
Values in one application can be mapped to equivalent values in another application by defining domain value maps using iStudio. Keys for corresponding entities in two different applications can also be correlated using iStudio.
The interface in the i Studio modeling and design tool consists of two navigation trees for design and deployment, as well as five main menus.
Here are the navigation trees:
Design Navigation Tree
Groups objects as Common Views, Applications, Workflow, and Enabling Infrastructure
Deploy Navigation Tree
Groups objects as Applications or Workflow
File Menu
Handles creating and opening existing projects and workspaces, project reloading, object creation and migration, export of PL/SQL stubs, and metadata push to adapters
Edit Menu
Handles editing, copying, deleting, versioning, or loading objects, renaming applications, adding or removing applications from domain value maps or cross-reference tables, and deploying events to or editing Workflow configurations
Procedure Menu
Handles invoking or implementing procedures via wizards
Event Menu
Handles publishing or subscribing to events via wizards
Help Menu
Handles access to the iStudio User's Guide
Figure 15-4 shows a typical view of the iStudio interface and the Design Navigation Tree.
The Oracle Workflow for Java (OW4J) engine can be used with OracleAS InterConnect to enable business process definition, automation, and integration. Oracle Workflow for Java enables execution of a sequence of events in a specific order. You can view the progress of processes through these sequences via either monitors or notification methods (for example, JMS messages and email). The following components are part of OW4J:
Workflow Builder
Provides a graphical business process-modeling tool
Workflow Engine
Manages business process execution and exception handling
Business Event System
Provides a Java API for propagating events
Process Monitor
Used to view and administer events
Directory Service
Enables OracleAS Single Sign-On, synchronization with the Oracle Internet Directory, and integration with LDAP
Workflow Manager
Monitors system metrics and processes, and configures and monitors notification mailers
Business process models are typically created using the JDeveloper OW4J Modeler as the Workflow Builder. Business processes might be either short or long. Very short business processes are served by in-memory workflows. Long-lived tasks may extend to weeks and beyond.
Version numbers are automatically assigned to workflow tasks, thus enabling different versions of activities.
Models of these processes can be built to include logic for looping, branching into parallel flows and rendezvous, decomposing into subflows, branching into subtasks, and others. Escalation processes can be created and then executed after periods of inactivity based on predefined rules. Notification routing can also be set up to handle typical occurrences such as delegation of responsibility or rerouting during absence of a participant.
The Process Monitor provides a Java applet to review business activities that have been completed, are active, or are yet to be initiated. Decision makers are identified and their responses are shown. Administrators can intervene to explore stopped processes or to skip or retry processes. It is possible to review the time and cost of business processes by exploring workflow processing data stored in an audit database.
The Workflow Manager interface is exposed through Oracle Enterprise Manager. Work items and event messages can be viewed (including the distribution of event messages by status). This interface enables administrators to more quickly determine business bottlenecks.
A typical OracleAS InterConnect deployment sequence includes the following steps:
Configure a source triggering mechanism (such as through Oracle AQ).
Create a new project in iStudio.
Create common view business objects in iStudio and business object events.
Create an iStudio application in which an adapter communicates with a business application.
Create a cross-reference table mapping keys between systems using iStudio applications.
Create published events in iStudio that map application views to common views, perform transformations, and publish new events to subscribers.
Subscribe applications to events in iStudio.
Create content-based routing in iStudio if required (e.g., routing based on message or message header contents via Oracle Workflow with appropriate applied business logic).
Create an Oracle Workflow process bundle in iStudio if business logic is to be applied (including a bundle name, business process, and publish-and-subscribe activities), and then deploy it.
Create objects in Oracle Workflow for modeling, and then model business logic.
Deploy application queues in iStudio, and test the integration prior to final production deployment.