| Oracle® Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.4.0) E17363-02 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack 11g Release 1 (11.1.1.4.0) E17363-02 |
|
Previous |
Next |
This chapter provides an overview of Application Business Connector Services (ABCS).
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.
The role of the ABCS is to expose the business functions provided by the participating application in a representation that is agreeable to a service interface.
In canonical integration style, the common service interface is the one exposed by Enterprise Business Services (EBSs). It can also serve as a glue to allow the participating application to invoke the 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 invoke the EBS exposed using the service interface defined by the provider.
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 role of the requester ABCS is to act as a vehicle to enable the participating application to invoke the EBS either to access data or to perform a transactional task. The client side ABM is the payload that is passed by the requester application to the requester ABCS.
The requester application that wants to leverage an action must define the requester-specific ABCS. The requester application that wants to implement this ABCS 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 role of the provider ABCS is to expose the business capabilities that are available in the provider application according to the EBS specification. In certain non-canonical integration styles, the EBS interface is defined by the provider. In other situations, the EBS artifact that acts as an abstraction layer might be present. 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 (in case of certain non-canonical integration styles) and sends the response using the same format. ABCS are needed because every application has a different representation of objects, and any communication between applications necessitates the transformation of these objects to the canonical definition.
The ABCS is responsible for the coordination of the various steps that are provided by a number of services, including:
Validation (if any)
Transformations - message translation, content enrichment, and normalization
Invocation of application functions
Error handling and message generation
Security
For each of the activities that can be performed with an Enterprise Business Object (EBO), an ABCS must be defined by the participating requester application and another ABCS must be defined by the service provider application.
For an application providing a business function to be a part of the Oracle Application Integration Architecture (AIA) ecosystem, it must be able to send messages that comply with either EBS or provider ABCS (in non-canonical integration styles) expectations. This ability enables the application to participate in cross-application business processes and prebuilt data integrations that exist in the Oracle AIA ecosystem.
Similarly, the application that receives messages from EBS must be able to understand the message types. Very few applications are built to readily interact with EBS. For applications that are not able to readily interact with EBS, ABCS act as conduits to expose the application-specific business functions in the Mediator.
The ABCS leverages a variant of the industry-standard integration pattern called the VETO -pattern. VETO is a common integration pattern that stands for Validate, Enrich, Transform, and Operate. The VETO pattern and its variations ensure that consistent, validated data is routed throughout the Mediator. The VETO pattern has many variations. A commonly known variation is the VETRO pattern. This includes the Route step.
The ABCS architecture adopts an extended variation of the VETRO pattern called the VETORO pattern illustrated in Figure 4-1.
The VETORO pattern consists of the following steps:
Validate
This step can be used to ensure that the incoming message has the right content so that it can be transformed into what the target system is expecting. In certain cases, the validate step can be used to check whether the incoming message contains a well-formed XML document that is in conformance with the particular schema associated with the receiving application. The latter validation is often performed as one of the first steps in the EBS and is needed to allow 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 converts the message to a target format by translating an application-specific object representation into an EBO, or translating an EBO-specific representation into the application-specific object representation of the Operate step.
Operate
This step is the invocation of the target service or an interaction with the target application. In Oracle AIA, it could be either an invocation of the EBS or a specific ABCS, or an interaction with the participating application using the provider ABCS.
Route
The Route step deciphers the appropriate service provider that is responsible for performing the service. In Oracle AIA, the Route step is implemented in the EBS using the content-based routing technologies that are available in Oracle Mediator.
In some cases, the validate, enrich, and transform steps can be accomplished in one ABCS implementation. Also, note that a Mediator routing service may use XSL-based validation as well as 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 as well as outbound interactions using only the SOAP/Mediator protocol. A transport adapter is used to integrate the participating application-specific native protocols with the ABCS-specific standard. This facilitates the reuse of the same ABCS for multiple transport adapters and vice versa.
The ABCS has the following characteristics:
For each of the activities that can be done on an EBO (canonical pattern-based integration style), an ABCS must be provided by each of the participating requester and provider applications.
In the case of a non-canonical pattern-based integration style, an ABCS must be provided by the provider application.
The requester ABCS has participating application-specific ABMs as input as well as output.
The service accepts requester application-specific ABMs as input and provides requester application-specific ABMs as output.
The provider ABCS has EBMs (representing specific content of EBO needed for performing the operation) as input as well as output.
The service accepts EBMs as input and returns EBMs as output.
Although a single ABCS can be used to 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. Doing this enables the ABCS to decipher the actual action to be performed and enables it to perform 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.
The architectural issues discussed in the following sections play a large role in determining your choice of implementation technologies as well as the design paradigms that you use to construct ABCS.
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 matches exactly that of an application-agnostic or provider application-specific interface
If an exact match exists, then much of your new effort will be to transform the application-specific ABM into the enterprise EBM and vice versa. Mediator would certainly be a candidate as the implementation technology for building the ABCS for this design paradigm.
In situations in which granularity of functionality exposed by the application through the web service does not match that of the EBS, attempts should be made to have appropriate modifications or enhancements made in the application. In situations in which these modifications cannot be made to the application, the ABCS is not only responsible for transformations, but also must aggregate and disaggregate services.
For example, perhaps 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.
This type of ABCS can be implemented only through BPEL technologies and not through Mediator services.
Although Oracle AIA allows for the existence of this type of ABCS, Oracle highly recommends that much of this application logic be encapsulated within native applications as opposed to having them handled in ABCS.
Because the EBS operates only on EBMs, you need to determine whether the applications that implement the services provide support for EBMs. In scenarios in which the application-provided services provide native support for EBMs, the effort for transforming the EBO into an EBM is minimal. In situations in which the applications that implement the services do not provide EBM support, you should determine whether their services can provide inherent support for EBMs.
If these applications cannot provide support for EBMs, transformation-related work must be done by the ABCS.
Perform a check to determine how the participating applications intend to allow the business logic to interact with the Mediator. Some applications may have inherent support for web service interfaces. This is the preferred scenario. The WSDL defines the interface that is used to communicate directly with the application business logic. In this situation, the ABCS uses the web service interface to invoke the application business logic.
In the case of packaged applications such as Siebel, PeopleSoft, J.D. Edwards, and SAP, the much-preferred route is to use the respective packaged-application adapters. These adapters can be deployed as J2CA resource adapters. This is a better solution than using the conventional SOAP interface. In situations in which the participating applications do not expose their business logic as web services, interactions with these applications must occur by means of technology adapters such as database adapters, advanced queuing (AQ) adapters, and so forth.
Investigate whether the services exposed by the participating applications provide support for proprietary message formats, technologies, and standards. If the applications that implement the functionality do not have inherent support for standards and technologies such as XML, SOAP, and JMS, then the transformations need to happen in the ABCS.
For example, the application might be able to receive and send messages only through files, and EDI is the only format that it recognizes. In this case, the ABCS becomes responsible for integrating with the application using a file adapter, translating the EDI-based message into XML format, and exposing the message as a SOAP message.
For more information, see "Establishing Resource Connectivity" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
The ABCS is responsible for facilitating logging and monitoring capabilities. The ABCS invoke the 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.
Situations occur in which the granularity of the service that is provided by the service provider does 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 interface that is defined by the EBS warrants that the service provider return complete details about a bill, including all of the details. In this case, it becomes the responsibility of the ABCS to provide protection to the application implementing the service by doing the 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.
The security model that you choose plays a large role in determining which responsibilities are owned by the ABCS. 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.
In the latter scenario, Web Services Security can be used if all participating systems provide support for it. Otherwise, transmitting security credentials either as application data or as a part of the SOAP header is an option. Depending upon the route taken, the ABCS must be coded accordingly so that it can be authenticated.
As the message travels from one participating application to another, validations need to occur at various stages throughout the journey to ensure that accurate and valid data is being sent to the target system. The specificity of the validations varies significantly depending on how far or close the message is from the target system.
Validations are based on the constraints that are imposed by the participating application providing the service. The ABMs generated from the EBMs need to comply with the constraints imposed by the participating applications. In addition, the target system may have its own built-in validation rules, which necessitates that the transformation step alter incoming data to prevent rejection of the message by the target system.
Because not all participating application-specific constraints can be enforced at the EBM level, these validations must be enforced by the specific ABCS. 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 is responsible for ensuring that the ABM generated from the EBM includes the product description. This validation ensures that the ABM that is passed to the PeopleSoft CRM Create Product service is compliant with the constraints imposed by the service.
If the previously mentioned constraint is very specific to the PeopleSoft CRM application, then this validation 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.
In the case of asynchronous interaction styles (request-only), where the user experience is hindered if validations are not performed at the time of capture, the requester application should use another integration point to perform the validation before submitting the message for processing. For example, in an Order Capture application, before submitting the order for fulfillment, the requester application makes a synchronous call to validate the order to ensure that the order contains the content required to enable successful provisioning. A Validate Order or Validate Billing Information EBS might exist that can be implemented by various service providers. If the response from the Validate Order service is favorable, the requester application then makes the request to process the order.
The ABCS that pass the EBMs to the actual service providers are responsible for translating the document into a locale-specific ABM. Similarly, the ABCS is responsible for translating the locale-specific ABM into the locale-independent EBM.
The ABCS deciphers the locale based on the locale preferences of the user of the relevant participating application. This data provides information about how the locale-specific ABM must be constructed, as well as how the locale-specific ABM must be interpreted.
The ABCS should specify the locale in which the response must be provided by the real service provider. For example, the ABCS for Get Product Details EBS must specify the locale in which the product details should be provided by the Oracle eBusiness Suite application. If the requester wants the product details in Spanish, the Get Product Details EBS must instruct the real service provider that the product details need to be returned according to the Spanish locale.
You may need to combine responses to a request that originates from multiple sources. For example, in the case of convergent billing in the telecommunication solution, the ABCS for the getBillDetails EBS might have to retrieve details from multiple participating applications. This ABCS is also responsible for consolidating them into a single response.
You may have multiple instances of a packaged application with the same business capabilities in your company's ecosystem. The routing rules defined in the EBS are responsible for deciphering the right application instance to which the request must be routed. Regardless of the number of application instances for a packaged application, only one ABCS exists for that packaged application to perform a specific business task.
Each of the participating applications implementing a business activity or task has its own ABCS.
An ABCS for a particular participating application should be responsible for implementing a single action. The action is the same in the case of a synchronous request-response pattern. In the case of a delayed response pattern, the carrying out of the request is implemented by one action and the carrying out of the response is implemented by another action. Hence, two ABCS would exist.
The ABCS can be implemented in two ways:
The first approach is to make complete use of components that are built using Oracle Fusion Middleware technologies to make up the ABCS.
The service is implemented as a Mediator service or a BPEL process. This Mediator service or BPEL process performs the tasks listed in the following sections.
The second approach is to build the transformation services, to a large extent, as part of the participating application.
This approach can be taken when the participating application's technology stack has the infrastructure to 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 exists that is exposed as a WSDL. This is what the client applications use to invoke the ABCS.
The transformations for each of the directions in both the client-side and server-side ABCS are implemented XSL scripts.
The ABCS itself should be independent of deployment. In situations in which multiple deployments of a single client or provider application exist, only one instance of an ABCS exists. For example, two deployments of BRM Billing applications could exist, one for customers who reside in North America and the second for customers living in the rest of the world. In this case, only one BRM application-specific ABCS would still exist for a particular action. Under no circumstances should two versions of the ABCS exist, one for each deployment. A single ABCS should be responsible for invoking the application business service that is available in the appropriate deployment.
In many situations, a single action cannot be mapped to a single API or operation in the provider 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-side ABCS probably has a chatty conversation with the server application. The provider-side ABCS is also responsible for state management.
This type of ABCS can be implemented using only BPEL technologies and not through Mediator services.
Although Oracle AIA allows the existence of this type of ABCS, Oracle highly recommends that much of this application logic be encapsulated within native applications as opposed to having them handled in ABCS.
The service is responsible for populating the message header section of the EBM with values. The service deciphers some of the values by itself, whereas for other values it relies on the content being passed by participating applications through an ABM.
For more information, see Section 2.2.1, "EBM Architecture".
The requester-side ABCS has the following core responsibilities:
Enrichment or augmentation of the ABM.
This may be required in situations in which the ABM received from the participating application does not contain all of the required content. The enrichment can be done by issuing additional calls to the participating application to get more information. For example, a CRM application might pass only the order identifier as part of the ABM. The interface for ProcessOrder EBS might warrant that the entire order object be passed as the payload. In this situation, the ABCS is responsible for interacting with the participating application to get all of the required information 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.
You can use the extension handler to perform any additional transformations. The extension handler is passed to the EBM and the transformed EBM is passed back as the response. This extension handler enables you to perform additional transformations on the EBO before the EBS is invoked.
Invocation of the EBS.
The EBS is responsible for taking an EBM and providing the response using an EBM.
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. This extension handler enables you to perform additional transformations on the ABM before the ABM is passed back to the calling application.
Perform any necessary validations to ensure that the ABM that must be passed to the participating client application complies with the constraints enforced by the participating application.
Return the response to the calling application.
Figure 4-2 illustrates the high-level flow of activities in a requester-specific ABCS. The diagram makes an assumption that the EBS with which it is interacting employs a request-response interaction style. Note that 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 diagram makes an assumption that the EBS with which it is interacting employs a fire-and-forget interaction style. Note that the steps for running the extension to do additional transformations are optional.
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.
You can use this extension handler to perform any additional transformations. The extension handler is passed to the ABM and the transformed ABM is passed back as the response. This extension handler enables you to perform additional transformations on the ABM before the ABM is passed to the provider application business service.
Performance of any necessary validations to ensure that the ABM that must be passed to the participating provider application complies with the constraints enforced by the participating application.
Invocation of the provider application business service.
One or multiple calls may be made to the provider application business service.
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 EBS. Because EBS expects only EBM as the output, the transformation must be done to transform the ABM 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.
You can use this extension handler to perform any additional transformations. The EBM is passed to the extension handler and the transformed EBM is passed back as the response. This extension handler enables you to 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 diagram makes an assumption that the EBS with which it is interacting employs a request-response interaction style.
Figure 4-5 depicts the high-level flow of activities in a provider-specific ABCS. The diagram makes an assumption that the EBS with which it is interacting employs a fire-and-forget interaction style.
Oracle AIA provides two blueprints for implementing an ABCS: Oracle Mediator and BPEL.
The Oracle Mediator blueprint can be applied in situations in which you do not need the ABCS to do additional enrichment and validation of the content. In this model, the ABCS are implemented as Mediator services.
You can add transport adapters either before the client-side ABCS or after the provider-side ABCS to use a different transport using only configuration changes.
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.
BPEL is used when the ABCS must augment content, validate content, or both. In most situations, the ABCS must have a conversation with one or more participating applications to enrich the content. It may also have to handle state management.
In this scenario, BPEL is the preferred technology. BPEL enables you to perform the tasks listed previously and also enables you to extend the connector. This architecture does not preclude you from implementing the ABCS using procedural object-oriented languages such as Java or C++.
BPEL is also used when a Mediator service can't be used to implement the ABCS either due to the constraints in Mediator technology or due to the 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.
Oracle AIA facilitates the use of different transports without having to modify 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 by which the services provided by the participating application are invoked without having to modify the ABCS.
Each of the client-side and provider-side ABCS implementing request-response pattern provides four extensibility points. In the case of the requester ABCS, two extensibility points are provided prior to the invocation to the EBS and two after the receipt of response message from EBS. In case of provider ABCS, two extensibility points are provided prior to the invocation of application-specific service and two after the receipt of response from the application service. In case of fire-and-forget patterns, the ABCS have only two extensibility points. These extensibility points can be used to inject additional behavior. The services for injecting additional behavior can have capabilities such as custom validation or custom transformations. Transformations are used primarily for any additional elements that have been introduced at the implementation site. You can use this feature to introduce any additional processing that must be done without having to customize the delivered ABCS. The extension service is passed either the EBM or the ABM, depending on the situation. The content is passed as context to the extension service and the extension service 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.
Because an EBM can carry multiple instances, the provider ABCS should be able to iterate through each of the instances and process them. Not all EBMs have support for carrying multiple instances. But EBMs that are created specifically for supporting bulk processing can be defined to support multiple instances.
The 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 does not have the capability to 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.
When a requester application encounters a business event, it might send a request to get details from another application by invoking an ABCS. At the time of invocation, the requester application passes the ABM to the ABCS. The requester application can either pass everything that an ABCS will ever need or it can pass just the bare minimum, which in turn could be used by ABCS as the driver to fetch relevant details from the client-side participating application. In the latter approach, the ABCS might need to engage in conversations with the participating application to get all of the details relevant to compose an EBM. Although the architecture can support both approaches, Oracle highly recommends that the participating applications resort to the first approach to minimize overhead.
Because the ABCS is responsible for enclosing an EBO in an EBM, much of the information pertaining to population of the EBM header with attributes also must be passed by the participating application. For this reason, in addition to passing the business content, the participating application is also passing data that is related to the source environment. This information is needed to associate an EBM with the originator.
For more information, see Section 2.2.1, "EBM Architecture".
The participating application is also responsible for specifying the locale that was used to construct the ABM. This locale can be used to interpret the locale-specific content. This enables the translation of locale-specific content into locale-independent content and vice versa.
The transformations found in ABCS are participating application-specific components. The main responsibility of ABCS is to perform transformations and invoke the services provided by the participating application. The transformations result in replacement of application-specific fields with some generic fields and vice versa. The transformation also involves the replacement of any static and non-static application-specific identifiers with a common identifier. The non-static identifier-related transformations are done with the help of the Mediator cross-reference facility. The types and number of transformations done in a single ABCS depend upon the design patterns employed and the type of participating application with which the service is interacting. 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.
Two ways are available by which transformation can be implemented. In the case of ABCS that are specific to a particular action, the entire set of transformations is present in an XSL file. The ABCS invokes the XSL file to perform the transformations.
The architecture also provides a facility for you to provide transformations for additional elements that were introduced as a part of their implementation. Customer-specific transformations do not modify the artifacts delivered by Oracle AIA and hence will survive upgrades.
The ABCS transformations handle:
Cross-referencing
Error-handling
Validation rules (such as format validation)
Transformations can be simple or complex. The following transformation map patterns are handled by the Oracle AIA service:
Data field mapping
Static data cross-referencing
Dynamic data cross-referencing
Structural transformation
Different applications and common component objects frequently use different values for enumerated types. For example, the values for the Country common component object may be the full country name, such as United States of America, while it could be a two-letter code, such as US in an ERP application. 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 that is available in the Mediator is used to facilitate static 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 given data objects are the same becomes an issue of 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.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
