|Oracle® Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack
11g Release 1 (220.127.116.11)
Part Number E17363-07
|PDF · Mobi · ePub|
This chapter provides an overview of extensibility and discusses considerations for schema extensions, transformation extensions, transport/flow extensions, process extensions and routing extensions.
This chapter includes the following sections:
The Oracle Application Integration Architecture (AIA) allows customers to extend various artifacts of prebuilt integrations. These extensions are protected during upgrades, although postupgrade configurations may be needed to point to the artifacts. The artifacts are designed and constructed with native extensibility support. Figure 6-1 shows various extensibility points in the integration flow and provides examples of how the flow might be extended at each point.
Oracle AIA allows Enterprise Business Objects (EBOs) to be extended to meet industry-specific and customer-specific needs.
The EBO structure that Oracle AIA delivers and provides upgrades for is separate from and does not affect any extensions.
Extensions must use their own namespace name for two reasons:
Each family of extensions must be distinguishable from the core components of the XML format and other extensions.
Without such identification, naming conflicts might occur between different extensions or between extensions and future additions to the core specification.
A straightforward path should exist to identifying details about the extension.
Two approaches are available for implementing extensibility:
Every EBO component has an element at the end to accommodate applicable customer-specific attributes. For example, a customer may complete the data type definitions for data elements of interest.
For information about extension-enabling an EBO and adding customer-specific attributes, see the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
The architecture allows for industry-specific attributes as overlays. An industry-specific object combines business components available at the core with industry-specific components. It's not clear what this means. Here's my best guess: Only Oracle can create industry-specific EBOs. Customers can add industry-specific content using the approach described in Section 6.2.1.
You can extend the Get Account Balance use case to retrieve customer usage details from the billing system. Suppose the BRM web service exposes this information. You can render the usage details on a Siebel screen along with other information from BRM. Extend the Enterprise Business Message (EBM), specifically the Query Customer Party Response EBM.
The transformation scripts in prebuilt integrations are extension-ready. This ensures that customer-defined transformations are nonintrusive and customer-specific transformation-related extensions are durable.
Every component in the EBM, including the EBM header, contains an extensibility point for transformations. Oracle provides a transformation script exclusively dedicated to housing customer extensions. You can add code to the templates in this script to specify transformation rules for the new content.
In this release, the XSLT extensibility programming model allows customers to add maps only to their new elements in the EBM. You cannot override existing maps for certain elements. Similarly, you cannot add maps to existing elements having no maps in the Pre-Built Integrations.
The Get Account Balance use case illustrates how to send the extensions to the Siebel screen. The Oracle BRM Application Business Connector Service (ABCS) for Query Customer Party transforms the Application Business Message (ABM) into an EBM. Suppose that the BRM web service has retrieved the details and made them available in the ABM. Now you must ensure that the ABM content is also in the EBM.
You use the predefined extensibility point and include the transformation code in the extensions script. The customer-specific Usage Details content is available in the Query Customer Party Response EBM.
The Enterprise Business Service (EBS) operation Query Customer Party returns the Customer Party Response EBM to the Siebel Query Customer Party ABCS. The script in the ABCS transforms the EBM into an ABM, which is then sent to the Siebel application. Now the Siebel ABM gets the ABM from the ABCS and can display the Usage Details on the screen.
You can change the transport channel in a nonintrusive manner for messages traveling between the participating application and the connector services. For example, the prebuilt integration might use SOAP/HTTP to transport the message between Siebel CRM and the connector service. At implementation time, you might decide to ship the data using a file instead. You can reconfigure the transport without customizing the delivered artifacts.
Oracle recommends ways for customers to extend the architecture of the ABCS and the orchestration processes. These orchestration processes are Composite Business Processes (CBPs) and Enterprise Business Flows (EBFs).
Each BPEL process can have its own extensibility points based on functional needs. You can implement the interface for each extensibility point to augment or override the behavior. Oracle recommends that an ABCS for a request-response pattern have a minimum of four extensibility points. An ABCS for a fire-and-forget pattern is expected to have a minimum of two extensibility points. The orchestration processes might not have any extensibility points.
Refer to the documentation for the appropriate Pre-Built Integrations to check whether they to support process extensions.
Figure 6-2 shows how to add custom routing rules using the custom extension points in the custom EBS. You can route a message to any homegrown applications or services plugged into Oracle AIA to extend service provisioning for any service request.
For information about whether a Pre-Built Integration supports routing extensions, see the relevant implementation guide.