1 Understanding the Oracle AIA Reference Architecture
This chapter introduces Oracle Application Integration Architecture (AIA) and integrations and provides an overview of Reference Process Models, Shared Service Inventory, and AIA Service Artifacts.
This chapter includes the following sections:
1.1 Introduction to Oracle Application Integration Architecture
Oracle Application Integration Architecture (AIA) is a complete integration solution for orchestrating agile, user-centric business processes across enterprise applications. AIA offers prebuilt solutions at the data, process, and user interface levels, delivering a complete process solution to business end users. All of the AIA components are designed to work in a mix-and-match fashion. They are built for configurability, ultimately helping to lower IT costs and the burden of building, extending, and maintaining integrations.
Powered by Oracle Fusion Middleware, AIA enables organizations to use the applications of their choice to create Composite Business Processes (CBPs) following these guiding principles, which define the ground rules for development, maintenance, and usage of a service-oriented architecture (SOA):
-
Reuse, granularity, modularity, compose ability, componentization, and interoperability.
-
Standards-compliance (both common and industry-specific).
-
Service identification and categorization, provisioning and delivery, and monitoring and tracking.
1.2 AIA Features
AIA Foundation Packs provide the methodology, framework, and content that is critical for customers to figure out their integration problems.
Figure 1-1 illustrates the main AIA features and the underlying technology.
Table 1-1 lists the main features of AIA and how these features are delivered.
Table 1-1 AIA Features and Related Deliverables
| Features | Deliverables |
|---|---|
|
A robust architectural framework for engineering service-oriented business processes. |
|
|
Support for interaction styles to handle high transaction rates and volumes that are associated with mission-critical applications. |
Reference Architecture for different integration styles with and without canonical abstractions. |
|
Ability to leverage functionality provided by various Oracle and customer-owned software assets. |
Programming Models for constructing and assembling different types of AIA service artifacts that leverage various Oracle tools. |
|
Ability for customers to extend various AIA artifacts delivered as part of Pre-Built Integrations. |
Programming Models for extending various AIA service artifacts. |
|
Support for process model decomposition and analysis, service design, service construction, process definition, deployment plan generation, deployment, and upgrade. |
Project Lifecycle Workbench and Deployment Plan Generator |
|
Governance of design-time and run-time AIA artifacts. |
Oracle Enterprise Repository |
1.3 Understanding Integrations
This section includes the following topics:
1.3.1 The Integration Flow Concept
An integration flow represents the journey of a message from a business event-triggering source, through possible intermediary milestones, to one or more target milestones as shown in Figure 1-2. At each milestone, the message is stored in a different state.
An integration flow represents the run-time path of a message. It is not a design-time artifact.
There is no "one size, fits all" approach to integration. The requirements and objectives of the integration drive the selection of integration styles and supporting design patterns. AIA supports a variety of integration styles and patterns to enable the flight of a message in an integration flow. The AIA artifacts required for the collaboration between applications or functions are dependent on the integration style adopted for an integration flow.
1.3.2 Integration Styles
The following sections provide details about each of these integration styles:
-
Data-centric integration
-
Integration through native interfaces
-
Integration through Web services
-
Reference data query
-
Process-centric integration
Figure 1-3 illustrates the flow of each integration style.
1.3.3 Data-Centric Integrations
Data-centric integrations transform data from its source format into its target format. They provide some level of logic in the transformation process to make it useful and coherent to the target environment.
Typical requirements driving data-centric integrations include bulk data replication, where no individual message based processing is required, or where multiple data enrichment activities are not required to populate the target system.
- Example 1 Initial Data Synchronization
-
Initial data synchronization occurs between a running application that contains meaningful but nonvolatile data and a new application that is being installed. This typically makes on-going integration efforts using one or more of the integration styles much simpler to achieve.
- Example 2 Bulk Upload of Recurring Transactions
-
An example of a bulk upload of recurring transactions is sales orders that must be tallied for commission payments to the appropriate sales people. The commission payments are made either quarterly or monthly, and while sales activities are going on every day, there is no need to have this information available in real time.
1.3.3.1 What Oracle Provides
Oracle provides two data-centric integration tools: Oracle Golden Gate and Oracle Data Integrator.
Oracle Golden Gate uses the change data capture logs of the databases and can work across a heterogeneous database landscape, while Oracle Data Integrator works directly with the database tables and utilizes an extract, load, and transform approach to its handling of the data.
Oracle delivers several pre-built data-centric integrations. Among them are the sales order and commission payments use case described previously and an automated scheduler to publish general ledger reports from one application to another. They provide capabilities for general ledger reports, such as incremental and cumulative revenue reporting, automated report regeneration, and the ability to customize reports.
1.3.4 Integration Through Native Interfaces
Every application executes on top of its own technology stack. Based on the application architecture, there may be one or more supported ways to integrate with the application. For example, Oracle E-Business Suite exposes public Java interfaces, PL/SQL APIs, business events, and batch interfaces to allow a wide range of integration options for customers and partners.
Typical requirements driving data-centric integrations include a simple exchange of business-oriented messages or consumption of more sophisticated application capabilities exposed through these interface mechanisms. One example of the use of native interfaces is providing enterprise data through multiple channels, such as web and voice, where the application itself has no such capability, and the speed of delivery is critical due to a high degree of human interaction.
1.3.4.1 What Oracle Provides
From a technology foundation perspective, each application exposes one or more mechanisms for integration based on its native technology stack. Some applications provide extended tooling to assist with the exposure, configuration, customization, and extension.
Through the Oracle Validated Integration program, several pre-built integrations created by Oracle partners exist, which take advantage of the applications' native interfaces. For example, one of Oracle's partners integrates with Siebel CRM to provide multi-channel access to contact center information. This improves customer satisfaction with their interactions to the call center by allowing customers to choose their method of interaction (phone, chat, email, fax, letter, and so forth.) and get a consistent experience regardless of the medium.
1.3.5 Integration Through Web Services
XML-based Web services are a technology platform-independent way of exposing application interfaces. Using XML as the common language, business transactions are sent from one application to another in near real time. Web services are exposed using industry standards such as WSDL and SOAP (or in a REST-ful manner), shielding the implementation and connectivity details of the provider application from the consumer. The primary requirement which leads to the use of Web services is similar to that of native integrations, which involves the exchange of business messages. The key difference is the need to integrate applications across a wide variety of potentially incompatible technology platforms, including integration with third-parties (for example, business-to-business scenarios or the use of Software-as-a-Service). This eliminates the use of the native interfaces as an option.
1.3.5.1 What Oracle Provides
Oracle Fusion Middleware, including SOA Suite and Adapters (bridging from an application's native interfaces to the world of Web services), allows for the consumption, composition, and integration of applications using Web services. The inclusion of Fusion Middleware to support Web service-based integration enables an expanded set of Quality of Service characteristics, like resiliency, scalability, guaranteed delivery, and security.
Through the Oracle Validated Integration program, several pre-built integrations created by Oracles partners exist, which take advantage of the applications' Web service-based interfaces. One partner has leveraged PeopleSoft's Web services interfaces and Oracle Fusion Middleware to exchange standard HR-XML schemas. As a result, ordering a background check on an applicant is a matter of just a few clicks, and after a report is complete, the detailed search results can be viewed immediately from within the PeopleSoft Enterprise interface.
1.3.6 Reference Data Query
Reference data query addresses supplemental information important to completing and or facilitating business transactions, but is not in and of itself part of the primary integration activity. Web services have further fueled the availability of reference data from third-party providers, and many companies offer reference data services on a subscription basis.
Typical use cases include geocode or tax code lookups, evaluating availability to promise (ATP) for inventory/manufactured goods, or something as common as retrieving an account balance.
1.3.6.1 What Oracle Provides
Oracle Fusion Middleware, including SOA Suite and Adapters (bridging from an application's native interfaces to the world of Web services), allows for the consumption, composition, and integration of applications using Web services. The inclusion of Fusion Middleware to support Web service-based integration enables an expanded set of Quality of Service characteristics, like resiliency, scalability, guaranteed delivery, and security.
Through the Oracle Validated Integration program several pre-built integrations created by Oracle partners exist which take advantage of the applications' Web service-based interfaces for reference data query. One partner provides a pre-built integration with Oracle E-Business Suite for tax jurisdiction lookup and tax calculation. The partner's solution includes a SOAP service, deployed at the customer site, which then invokes their Software-as-a-Service system for geocode lookup and tax calculation. The interface leverages the tax partner subscription method of Oracle E-Business Tax for third-party tax vendor integration.
1.3.7 Process-Centric Integration
While many applications expose Web service interfaces, there is a growing need for a more coordinated exchange of messages between applications. This orchestrated exchange of messages is typically intended to support one or more business processes. As a part of the orchestration of messages, additional activities may take place, such as message transformation, enrichment, or validation.
An example of the process-centric integration style is the orchestration of transactional data, from the point of capture through transformation and movement to back-office systems. You can also use this style to drive the movement of transactional data through a process, based on a business event.
1.3.7.1 What Oracle Provides
From a technology foundation perspective, Oracle provides support for the definition and orchestration of business processes through the SOA Suite and BPM Suite offerings. In addition to the expanded set of QoS capabilities, Oracle provides tools to visualize and define the orchestration itself.
Oracle delivers several pre-built process-centric integrations. One helps orchestrate the conversion of an opportunity into a Quote or Order. Another orchestrates the bi-directional consolidation of Account, Contact, Opportunity, and Product information between an organization's on-premise solution and their On Demand instances in real time.
1.3.8 What Integration Pattern Should be Used: Direct Transformation Of The Data Objects or a Canonical Data Model And EBOs?
Use of canonical Enterprise Business Objects (EBOs) is an integration best practice, especially in integrations that involve connectivity with multiple source and destination systems. However, use of a canonical data model introduces some overhead and might introduce unnecessary engineering work.
Figure 1-4 illustrates an approach for deciding between a direct point-to-point transformation or a canonical data model and EBOs.
1.4 AIA and Integration Styles
This section includes the following topics:
1.4.1 Pre-built Integration Accelerators
Oracle AIA delivers pre-built Integration Accelerators in two formats:
1.4.2 Integration Through Native Application Interfaces Using the Oracle Applications Technology Infrastructure
In this style, messages flow from the requester application to the provider application. The mode of connectivity could be SOAP/HTTP, queues, topics, or native adapters. No middleware is involved in this integration.
The requester application must establish the connectivity with the provider applications. It is the responsibility of the requester application to send the request in the format mandated by provider's API, and to interpret the response sent by the provider. In addition, the requester and provider applications are responsible for the authentication and authorization of requests.
The integration flow consists of individual application functions interacting directly. All capabilities required to make this interaction possible must be available in the individual applications.
Figure 1-5 illustrates how a requester application interacts directly with the provider application.
In more complex situations in which the integration flow consists of multiple steps involving interactions with multiple applications, one or more applications must leverage workflow-like capability.
There are no AIA artifacts to be built in this case. Direct connectivity must be established between applications.
1.4.3 Direct Integration Through Application Web Services Using Oracle SOA Suite
A provider's application-specific AIA service, exposing a coarse-grained functionality of the provider application leveraging one or more APIs, is created with a suitable application-specific interface.
Several business initiators can invoke this AIA service. If the business initiators cannot present the request in the format understood by the provider's application-specific AIA service, a requester's application specific-AIA service is used to transform the business initiator request into the provider's application format.
The requester's application-specific AIA service is responsible for the authentication and authorization of the requests. The provider's application-specific AIA service propagates the authentication and authorization information of the requests to the provider application.
The integration flow consists of a requester's application-specific AIA service artifact deployed on the middleware that manages interactions with all provider application-specific AIA services.
Figure 1-6 illustrates how a service deployed to the middleware enables the integration between the requester and the provider applications.
In more complex situations in which the integration flow involves interactions with multiple applications, the requester's application-specific AIA service implements a workflow-like capability and manages interactions with all the provider's application-specific AIA services.
The complexity of the data exchange and the various message exchange patterns involved, determine the AIA service artifacts that must be developed.
1.4.4 Integration Through Packaged Canonical and Standardized Interfaces Using Oracle Foundation Pack
Use SOA for loose coupling through a canonical (application-independent) model to simplify integration involving many instances of the same or similar participating applications. Participating applications in loosely coupled integrations communicate through a virtualization layer. Instead of direct mappings between data models, transformations map to the canonical data model. While this allows for greater reusability, the transformations both increase the message size and consume more computing resources. For integrations at the business logic tier, this is the ideal integration pattern, because the reusability gained is worth the increased overhead cost. Most important, this isolates the impact on the overall integration of changes to one of the participating applications. This effectively brings the cost of maintaining these more complex integration scenarios in line with the costs of a single point-to-point integration.
In this case, an Enterprise Business Service (EBS) based on relevant Enterprise Business Objects (EBOs) and Enterprise Business Messages (EBMs) is created as a mediator service.
A provider service, exposing a coarse-grained functionality of the provider application leveraging one or more APIs, is created with the same EBM interface as the EBS operation interface.
If the business initiators cannot present the request in the format understood by the EBS operation interface, a requester service transforms the business initiator request to the provider service format.
Figure 1-7 illustrates how the request sent by the source application is processed by target application with the help of the EBS and a set of intermediary services. The request and provider transport services are optional. They are needed only for non-SOAP-based transports.
In more complex situations in which the integration flow involves interactions with multiple applications, the requester's application-specific AIA service presents its request to the mediator AIA service. The mediator AIA service triggers an AIA service that implements a workflow-like capability and manages all interactions with the provider application-specific AIA services through mediator AIA services.
The mediator AIA service interface chosen must be accepted as a common interface. Thus, all requester application-specific AIA services invoke this mediator AIA service and all provider application-specific AIA services implement this common interface. The complexity of the data exchange and the various message exchange patterns involved, determine the AIA service artifacts that must be developed.
1.4.5 Bulk Data Integration with an Extract, Transform, and Load Approach Using Oracle Data Integration Suite
Bulk data processing involves a large batch of discrete records or records with very large data sets. This is a point-to-point integration for data movement with high performance but less reusability than a canonical model.
1.4.5.1 Integrations for High-Volume Transactions without an Xref Table
When storing cross-reference (Xref) data for high-volume transactions does not make sense, AIA recommends using a point-to-point integration using Oracle Data Integrator.
For example, suppose a retail store chain headquarters receives business transaction data from individual retail stores at the end of each day after each store closes. Each store sends a day's worth of business transactions to headquarters according to its closing time and time zone. Because no data manipulation language (DML) operates on such data sets, no storage of Xref data between local stores and headquarters is needed.
Figure 1-8 illustrates a high-volume transaction integration without an XRef table.
The steps to load data are the same as those for using an Oracle Data Integrator package. There is no AIA component in this architecture. Local Enterprise Resource Planning (ERP) applications load their interface table and invoke an Oracle Data Integrator package to send data to the headquarters interface table. After the data is processed, the Oracle Data Integrator updates the local ERP application's interface table with a status of Transferred or Processed for each row.
For more information about bulk data integration, see "Using Oracle Data Integrator for Bulk Processing" in the Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.
1.5 AIA Reference Process Models
AIA Reference Process Models are collections of best practices from various Oracle application portfolios. These AIA models are delivered as Oracle Business Process Analyzer content.
Reference Process Models serve the following purposes:
-
Help categorize Business Processes into Business Activities and Tasks
-
Build a repository of reusable Business Activities and Tasks
-
Establish key performance indicators
-
Aid in identifying equivalent AIA service artifacts described as part of the AIA service inventory
For more information about Reference Process Models, see the Oracle Fusion Middleware Reference Process Models User's Guide for Oracle Application Integration Architecture Foundation Pack.
Figure 1-9 illustrates the relationship of business processes, activities, and tasks that is described in the following sections.
1.5.1 What is a Business Process?
A set of activities and tasks accomplished in a particular business area are treated as a business process. Examples include Sales Management, Inventory Management, and so on. In themselves, they do not deliver business value. Coordination of business processes from different business areas creates business value.
1.5.2 What is a Business Activity?
A Business Activity is a coordinated set of Tasks. A Business Activity is equivalent to a subprocess. Examples include Process Payment, Ship Goods, and so on. One application or a combination provides business activity functionality.
1.5.3 What is a Task?
A Task is an elementary activity or atomic process capable of handling a unit of work. It cannot be split further without a loss of business meaning. It can be implemented by one or more providers. Examples include Create Customer, Query Payment, and so on.
1.5.4 What is a Composite Business Flow?
A Composite Business Flow is a set of coordinated tasks and activities, involving both human and system interactions across one or more business areas, which leads to accomplishing a set of specific organizational goals. Characteristics of Composite Business Flows include the following:
-
Large, complex, and long running
-
Widely distributed and customized
-
Dynamic
-
Automated
-
Both business-oriented and technical in nature
-
Crossing boundaries within and between businesses
-
Dependent on and supportive of human intelligence and judgment
-
Difficult to recognize
1.6 The Conceptual View of AIA
This section includes the following topics:
1.6.1 What is a Service Consumer?
A Service Consumer is the initiator of a business process, business activity, or task in an enterprise. It has knowledge of the available AIA Conceptual Services and can present requests accordingly.
1.6.2 What are AIA Conceptual Services?
AIA Conceptual Services are developed using Oracle Fusion Middleware technologies. They constitute the service portfolio for the SOA implementation and enable the following:
-
Reuse, granularity, modularity, composeability, componentization, and interoperability
-
Standards-compliance (both common and industry-specific)
-
Service identification and categorization, provisioning and delivery, and monitoring and tracking
AIA Conceptual Services are categorized into Process Services, Activity Services, Data Services, Connector Services, and Infrastructure Services.
Figure 1-10 depicts the conceptual services of AIA.
1.6.3 What are Provider Applications and Resources?
Various applications acquired for their best-of-breed functionalities and any legacy applications built in-house are Provider Applications and Resources. Each of these applications exposes business functions, such as APIs, and can be accessed using different modes of connectivity.
1.7 The AIA Shared Service Inventory
Shared Services are application-agnostic services leveraged to build cross-application Composite Business Processes (CBPs). A successful AIA implementation is dependent on a robust Shared Services Inventory.
The various categories described in this section help relate Shared Services to Reference Process Model artifacts. Figure 1-11 depicts elements in the Shared Services Inventory.
1.7.1 What is a Process Service?
A Process Service is the implementation of major business events that have a significant impact on running the enterprise. It involves work being accomplished with the help of multiple resources.
Process Services automate business processes, orchestrate a series of human and automated steps, and normally span multiple information systems. They are analogous to Business Processes in AIA Reference Process Models.
Process Services in AIA define and automate business processes that are external to and independent of the specific back-end systems used in the organization. This shields business processes from back-end system changes. Similarly, applications are isolated from business process changes. Loose coupling between business processes and applications simplifies changes and maintenance for both.
Figure 1-12 depicts some characteristics of Process Services.
The structure of the information packets passed around must be rich enough to capture the significant event details. These can be custom-defined or accepted canonical messages, independent of the enterprise applications. Process Services leverage the Activity Services and Data Services and are triggered by significant business event initiators, such as CRM, UI applications, and business-to-business (B2B), for example.
1.7.2 What is an Activity Service?
An Activity Service represents an atomic business unit of work and has a set of steps involving system-to-system interactions. Activity Services may also warrant orchestration. In some cases, there may be matching application capabilities. These are exposed as mediator services on the service bus. Activity Services can act upon multiple canonical messages and be consumed by participating applications and process services. The structure of the message is either canonical or a user-defined format.
Figure 1-13 depicts some characteristics of Activity Services.
Activity Services are analogous to the Business Activities and Tasks in the AIA Reference Process Models. In some cases, multiple lower-level operations are combined to form an Activity Service, thereby hiding the complexity of the lower-level operations.
1.7.3 What is a Data Service?
A Data Service provides an aggregated, real-time view of enterprise data. Data consumers interact with enterprise data using Data Services. Data Services are primarily create, read, update, and delete (CRUD) operations that act upon canonical or user-defined messages. They are exposed on the service bus as mediator services.
Data Services eliminate point-to-point links at the data level and direct dependency on the data models of data sources. Data Services can be consumed by participating applications, process services, and activity services.
Figure 1-14 depicts some characteristics of Data Services.
Data Services are analogous to Tasks in AIA Reference Process Models.
1.7.4 What is a Utility Service?
A Utility Service provides error handling, diagnostic, and logging facilities across AIA implementations.
Figure 1-15 depicts some characteristics of Utility Services.
1.7.5 Implementing Process Services
The CBP AIA service artifact is an implementation of a Process Service.
1.7.5.1 Common Scenarios for Process Services
Process Services are analogous to Business Processes in AIA Reference Process Models, so they have the same goal: enabling structured accomplishment of work in an enterprise to ensure consistency and efficiency with low cost.
A Reference Process Model Business Process consists of a set of business activities and tasks. There is a judicious mix of automated and manual tasks.
Process Services leverage technology and provide implementation software that can be executed on the application server. They leverage activity services and data services.
Following are two Process Service examples.
- Example 1 Resolve Customer Complaint Process Service
-
A business process defined to resolve complaints could:
-
Analyze a complaint and identify activities.
-
Schedule a call, block resources, and assign a technician.
-
Track activities and send statuses.
-
Close the complaint, generate metrics, and update statuses.
-
- Example 2 Settle Auto Accident Claim Process
-
A business process to settle auto accident claims could:
-
Analyze the claim and identify the parties and insurance agencies involved.
-
Schedule appointments and assign agents for collecting facts.
-
Compare facts collected with those from other agencies and attribute fault and settlement.
-
Send for approval.
-
Figure 1-16 illustrates a process service implementation.
1.7.6 Implementing Activity Services
If the EBS operation invokes an Enterprise Business Flow (EBF), the EBS AIA service artifact is the implementation of an activity service. In very few situations, an application might directly expose the needed functionality. In this case, an EBS operation may call an Application Business Connector Service (ABCS).
1.7.6.1 Common Scenarios for Activity Services
Activity Services are analogous to Business Activities in AIA Reference Process Models, so they have the same goal: providing a structure to accomplish work with the help of granular tasks. Typically, an orchestration flow implements Activity Services. The orchestration flow connects a set of tasks. Activity Services can leverage other activity services and data services.
Following is an Activity Service example.
- Example 1 Creation of Customer in Billing Systems
-
An activity service can create a customer in a billing system using an order document. This service may be composed of the following steps:
-
Retrieval of a set of account identifiers from an order document
-
Retrieval of account particulars from a CRM system
-
Creation and update of customers in a billing system
-
1.7.7 Implementing Data Services
The EBS AIA service artifact is an implementation of a data service.
Data Services are analogous to Tasks in AIA Reference Process Models, so they have the same goal: providing a structure to accomplish work with the help of application provider services. Data Services leverage application provider services.
1.8 AIA Service Artifacts
This section includes the following topics:
1.8.1 What is a Composite Business Process?
A Composite Business Process (CBP) is a set of coordinated tasks and activities involving both human and system interactions. It is an implementation of the AIA Reference Process Model Business Process and is a Process Service.
In AIA, CBPs are implemented, managed, and monitored as a single SOA composite using SOA BPEL along with SOA Mediator, SOA Human Workflow, and SOA Business Rules components. The BPEL components drive the flow.
1.8.2 What is an Enterprise Business Service?
An Enterprise Business Service (EBS) is a first-class object exposed on the enterprise service bus. An EBS is coarse-grained and performs a specific business activity or task and is either an Activity Service or Data Service.
For example, the activity it performs could be one of the following:
-
Creating an account in a billing system.
-
Checking for the presence of an account in a billing system.
-
Getting the balance details for an account from a billing system.
An EBS is agnostic to a specific back-end implementation. Back-end implementations that support EBS interface standards can be considered service providers. EBSs expose coarse-grained, message-driven interfaces for exchanging data between applications, both synchronously and asynchronously.
The salient features of EBSs include:
-
Reuse of available assets in the Oracle portfolio.
-
Substitution of a service provider with another without any impact to the client.
-
Content-based selection of the service provider.
Figure 1-17 shows how an EBS enables the loose coupling of requesters with actual service providers.
1.8.3 What is an Enterprise Business Flow?
An Enterprise Business Flow (EBF) implements a business activity or a task that involves leveraging capabilities available in multiple applications. An EBF strings a set of capabilities available in applications to implement a coarse-grained business activity or task and composes a new service that leverages existing capabilities. An EBF involves only system-to-system or service-to-service interactions and does not include any activity that requires human intervention.
In a canonical integration, the EBF is an implementation of an EBS operation and calls other EBSs. An EBF never calls an ABCS or application directly. In other integration styles, the caller invoking the EBF can be an application or any other service.
Oracle Service Bus can implement an EBF for stateless coordination of synchronous or one-way business activities, where BPEL coordinates asynchronous activities.
Figure 1-18 illustrates how the EBF orchestrates a flow for synchronizing customers between the source application and the target application. When the source application invokes the sync operation, the EBF first determines if the customer exists in the target application. If so, it updates the customer in the target application. If not, it creates the customer in the target application.
1.8.4 What is an Application Business Connector Service?
An Application Business Connector Service (ABCS) implements the EBS interface by exposing the business functions provided by the participating application. Figure 1-19 illustrates how the ABCS functions in the integration flow.
The ABCS coordinates the various steps provided by several business functions exposed by a provider application. For example:
-
Validation
-
Transformations: message translation, content enrichment, and normalization
-
Invocation of application functions
-
Error handling and message generation
-
Security
Figure 1-20 illustrates an ABCS implementation, in this case the CRM application querying an account balance from the billing system.
