15 Designing Application Business Connector Services

This chapter provides an overview of Application Business Connector Services (ABCS) describes how to define the ABCS contract, identify the MEP and discusses technology options for outbound interaction with the application and how to use BPEL for building ABCS.

This chapter includes the following sections:

15.1 Introduction to ABCS

The role of the ABCS is to expose the business functions provided by the participating application in a representation that is agreeable to Enterprise Business Services (EBSs). It can also play another role in which it serves as a glue to allow the participating application to invoke the EBSs. Figure 15-1 illustrates a scenario in which the E-Business Suite application is using an ABCS to invoke an EBS. In this scenario, the ABCS is playing a requester role. The same diagram also illustrates how the EBS invokes one of three ABCS to perform a specific task. Here, the three ABCS are playing provider roles.

Figure 15-1 ABCS in Oracle AIA Architecture

The image is described in the surrounding text

The ABCS enables participating applications to become service providers and service consumers. It also enables applications having nonstandard connectivity to expose their functionality as web services.

For more information about ABCS, see "Understanding Application Business Connector Services" in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

15.1.1 ABCS Types

The two types of ABCSs are:

15.1.1.1 Requester ABCS

The requester ABCS is provided by the requesting application to interface with an EBS for performing a single task. The service interfaces between Requesting/Source application and EBS. The role of the requester ABCS is to enable the participating application to invoke the EBS either to access data or to perform a transactional task.

The requester ABCS is a service provided by the requesting application to invoke the EBS. It receives the Application Business Message (ABM) as payload and optionally returns the ABM as the response.

The ABM can be enriched by having additional conversations with the requester application. The ABM is transformed into an Enterprise Business Message (EBM) using XSL. Responses received from the EBS (EBM) are transformed into the ABM.

Non-SOAP payloads are handled by having transport adapters in between requester application and requester ABCS. Requester applications must pass system information for the ABCS to have subsequent conversations.

15.1.1.2 Provider ABCS

The provider ABCS is supplied by the provider application to interface with an EBS for performing a single task. The service interfaces between the EBS and provider or target application.

The provider ABCS:

  • Is a service supplied by the provider application to interface with the provider application

  • Receives EBM as payload

  • Optionally returns the EBM as the response

The EBM is transformed into an ABM using XSL. The ABM can be enriched by having additional conversations with the provider application. Responses received from the application (ABM) are transformed into the EBM.

Non-SOAP connectivity with the provider application is handled by having transport adapters in between the provider ABCS and the provider application.

For more information about ABCS, see "Understanding Application Business Connector Services" in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

15.1.2 Designing ABCS - Key Tasks

An ABCS architect or developer must perform the following tasks as part of the design activity:

  • Understand the ABCS role

  • Identify the business events triggering the invocation of ABCS

  • Identify the interactions between application and the ABCS and vice versa

  • Identify the appropriate technologies to be used to facilitate the interaction

  • Define the ABCS contract

The following sections discuss these tasks:

15.2 Defining the ABCS Contract

The ABCS contract (WSDL) specifies how a caller interacts with its Business Connector Service. The caller could either be a participating application or another service such as EBS.

Figure 15-2 illustrates the decision flow for defining the contract (WSDL) for the ABCS.

Figure 15-2 Decision Flow for Defining the ABCS Contract

The image is described in the surrounding text

15.2.1 Defining the Role of the ABCS

This section discusses design decisions that you must make to enable the ABCS to participate in either a requester or provider role.

15.2.1.1 Designing an ABCS to Participate in a Requester Role

To determine how to enable the ABCS to participate in a requester role:

  1. Determine how the ABCS is invoked or triggered. This analysis tells you how the ABCS is invoked by the application. Determine:

    1. Whether the application can make a SOAP-based invocation of ABCS.

    2. Whether the application service can invoke the ABCS using JCA adapter.

    3. Whether the ABCS must subscribe to messages published by the application due to occurrence of business events.

  2. Determine what interaction pattern is needed.

    The following questions help the architect identify the optimal message exchange pattern.

    1. What business events cause the invocation of requester ABCS?

    2. Is the application expecting a response from the requester ABCS?

    3. Should the application wait until the response is received for performing the next task?

    4. Should the application wait until the request is fully processed by the provider application?

    For more information about choosing a MEP, see Section 15.3.2, "Choosing the Appropriate MEP."

  3. Determine what Enterprise Business Services or operations must be invoked.

  4. Does the message sent by the requester application have all the information necessary for requester ABCS to construct the EBM?

    1. If not, does it have to reach out to applications to get the additional information?

    2. If yes, what technologies are available? What application interfaces are to be used to get the additional information?

    For more information, see Section 15.4, "Technology Options."

  5. Can the application possibly publish a message with incomplete information?

    1. Should the ABCS wait until the message with complete information is published?

      In such a scenario, an aggregator should collect and store individual messages until a complete set of related messages has been received

    2. If yes, what is the application service and how does it communicate with it?

15.2.1.2 Designing an ABCS to Participate in a Provider Role

To determine how to enable the ABCS to participate in a provider role:

  1. Decide whether the application can directly consume the information sent by EBS.

  2. Determine how the ABCS interacts with provider applications.

    See Chapter 24, "Establishing Resource Connectivity."

  3. Define the tasks that must be done by this ABCS.

  4. Determine what message exchange pattern (MEP) is used to communicate with the application.

  5. Determine whether data validation must be done on the EBM sent by the EBS before sending the request to the provider application.

  6. Decide whether you need guaranteed delivery of messages.

  7. Determine whether it is a single message containing data for multiple instances.

  8. Decide whether the entire message should be processed as a unit of work.

  9. Decide what must be done when a subset of instances present in that message encounter failure.

15.2.2 Constructing ABM Schemas

The ABM schemas are created by the participating applications. Consider the following points when defining the ABMs:

  • Construct messages that are durable and long-lasting because frequent changing of the ABM definition puts duress on ABCS development.

  • Ensure reusability of business components across multiple ABMs to promote reusability of transformation maps.

  • Design ABMs to pass the following system data:

    • System Instance - connection information that helps identify the system ID registered in the system registry

    • Locale - language code in which the request is sent

    • Sender information - contextual details pertaining to the origination of the message

  • Design ABMs that are extensible.

15.2.3 Analyzing the Participating Application Integration Capabilities

To analyze the participating application integration capabilities:

After identifying the participating applications, you must analyze the integration capabilities of each participating application and how each application exposes its data.

  1. Work with the application providers (developers) to decide the best way to interact with the application to attain the needed functionality.

    The interactions can be inbound or outbound. The interaction mechanism can be one of these:

    • Web Service using SOAP/HTTP

    • Events/Queues

    • JCA Adapter

    • Database Adapter

    For more information about various types of connectivity to different resources, see Chapter 24, "Establishing Resource Connectivity."

  2. Obtain relevant details from the applications in situations in which the interactions between the participating applications and the ABCS happen through a message queue adapter, database adapter, or JCA adapter.

    These details are used in configuring the adapters. The configuration results in the WSDL creation. Care must be taken to ensure that the environment-specific details are configured in relevant resource files on the server and not directly in the WSDLs.

  3. Identify the available functionality within the participating applications and the mapping between EBMs and application business objects (map operations).

    A one-to-one, one-to-many, or many-to-one mapping between the two may exist.

  4. Tabulate the mapping between the Enterprise Business Object (EBO) attributes/elements and the application objects attributes/elements in a spreadsheet.

    Remember these points when creating the transformation maps:

  5. For an ABM being mapped to an EBM, ensure that an attempt is made to populate all of the data elements present in the ABM to the relevant elements in the EBM.

    In situations in which the ABM does not have all of the content to supply all of the data elements in the EBM, you must work with the respective requester application teams to identify the application services that could be used to enter the content in the EBM.

    For example, a Siebel application invoking the CreateOrder ABCs might supply only the Siebel Customer ID in the ABM that is being passed as the payload. However, the EBM to be passed as a payload to the CreateOrder EBS operation expects all the information regarding the Customer. So the CreateOrder ABCS is responsible for invoking a Siebel service to retrieve complete Customer details from the Siebel application and populate the EBM. Although the integration platform provides support for this pattern, we highly recommend that you work with the participating application to ensure that the payload being passed to the ABCS is as close to the shape of the EBM as possible to minimize the chattiness.

15.3 Identifying the MEP

The possible interaction types between an ABCS and its client are:

  • Synchronous request-response

  • Asynchronous request only

  • Asynchronous request-delayed response

MEPs vary in functionality and usage depending on the role of the ABCS.

For more information about MEPs, see "Understanding Interaction Patterns" in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

15.3.1 Introduction to MEPs

Synchronous Request-Response Pattern

  • A requester sends a request to a provider, who processes the request and sends back a response.

  • The requester is in a suspended mode until the response is received from the provider.

  • Results are in real-time response or error feedback.

Asynchronous Request Only

  • The message exchange is one-way, with a requester sending a request to a provider. No response comes from provider to requester.

  • The requester is free, after request submission, to resume normal execution.

Asynchronous Request - Delayed Response

  • This involves two one-way invocations.

  • First, a one-way message is sent from requester to provider. At a later time, another one-way message is returned from the provider to the original requester.

  • Two distinct one-way messages are correlated.

For more information about MEPs, see "Understanding Interaction Patterns" in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

15.3.2 Choosing the Appropriate MEP

  • Identify how the participating applications interact with the ABCS for inbound and outbound interactions.

  • Identify whether the requester application must be in a call-waiting state until it has received the response from the provider application.

    Waiting until the response is received from the provider application forces the requester application to invoke the ABCS in a synchronous manner. For example, a CRM application submitting a request to retrieve account details from a billing application would fit this scenario. In this case, the requester cannot perform any task until the response is received.

    However, sending a request from the CRM application to create a customer in a billing application can be done in an asynchronous manner. After publishing an outbound request, the CRM application can move to the next activity without having to wait until the provider application has successfully created a customer. In this case, the CRM application invokes this outbound request in an asynchronous manner.

Applications can leverage different kinds of integration technologies for synchronous versus asynchronous invocations. You must select the most appropriate technology based on the situation.

For more information about how AIA services interact with applications, see Chapter 24, "Establishing Resource Connectivity."

In a single flow, even though the requester ABCS MEP is influenced by the MEP for the EBS operation to be invoked, the requester application's interaction capabilities influence the MEP for requester ABCS. For provider ABCS, the MEP is predominantly influenced by the MEP of the EBS operation.

15.3.2.1 When to Use the Synchronous Request-Response MEP

Most of the cases involving Query and Validate need this pattern because the participating application that initiated the request is waiting for the response. For all the other cases, the suitability of this pattern is determined by the demands of the response time and possibility of meeting those requirements based on the amount of processing to be done.

The MEP between requester ABCS and EBS is synchronous. The MEP between provider ABCS and participating application servicing the request can be either synchronous or asynchronous.

For more information about Query, see Section 16.8.7, "Query."

For more information about Validate, see Section 16.8.5, "Validate."

Use Case

CRM Application requesting account details about a customer from the billing system

Figure 15-3 illustrates the two-way communication between AIA services, requester ABCS, and CustomerPartyEBS.

Figure 15-3 GetAccountBalanceSummary Integration Scenario

The image is described in the surrounding text

15.3.2.2 When to Use the Asynchronous Request Only (Fire-and Forget) MEP

Use this pattern when:

  • The requester ABCS receives the request message from the participating application and ends with invoking of the EBS. In this case, no response comes from the EBS to the requester ABCS and no response is made to the participating application that initiated the request.

  • The provider ABCS receives the request message from the EBS and ends with invoking the provider participating application API. No response is made to the EBS that initiated the request.

Use Case

A CRM application submitting a request to the BRM application to create CustomerParty

From the perspective of the participating application, Siebel, a request message to the BRM application to create a CustomerParty is enqueued for processing at a later time. The Siebel application is free to resume its processing immediately. The request message is dequeued from the queue and is processed in an asynchronous fashion.

Figure 15-4 illustrates the one-way invocation between AIA services, Requester ABCS, and CustomerPartyEBS.

Figure 15-4 Example of One-Way Invocation

The image is described in the surrounding text

15.3.2.3 When to Use the Asynchronous Request Delayed Response MEP

Use this pattern when:

  • The requester ABCS receives the request message, processes the message, and finally updates the participating application that initiated the request by invoking an API exposed by the participating application. The participating application is not waiting for the response.

  • The provider ABCS receives the request message from the EBS Request mediator service, processes the message, and finally responds to the requesting service-requester ABCS or Enterprise Business Flow (EBF)-by invoking the response operation of the EBS Response mediator service. The EBS Mediator service is not waiting for the response.

The MEP between requester ABCS and EBS can be synchronous or asynchronous, and between the provider ABCS and the provider participating application can also be synchronous or asynchronous.

15.4 Technology Options

This section discusses technology options for:

For more information about resource connectivity, see Chapter 24, "Establishing Resource Connectivity."

15.4.1 Outbound Interaction with the Application

Communication between ABCSs and the application is governed by the application capabilities.

Communication technologies include:

  • JCA Adapters

  • Standard web service interfaces

  • Adapters

  • JMS queues

15.4.1.1 When to Use JCA Adapters for Outbound Interactions

JCA Adapters, when available and authorized for use, should be the first choice for developers to connect to applications.

JCA Adapters:

  • Natively invoke participating applications in a co-located fashion.

  • Standardize the programming interface.

  • Standardize the quality of services (QoS) implementation.

  • Provide support for tasks associated with connection management, transaction management, and scalability in combination with the run-time environment.

For more information about establishing outbound connectivity, see Chapter 24, "Establishing Resource Connectivity."

15.4.1.2 When to Use Standard Web Service Interfaces (SOAP/HTTP, XML/HTTP) for Outbound Interactions

This is the most common means of communicating with participating applications.

Most applications expose functionality in the form of a web service. The most common transport used is SOAP over HTTP, however some applications may expose direct XML over HTTP.

15.4.1.3 When to Use JCA Adapters, (Database, File, JMS, or AQJMS), for Outbound Interactions

In situations in which the message submission is decoupled from the processing of the message, usage of queues is suggested. When JMS queues are used, they must be accessed using JMS Adapter. The message is enqueued to the JMS queue by the ABCS and the application would dequeue the message.

Tip:

AIA highly recommends that participating applications making an outbound interaction in an asynchronous mode use message queues to publish the requests. AIA recommends this approach because it allows for high scalability and a better end-user experience. Similarly, the ABCS making an outbound interaction to the applications must assess the tasks to be performed by the application. Use of message queues to communicate with the applications in situations in which applications need longer periods to perform the tasks.

Participating applications making an outbound interaction in a synchronous mode alone should send the requests using SOAP/HTTP.

For more information about JMS Adapters, see Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server.

15.4.2 Using BPEL for Building ABCS

AIA recommends using a BPEL component to build an ABCS composite.

BPEL is the most effective solution when:

  • You have a long-lived process.

    In scenarios in which you have a long-lived process that may take hours or even days, BPEL is the best technology choice. In this case, BPEL persists (dehydrates) the process at certain hook points and then bring the process to life when needed.

  • You need complex orchestration capabilities.

    In scenarios that require complex orchestration, parallel processing, and multiple conversations with participating applications, and with integrated services such as BPA, BAM, Workflow, and Rules Engine, BPEL is the most effective solution.

  • You have content augmentation and validation that cannot be done using XSLT.

    In cases in which the decision-making and validation is not simple enough to perform using XSLT, other means are needed such as the standard BPEL procedural constructs or even calling out to the Rules Engine. BPEL enables you to easily perform fairly complicated decision trees and route the results to different partners.

  • You need aggregation or disaggregation.

    In scenarios in which the ABCS must make multiple calls to the application to process a message or to collect data and then consolidate it in one message, BPEL is the suitable technology. BPEL constructs enable you to split or consolidate payloads and aggregate or disaggregate calls. The BPEL process is also responsible for maintaining the state and handling transactions in between invocations.

  • You must augment the participating application functionality.

For more information, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.