4 Understanding Application Business Connector Services
This chapter introduces Application Business Connector Services (ABCS) and provides an overview of ABCS architecture and characteristics, architectural considerations for implementing ABCS, extensions and customizations for ABCS, processing multiple instances, and ABCS transformations.
This chapter includes the following sections:
For more information about ABCS, see "Designing Application Business Connector Services," "Constructing the ABCS," and "Completing ABCS Development" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
4.1 Introduction to ABCS
The ABCS exposes a participating application's business functions in a representation compatible with a service interface.
In canonical integration style, an Enterprise Business Service (EBS) exposes the common service interface. The common service interface allows participating applications to invoke EBSs.
In non-canonical integration styles, an EBS to expose the service interface might not be present. In these situations, the client application or its ABCS can directly invoke the provider ABCS. In other situations, the client application or its ABCS can use the service interface defined by the provider to invoke the EBS.
An ABCS can be requester-specific or provider-specific. A requester ABCS accepts the request from the client application through a client-specific Application Business Message (ABM) and returns the response to the client application through a client-specific ABM. The requester ABCS enables the participating application to invoke the EBS to access data or perform a transactional task. The client side ABM is the payload passed by the requester application to the requester ABCS.
The requester application must define the requester-specific ABCS. The requester application could be Siebel CRM, PeopleSoft Enterprise CRM, or Oracle eBusiness Suite CRM. The requester application-specific ABCS must take the requester application-specific ABM as input and provide the requester application-specific ABM as output.
The provider ABCS exposes the business capabilities available in the provider application according to the EBS specification. In certain non-canonical integration styles, the provider defines the EBS interface. In other situations, the EBS artifact acts as an abstraction layer. The service-provider-side ABCS accepts the request either from the EBS through the Enterprise Business Message (EBM) or directly from either Requester Application or Requester ABCS and sends the response using the same format. The ABCS transforms different application object representations to the canonical definition, making communication between applications possible.
The ABCS coordinates various steps provided by several services, including:
-
Validation (if any)
-
Transformations - message translation, content enrichment, and normalization
-
Invocation of application functions
-
Error handling and message generation
-
Security
For every activity of an Enterprise Business Object (EBO), the participating requester application and the service provider application must each define an ABCS.
4.2 ABCS Architecture
The Oracle Application Integration Architecture (AIA) requires messages sent from applications providing business functions to follow either EBS or provider ABCS (in non-canonical integration styles) standards. Applications meeting these standards can participate in cross-application business processes and prebuilt data integrations.
Similarly, applications receiving messages from an EBS must be able to understand them. For applications not designed to interact with an EBS, the ABCS exposes the application-specific business functions in the Mediator.
The ABCS uses a variant of the industry-standard integration pattern called VETO: Validate, Enrich, Transform, and Operate. The VETO pattern and its variations ensure that consistent, validated data is routed throughout the Mediator. A common variation is the VETRO pattern, which adds a Route step.
The ABCS architecture adds an extra Operate step to the VETRO pattern, resulting in the VETORO pattern illustrated in Figure 4-1.
The VETORO pattern consists of the following steps:
-
Validate: This step ensures that the content of the incoming message can be transformed for the target system. In certain cases, the validate step can check whether the incoming message contains a well-formed XML document in conformance with the schema of the receiving application. This is often one of the first steps in the EBS. It allows dissimilar versions of XML-producing and XML-consuming applications to coexist.
-
Enrich: This step involves adding additional data to a message to make it more meaningful and useful to a target service or application.
-
Transform: This step translates an application-specific object representation into an EBO, or translates an EBO-specific representation into an application-specific object representation.
-
Operate: This step invokes the target service or an interaction with the target application. In Oracle AIA, it could invoke the EBS, a specific ABCS, or an interaction with the participating application using the provider ABCS.
-
Route: The Route step deciphers the appropriate service provider responsible for performing the service. In Oracle AIA, the Route step is implemented in the EBS using content-based routing technologies available in Oracle Mediator.
In some cases, one ABCS implements the validate, enrich, and transform steps. Also, a Mediator routing service may use XSL-based validation and content-based routing directly in the service itself, rather than using a separate routing service.
The ABCS does not handle transport protocol abstraction itself. The ABCS has inbound and outbound interactions using only the SOAP/Mediator protocol. A transport adapter integrates the participating application-specific native protocols with the ABCS-specific standard. This facilitates reuse of the same ABCS for multiple transport adapters and vice versa.
4.3 ABCS Characteristics
The ABCS has the following characteristics:
-
For every activity of an EBO (canonical pattern-based integration style), the participating requester and provider applications must each provide an ABCS.
-
In a non-canonical pattern-based integration style, the provider application must provide an ABCS.
-
The requester ABCS has participating application-specific ABMs as input and output.
-
The service accepts requester application-specific ABMs as input and provides requester application-specific ABMs as output.
-
The provider ABCS has EBMs (representing EBO-specific content needed for performing the operation) as input and output.
-
The service accepts EBMs as input and returns EBMs as output.
-
Although a single ABCS can handle multiple activities, Oracle highly recommends allowing only a single ABCS per action. This approach greatly reduces the complexity of designing a generic ABCS.
If you do design a single ABCS to handle multiple activities, remember that the service must have the activity information accepted as a part of the input. The ABCS can then decipher the action to be performed and the appropriate transformations and invocations. In addition, allowing a single requester ABCS to handle multiple activities means that a single requester application-specific ABM encompasses all of the information pertaining to all of the activities.
4.4 Architectural Considerations
The architectural issues discussed in the following sections play a large role in determining your choice of implementation technologies and the design paradigms you use to construct ABCS.
4.4.1 Participating Application's Service Granularity
Perform some analysis to identify how the participating applications intend to expose their business functionality to the Mediator. If the applications expose their functionality using a web service interface, verify that the granularity of functionality exactly matches that of an application-agnostic or provider application-specific interface.
If an exact match exists, your main task is to transform the application-specific ABM into the enterprise EBM and vice versa. Mediator is an implementation technology candidate for building the ABCS.
If the granularity of the application's web service does not match that of the EBS, enhance or modify the application if possible. If you cannot modify the application, the ABCS must handle transformations and aggregate and disaggregate services.
For example, suppose a single business-level activity cannot be mapped to a single API or operation in the server application. The provider application might have very fine-grained operations and might also require that transaction management be handled by calling applications. In this case, the provider ABCS probably has a chatty conversation with the provider application. The provider ABCS is also responsible for state management.
You must implement this type of ABCS through BPEL technologies, not through Mediator services.
Although Oracle AIA allows this type of ABCS, Oracle highly recommends encapsulating much of this application logic in native applications instead of in the ABCS.
4.4.2 Support for EBMs
Because the EBS operates only on EBMs, you must determine whether the applications that implement the services provide support for EBMs. If application-provided services support EBMs, transforming the EBO into an EBM is easier. If the applications that implement the services do not support EBMs, you must determine whether their services can support EBMs.
If these applications cannot support EBMs, the ABCS must perform transformation-related work.
4.4.3 Application Interfaces
Interfaces determine how participating applications allow business logic to interact with the Mediator. Some applications support web service interfaces. The WSDL defines the interface that communicates directly with the application business logic. In this preferred scenario, the ABCS uses the web service interface to invoke the application business logic.
In packaged applications such as Siebel, PeopleSoft, J.D. Edwards, and SAP, the respective packaged-application adapters are preferred. These adapters can be deployed as J2CA resource adapters. This is a better solution than using the conventional SOAP interface. When the participating applications do not expose their business logic as web services, database adapters, advanced queuing (AQ) adapters, or other adapters are needed.
Investigate whether services exposed by the participating applications support proprietary message formats, technologies, and standards. If the applications do not support standards and technologies such as XML, SOAP, and JMS, then the ABCS must handle transformations.
For example, suppose the application receives and sends messages only through files and recognizes only EDI format. In this case, the ABCS integrates with the application using a file adapter, translates EDI-based messages into XML format, and exposes messages as SOAP messages.
For more information, see "Establishing Resource Connectivity" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
4.4.4 Support for Logging and Monitoring
The ABCS facilitates logging and monitoring. The ABCS invokes convenience services for logging and auditing.
For more information, see Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack.
4.4.5 Support for Insulating the Service Provider
The granularity of the service provider's service may not match that of the EBS. In this case, the ABCS must construct the message needed for interacting with the EBS from multiple fine-grained transactions.
For example, the BRM Billing application provides an API for retrieving only immediate child details for either a bill or bill detail. However, the EBS interface expects the service provider to return complete details about a bill. In this case, the ABCS protects the application implementing the service by doing workload buffering. The ABCS makes a series of sequencing calls to the application to retrieve all of the required information, consolidate the data into a single message, and send it to the calling application.
4.4.6 Support for Security
The security model largely determines ABCS responsibilities. Support for a point-to-point security model requires only that the ABCS authorize the service requests. Support for an end-to-end security model necessitates the transmission of requester credentials to the service provider.
The latter scenario can use Web Services Security if all participating systems support it. Otherwise, security credentials can be transmitted as application data or in the SOAP header. In either case, the ABCS must be coded accordingly for authentication.
4.4.7 Validations
As a message travels between participating applications, validations must ensure that accurate data reaches the target system. Validation specificity varies significantly depending on distance from from the target system.
Participating applications providing services impose validation constraints. ABMs generated from EBMs must obey these constraints. In addition, the target system's validation rules may reject a message unless a transformation step alters the incoming data.
Because the EBM cannot enforce all participating application-specific constraints, the specific ABCS must enforce them. For example, the PeopleSoft CRM application might mandate that the product description be present for creating a product, while the product EBM might not enforce that constraint. In this situation, the PeopleSoft Create Product ABCS must ensure that the ABM generated from the EBM includes the product description. Thus the ABM passed to the PeopleSoft CRM Create Product service complies with service constraints.
The validation for a constraint very specific to the PeopleSoft CRM application must reside only in the PeopleSoft CRM Create Product ABCS. It is inappropriate to have this validation present in the early stages of message flow, for example, in the client-side ABCS.
Because validation during capture creates a better user experience in asynchronous interaction styles (request-only), the requester application should perform the validation at another integration point before submitting the message for processing. For example, in an Order Capture application, the requester application makes a synchronous call to validate the content before submitting the order for fulfillment. A Validate Order or Validate Billing Information EBS might be available for various service providers. If the response from the Validate Order service is favorable, the requester application then makes the request to process the order.
4.4.8 Support for Internationalization and Localization
The ABCSs that pass the EBMs to the actual service providers translate the documents into locale-specific ABMs. Similarly, the ABCS translates the locale-specific ABM into the locale-independent EBM.
The ABCS deciphers the locale from the user preferences for the relevant participating application. This data specifies how the locale-specific ABM must be constructed, and how the locale-specific ABM must be interpreted.
The ABCS specifies the locale of the service provider's response. For example, the ABCS for the Get Product Details EBS specifies the locale in which the Oracle eBusiness Suite application provides product details. If the requester wants the product details in Spanish, the Get Product Details EBS must instruct the real service provider accordingly.
4.4.9 Message Consolidation and Decomposition
You may need to combine responses to a request that originates from multiple sources. For example, in convergent billing in the telecommunication solution, the ABCS for the getBillDetails EBS might have to retrieve details from multiple participating applications. This ABCS also consolidates them into a single response.
4.4.10 Support for Multiple Application Instances
You may have multiple instances of a packaged application with the same business capabilities in your company's ecosystem. The EBS routing rules decipher the right application instance to receive the request. Regardless of the number of application instances for a packaged application, only one ABCS exists for that packaged application to perform a specific task.
4.5 Implementing ABCS
Each application implementing a business activity or task has its own ABCS.
An ABCS for a particular participating application should implement a single action. The action is the same on both sides of a synchronous request-response pattern. In a delayed response pattern, one ABCS implements the request action and another implements the response.
The ABCS can be implemented in two ways:
-
Use only Oracle Fusion Middleware components.
A Mediator service or BPEL process performs the tasks listed in the following sections.
-
Build the transformation services mainly in the participating application.
Use this approach when the participating application's technology stack can perform the transformations. However, a lightweight ABCS still must perform the translations related to cross-reference details.
For more information about ABCS, see "Designing Application Business Connector Services," "Constructing the ABCS," and "Completing ABCS Development" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
Regardless of how an ABCS is implemented, it is still a service, so an interface is exposed as a WSDL. The client applications use this interface to invoke the ABCS.
XSL scripts implement client-side and server-side ABCS transformations.
The ABCS itself must be independent of deployment. Only one ABCS instance exists even for multiple deployments of a single client or provider application. For example, suppose two BRM Billing application deployments existed, one for North American customers and another for all others. A single ABCS would invoke the application business service in the appropriate deployment.
In many situations, you cannot map a single action to a single API or operation in the provider application. The provider application might have very fine-grained operations or require calling applications to handle transaction management. In this case, the provider-side ABCS probably has a chatty conversation with the server application. The provider-side ABCS also handles state management.
You must implement this type of ABCS using only BPEL technologies, not Mediator services.
Although Oracle AIA allows this type of ABCS, Oracle highly recommends encapsulating application logic within native applications instead of in the ABCS.
The service populates the EBM message header section with values. The service deciphers some values by itself, and receives other values from participating applications through an ABM.
For more information, see Section 2.2.1, "EBM Architecture".
4.5.1 Requester-Side ABCS
The requester-side ABCS has the following core responsibilities:
-
Enrichment or augmentation of the ABM.
The ABM from the participating application may lack required content. For example, a CRM application might pass only the order identifier in the ABM. The ProcessOrder EBS interface might require the entire order object. In this situation, the ABCS must request all required information from the participating application to enrich the ABM.
-
Transformation of requester application-specific ABMs into EBMs.
-
Creation of an EBM that encompasses the previously mentioned EBM.
-
Population of the message header with the appropriate values.
For more information, see Section 2.2.1, "EBM Architecture".
-
Invocation of any extension handler that you may have registered.
The extension handler can perform additional transformations. The extension handler is passed to the EBM and the transformed EBM is passed back as the response. You can perform additional transformations on the EBO before the EBS is invoked.
-
Invocation of the EBS.
The EBS uses an EBM to provide the response.
-
Transformation of an EBM into an ABM.
-
Invocation of any extension handler that you may have registered.
This extension handler could be used to perform any additional transformations. The extension handler is passed to the ABM and the transformed ABM is passed back as the response. You can perform additional transformations on the ABM before the ABM is passed back to the calling application.
-
Validation of the ABM passed to the participating client application to ensure compliance with constraints enforced by the participating application.
-
Return of the response to the calling application.
Figure 4-2 illustrates the high-level flow of activities in a requester-specific ABCS. The EBS and ABCS interact in a request-response style. The steps for running the extension to do additional transformations are optional.
Figure 4-3 depicts the high-level flow of activities in a requester-specific ABCS. The EBS and ABCS interact in a fire-and-forget style. The steps for running the extension to do additional transformations are optional.
4.5.2 Provider-Side ABCS
The provider-side Application Business Connector Service has the following core responsibilities:
-
Transformation of an EBM into a provider application-specific ABM.
-
Invocation of any extension handler that you may have registered.
The extension handler can perform additional transformations. The extension handler is passed to the ABM and the transformed ABM is passed back as the response. You can perform additional transformations on the ABM before the ABM is passed to the provider application business service.
-
Validation of the ABM passed to the participating provider application to ensure compliance with constraints enforced by the participating application.
-
Invocation of the provider application business service.
Invocation can consist of one or multiple calls.
For more information, see Section 4.4, "Architectural Considerations."
-
Transformation of an ABM into an EBM. The response message sent by the provider application must be returned to the caller application. In this case, it would be the EBS. Because the EBS expects only the EBM as output, the ABM must be transformed into an EBM.
-
Creation of an EBM that encompasses the previously mentioned EBO.
-
Population of the message header section with the appropriate values.
For more information, see Section 2.2.1, "EBM Architecture".
-
Invocation of any extension handler that you may have registered.
The extension handler can perform additional transformations. The EBM is passed to the extension handler and the transformed EBM is passed back as the response. You can perform additional transformations on the EBM before the document is passed to the EBS.
-
Return of the document to the EBS.
Figure 4-4 depicts the high-level flow of activities in a provider-specific ABCS. The EBS and ABCS interact in a request-response style.
Figure 4-5 depicts the high-level flow of activities in a provider-specific ABCS. The EBS and ABCS interact in a fire-and-forget style.
4.6 Reviewing Implementation Technologies for ABCS
Oracle AIA provides two blueprints for implementing an ABCS: Oracle Mediator and BPEL.
4.6.1 Oracle Mediator
Use the Oracle Mediator blueprint when you do not need additional enrichment or content validation. In this model, the ABCSs are implemented as Mediator services.
To configure a different transport, add transport adapters before the client-side ABCS or after the provider-side ABCS.
For more information about using Oracle Mediator, see "Designing and Developing Enterprise Business Services" and "Tuning Integration Flows" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
4.6.2 BPEL
Use BPEL when the ABCS must augment or validate content. In most situations, the ABCS must call one or more participating applications to enrich the content. It may also have to handle state management.
BPEL can also extend the connector. You can implement the ABCS using procedural object-oriented languages such as Java or C++.
Use BPEL when a Mediator service cannot implement the ABCS due to technology constraints or complexities.
For more information about using BPEL, see "Designing Application Business Connector Services," "Constructing the ABCS," and "Completing ABCS Development" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
4.7 Extending or Customizing ABCS Processing
With Oracle AIA, you can use different transports without modifying the delivered artifacts. For example, you could add a third-party billing application-specific implementation without modifying the Query Customer Party EBS. Similarly, you can change the transport mechanism that invokes the participating application's services without modifying the ABCS.
A client-side or provider-side ABCS implementing the request-response pattern provides four extensibility points. A requester ABCS provides two extensibility points before EBS invocation and two after the EBS responds. A provider ABCS provides two extensibility points before application-specific service invocation and two after the application service responds. An ABCS implementing the fire-and-forget pattern has only two extensibility points. You can inject additional behavior, such as custom validation or transformations, at extensibility points. You can use transformations for additional elements introduced at the implementation site. You can introduce additional processing without having to customize the delivered ABCS. The extension service is passed to either the EBM or the ABM, depending on the situation. The content is passed as context to the extension service, which returns the content after performing the alterations.
For more information about ABCS, see "Completing ABCS Development" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
4.8 Processing Multiple Instances
Because an EBM can carry multiple instances, the provider ABCS must iterate through the instances and process them. Not all EBMs support carrying multiple instances. EBMs created specifically for supporting bulk processing can support multiple instances.
An ABCS can decide whether its application can process the instances in bulk form. If the application has the ability, then the ABCS transforms the content into ABM format for all of the instances and hands them over to the participating application by invoking the service. Upon receiving the response, the ABCS transforms the content of each instance back into EBM format, consolidates them in an EBM, and returns the message to the EBS.
If the provider application cannot process all of them in bulk, then the provider ABCS must invoke the services of the provider application for each of the instances, consolidate them, and return that message to the EBS.
4.9 Participating Applications Invoking ABCS
When a requester application encounters a business event, it might send a request to get details from another application by invoking an ABCS. At invocation, the requester application passes the ABM to the ABCS. The requester application can either pass everything an ABCS needs or pass the bare minimum. In the latter approach, the ABCS fetches from the participating application the details relevant to composing an EBM. Although the architecture supports both approaches, Oracle highly recommends that the participating applications use the first approach to minimize overhead.
Because the ABCS encloses an EBO in an EBM, the participating application must pass much of the EBM header content. For this reason, in addition to passing the business content, the participating application is also passing data related to the source environment. This information associates an EBM with the originator.
For more information, see Section 2.2.1, "EBM Architecture".
The participating application also specifies the locale used to construct the ABM. This locale interprets the locale-specific content. This enables the translation of locale-specific content into locale-independent content and vice versa.
4.10 ABCS Transformations
The transformations found in ABCS are participating application-specific components. The ABCS performs transformations and invokes the participating application's services. The transformations result replace application-specific fields with some generic fields and vice versa. Transformations also replace static and non-static application-specific identifiers with a common identifier. Non-static identifier-related transformations use the Mediator cross-reference facility. The design patterns used and the type of participating application determine the types and number of transformations done in a single ABCS. A single ABCS can interact with either a client-side or provider-side participating application.
For more information about ABCS, see "Working with Message Transformations" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
4.10.1 Transformation: Implementation Approach
You can implement ABCS transformations in two ways. First, an ABCS for a particular action can invoke an XSL file that performs all the transformations.
Second, the architecture allows you to provide transformations for additional elements introduced as part of a customer-specific implementation. Customer-specific transformations do not modify Oracle AIA artifacts and are unaffected by Oracle AIA upgrades.
The ABCS transformations handle:
-
Cross-referencing
-
Error-handling
-
Validation rules (such as format validation)
Transformations can be simple or complex. The Oracle AIA service handles the following transformation map patterns:
-
Data field mapping
-
Static data cross-referencing
-
Dynamic data cross-referencing
-
Structural transformation
4.10.2 Static Data Cross-Referencing
Different applications and common component objects frequently use different values for enumerated types. For example, a Country common component object may use the full country name, such as United States of America, while an ERP application may use a two-letter code, such as US. Static cross-referencing maps the values between an application and the common component object model. It would map the US and United States of America values presented in this example. Similar to dynamic cross-referencing, static cross-referencing uses a scheme to store and resolve the cross-references. However, in this case, the mapping is static and the mapping table is populated only at design time. The domain value mapping facility available in the Mediator facilitates static data cross-referencing.
4.10.3 Dynamic Data Cross-Referencing
Typically, each application generates its own set of identifiers or keys for the data objects that it stores. A data object replicated in multiple applications ultimately has different IDs or keys in different applications. Identifying that data objects are the same means identifying the mapping between these keys. The EBS provides a dynamic cross-referencing scheme that assigns a common or global key to data objects and maintains mappings between application-specific keys and the common key in a dynamic cross-referencing table.