6 Understanding Extensibility
This chapter provides an overview of extensibility.
This chapter includes the following sections:
6.1 Introduction to Extensibility
One of the capabilities of the architecture is to allow for various artifacts of prebuilt integrations to be extended by customers. It also ensures that these extensions are protected during the upgrades, although for some extensions, configurations may have to be done after the upgrade to point to the artifacts. The Oracle Application Integration Architecture (AIA) artifacts have been designed and constructed from the ground up to have native support for extensibility. Figure 6-1 shows various extensibility points in the integration flow and provides examples of how the flow might be extended at each point.
6.2 Schema Extensions
Oracle AIA facilitates the extension of delivered Enterprise Business Objects (EBOs) to accommodate the introduction of industry-specific and customer-specific needs.
The EBO is extensible to meet the specific needs of an implementation. Extensions are clearly separated from the original structure of the EBO delivered by Oracle AIA so that future delivered versions will not override any extensions that have been defined.
All of the EBO extensions have been designed to reside in the extension-specific namespaces. 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 providing such identification, naming conflicts might occur between different extensions or between extensions and future additions to the core specification. Hence, the customer and vertical-specific extensions each reside in their own namespace.
-
A straightforward path should exist from identifying an extension to learning more about it.
Two approaches are available for implementing extensibility:
-
Customer-specific extensions
-
Industry-specific extensions
6.2.1 Customer Extensions
Every component that is available in an EBO is enabled to accommodate customer-specific extensions. Every component has an additional element added at the very end that is designed to accommodate customer-specific attributes that may be applicable to that component. In an implementation, a customer may decide to complete the definition for the data types for which data elements are of interest.
For more information about extension-enabling an EBO and about how to add customer-specific attributes to an existing EBO, see the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
6.2.2 Industry-Specific Extensions
The architecture allows for incorporating industry-specific attributes as overlays. An industry-specific object can be created by assembling a set of business components that are available at the core with a set of industry-specific components. This approach is available only for delivering industry-specific EBOs by Oracle. Customers can add industry-specific content using the approach described in Section 6.2.1.
6.2.3 Schema in the Use Case
When implementing the Get Account Balance use case, you might want business-specific information such as usage details about the customer to be retrieved from the billing system. Assume that this information is available in BRM and that this information is made available by BRM web service. You want the usage details to be rendered on a Siebel screen along with the other information that has been brought from BRM. For this additional content to be sent to the calling application through integration, you must extend the Enterprise Business Message (EBM), in this use case, the Query Customer Party Response EBM.
6.3 Transformation Extensions
The transformation scripts that are delivered as part of prebuilt integrations are made extension-ready. This allows for customer-defined transformations to be introduced in a nonintrusive manner and ensures that customer-specific transformation-related extensions are durable.
Every component in the EBM, including the EBM header, contains an extensibility point that can be configured to add the necessary transformations. A transformation script exclusively dedicated for housing customer extensions is delivered. You can add transformation code to the templates that are available in the customer-specific transformation script to specify transformation rules for the newly introduced content.
In this release, the XSLT extensibility programming model focuses on providing hooks for customers to add maps only to the new elements they have added to EBM. The programming model at this time does not provide mechanisms for overriding the existing maps for certain elements. Similarly, adding maps to existing elements that have no maps provided by the PIPs are not addressed.
6.3.1 Extensions in the Use Case
The Get Account Balance use case illustrates what must be done to send the extensions to the Siebel screen. The Oracle BRM Application Business Connector Service (ABCS) for Query Customer Party is responsible for transforming the Application Business Message (ABM) into an EBM. Assume that the BRM web service has already retrieved the details and made them available in the ABM. Now you must ensure that the content present in ABM is made available in EBM.
You leverage the predefined extensibility point and include the code for transformations in the extensions script. The customer-specific content Usage Details is available in the Query Customer Party Response EBM.
The Enterprise Business Service (EBS) operation Query Customer Party returns the Customer Party Response EBM back to the Siebel Query Customer Party ABCS. The transformation script that is present in this ABCS is responsible for transforming the EBM into an ABM, which is then sent to the Siebel application. You use the transformation script that is exclusively meant for customer extensions and include the code pertaining to this transformation. Now the Siebel ABM gets the ABM from the ABCS and can display the Usage Details on the screen.
6.4 Transport/Flow Extensions
Oracle AIA enables you to change the transport channel by which the messages travel between the participating application and the connector services in a nonintrusive manner. For example, the prebuilt integration that is delivered with the system might use SOAP/HTTP to transport the message between Siebel CRM and the connector service. But at implementation time, you might decide to ship the data using a file. This change can be made in a configurable manner without making any customizations to the delivered artifacts.
6.5 Process Extensions
The architecture provides recommendations on how the ABCS as well as the orchestration processes (Composite Business Processes [CBPs] and Enterprise Business Flows [EBFs]) can be designed to allow the customers to introduce the extensions to augment the functionality.
Each of the BPEL processes can have its own set of extensibility points based on the functional needs. You can implement the interface that is defined for each of the extensibility points to either augment or override the behavior. ABCS are recommended to have a minimum of four extensibility points, in case of request-response pattern, to enable customers to inject additional behavior. In case of the fire-and-forget pattern, the services are expected to have a minimum of two extensibility points. The orchestration processes might decide not to have any extensibility points.
Refer to the documentation for the appropriate Process Integration Packs (PIPs) to check whether they have support for process extensions.
6.6 Routing Extensions
Oracle AIA enables you to add custom routing rules using the custom extension points provided in the custom EBS as shown in Figure 6-2. This enables you to route the message to any other homegrown applications or services plugged into the Oracle AIA to extend your service provisioning for any service request.
For more information about whether a PIP supports routing extensions, see the respective PIP implementation guide.