1 Introduction

Adapter Features

The Oracle Application Server Adapter for Siebel provides a means to exchange real-time business data between Siebel systems and other applications, databases, or external business partner systems. The adapter enables external applications for inbound and outbound processing with Siebel.

OracleAS Adapter for Siebel can be deployed as a J2EE Connector Architecture (J2CA) version 1.0 resource adapter. This deployment is referred to as OracleAS Adapter J2CA. It can also be deployed as a Web services servlet and as such is referred to as Oracle Application Server Adapter Business Services Engine (BSE).

OracleAS Adapter for Siebel uses XML messages to enable non-Siebel applications to communicate and exchange transactions with Siebel using services and events. Services and events are defined as follows:

• Services: Enables applications to initiate a Siebel business event.

• Events: Enables applications to access Siebel data only when a Siebel business event occurs.

To support event functionality, the following two features are implemented:

• Port: A port associates a particular business object exposed by an adapter with a particular disposition. A disposition defines the protocol and location of the event data. The port defines the end point of the event consumption. The port is the adapter component that pushes the event received from the enterprise information system (EIS) to the adapter client.

  
  

  Note: You do not need to create or configure ports for use with BPEL Process Manager.

  
  

• Channel: A channel represents configured connections to particular instances of back-end or other types of systems. A channel binds one or more event ports to a particular listener managed by an adapter.

  The channel is the adapter component that receives events in real time from the EIS application. The channel component can be a File reader, an HTTP listener, or an MQ listener. A channel is always EIS specific. The adapter supports multiple channels for a particular EIS. This enables the user to choose the optimal channel component based on deployment requirements.

OracleAS Adapter for Siebel:

• Supports synchronous and asynchronous, bidirectional message interactions for Siebel Business Services, Business Components, and Integration Objects.

• Includes Oracle Application Server Adapter Application Explorer (Application Explorer), a GUI tool that uses the Siebel Object Manager to explore Siebel metadata and build XML schemas or Web services.

• Supports Siebel transports—MQSeries, File, and HTTP. It also supports MSMQ messaging.

• XML schemas for OracleAS Adapter J2CA.

• Web services for BSE.

Oracle Application Server Adapter Business Services Engine (BSE) Architecture

Figure 1-1 shows the generic architecture for the Oracle Web service adapter for packaged applications. The adapter works in conjunction with BSE, as deployed to a Web container in a J2EE application server. BSE serves as host to the adapters, enabling Web service requests to the adapters.

Application Explorer, a design-time tool deployed along with BSE, is used to configure adapter connections, browse EIS objects, configure services, and configure listeners to listen for EIS events. Metadata created while you perform these operations are stored in the repository by BSE.

BSE uses SOAP as a protocol for consuming requests from clients, interacting with the EIS, and sending responses from the EIS back to clients.

Oracle Application Server Adapter Generic J2CA Architecture

Figure 1-2 shows the generic architecture for the OracleAS Adapter J2CA for packaged applications. The OracleAS Adapter J2CA is deployed to a standard J2CA container and serves as host container to the adapters. The connector is configured with a repository.

Application Explorer, a design-tool that works in conjunction with the connector, is used to configure adapter connections, browse EIS objects, configure services, and configure listeners to listen for EIS events. Metadata created while you perform these operations are stored in the repository by the connector. The repository can be a file system or an Oracle database. It is deployed as a RAR file and has an associated deployment descriptor called ra.xml. You can create multiple connector factories by editing the OC4J deployment descriptor oc4j-ra.xml. See Chapter 3, "OC4J Deployment and Integration" for more information on OC4J deployment.

The Siebel Application Model

The Siebel Enterprise application defines a data abstraction layer that removes dependencies on the underlying database. It accomplishes this by using intermediate Business Components and Business Objects that represent database structures. A Business Component usually represents a table in a database. A Business Object is a group of related business components.

From a given business component, you can navigate the relationships defined for that component to another component. The path you use to traverse component relationships is called the navigation path. For example, if you want to obtain all addresses for a particular account, you can traverse the parent/child relationship between Account and Address to obtain those addresses. By using navigation paths, you can traverse nearly all of the business component relationships defined in the Siebel system.

In Siebel, Integration Objects are similar to Siebel Business Components but describe more complex hierarchal data relationships.

Integration with Siebel

You can use OracleAS Adapter for Siebel to initiate a Siebel business process, such as add/update account, or you can use the adapter as part of an integration effort to connect Siebel and non-Siebel systems. OracleAS Adapter for Siebel is bidirectional and can detect an event from Siebel by receiving a Siebel XML document emitted by Siebel.

When integrating with Siebel using Siebel XML documents, the adapter application developer must use existing Siebel Integration Objects or create new Siebel Integration Objects to use within a Siebel Workflow. The Workflow processes inbound or outbound Siebel XML and uses various transports such as MQSeries, File, and HTTP to exchange transactions with external systems. The Siebel Workflow is usually created by the Siebel administrator or developer using Siebel Workflow Administration screens.

When integrating with Siebel directly using the Java Data Bean or COM Data Interface, OracleAS Adapter for Siebel does not require a Siebel Integration Object or Siebel Workflow. Instead, it executes Siebel Business Services and Siebel Business Components directly.

The following table lists Siebel objects and processes.

Using Application Explorer with OracleAS Adapter for Siebel

Application Explorer uses an explorer metaphor for browsing the Siebel system for Business Services, Business Objects, Business Components, and Integration Objects. The explorer enables you to create XML schemas and Web services for the associated object. External applications that access Siebel through OracleAS Adapter for Siebel use either XML schemas or Web services to pass data between the external application and the adapter.

Application Explorer uses interfaces provided by Siebel and in-depth knowledge of the Siebel application systems to access and browse business object metadata. After an object is selected, Application Explorer can generate an XML schema or Web service to define the object for use in conjunction with OracleAS Adapter for Siebel.

Key features of Application Explorer include:

• The ability to connect to and explore a variety of application systems.

• Access to application system object metadata.

• A point-and-click process for generating XML schemas and Web services.

BSE Versus OracleAS Adapter J2CA Deployment

If using OracleAS Adapter for Siebel with BPEL Process Manager, please note that:

• Only OracleAS Adapter J2CA deployment supports inbound integration (event notification) with BPEL Process Manager.

• Both OracleAS Adapter J2CA and BSE deployments support outbound integration (request-response service) with BPEL Process Manager.

The following four factors explain the differences between deploying BSE and the OracleAS Adapter J2CA. Understanding the factors can help in selecting a deployment option.

1. BSE is the preferred deployment option because it:

   • Can be deployed in a separate instance of the Oracle Application Server.

   • Provides better distribution of load.

   • Provides better isolation from any errors from third party libraries.

   • Provides better capability to isolate issues for debugging purposes.

   • Conforms more closely to SOA model for building applications.

2. OracleAS Adapter J2CA provides slightly better performance

   OracleAS Adapter J2CA does provide slightly better performance than BSE; however, the difference decreases as the transaction rate increases.

3. OracleAS Adapter J2CA and the BSE option both provide identity propagation at runtime

   The BSE option provides the capability to pass identity using the SOAP header. For the OracleAS Adapter J2CA, user name and password can be passed using the connection spec of the CCI.

4. Transactions

   Because no adapters currently being sold by Oracle support XA transactions, transactions are not a consideration when choosing between J2CA and BSE.