| Oracle® Fusion Middleware Administrator's Guide for Oracle Business Data Synchronization Server 11g Release 1 (11.1.1.6.0) Part Number E12319-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Business Data Synchronization Server 11g Release 1 (11.1.1.6.0) Part Number E12319-02 |
|
|
PDF · Mobi · ePub |
This chapter provides a high-level description of the Oracle Business Data Synchronization Server (BDSS) architecture
This chapter includes the following topics:
Oracle Business Data Synchronization Server (BDSS) utilizes a hub-and-spoke architecture that enables synchronization between PIM servers. The hub provides the core synchronization functions and is PIM-server agnostic, enabling connections for any type of PIM server. Connectors, which send data to and retrieve data from the PIM servers, comprise the spokes of the system. Figure 2-1 illustrates an example of this architecture, one that results in fewer connectors between PIM servers. Even in multiserver topologies, this simpler synchronization topology addresses the potential issue of data feedback looping between the PIM servers.
Note:
For Oracle Fusion Middleware 11g release 1, BDSS ships with support for Microsoft Exchange.BDSS consists of the following two main components:
The Hub, which orchestrates the synchronization of data for the system, includes the following subsystems (illustrated in Figure 2-2):
Dispatcher
The Dispatcher first reads the set of users that it must send to the Engine and verifies that users on the list are available for synchronization. After it is called, the Dispatcher process divides the entire set of users for synchronization into batches and calls the Engine component. This subdivision of the user list allows for improved scalability of the system, as several Engine components can be made available. Dispatcher calls can be balanced across the available Engine components as well.
Note:
The Dispatcher does not send users to the Engine when those users are currently undergoing synchronization.Scheduler
An external scheduler runs the Dispatcher at set time intervals. BDSS does not ship with a scheduler. You can use any scheduling service, such as the Windows scheduler service or the Oracle Enterprise Manager scheduler.
Note:
Although Oracle suggests a default interval of 5 minutes, you can select a scheduling interval that provides performance and scalability to suit the environment.Engine
The Engine receives the list of users from the Dispatcher and synchronizes each of these users at the same time. The Engine contacts each of the connectors to receive from the PIM servers a set of records that have changed for the user. The extraction sets are combined to form a complete set of changes to be pushed back to the PIM servers.
Note:
The Engine only notifies a PIM server about records that have changed on other PIM servers. It does not inform the PIM server of changes identified from its own extraction set.A conflict can arise if both PIM servers change a record during the same synchronization cycle. The Engine determines which changes to keep and which to discard based on the relative priority of each connector domain involved. (You can configure the priority assigned to each connector domain.) After the Engine determines which records comprise the result set, it pushes them to the PIM servers and then tracks the user's success.
The Hub itself does not read the data that it receives from the connectors. Instead, it reads the ID tag for each record and builds a record map that correlates the records of the different PIM servers. The Hub passes the data to the connectors.
The Engine also includes the Run-Time Configuration Manager, which stores and retrieves the data required for synchronizing users. This data includes component configuration settings, user information, mappings, user record information, and information about PIM server instances.
Connectors standardize communication between the Hub and the PIM server that they service. Connectors update the data for connector domains, such as a contact or a task. During a synchronization session, the connectors retrieve changed data for a user from their respective PIM servers and transform it into the Hub format. They then pass the transformed data to the Hub. The connectors also transform the data from the Hub into the format appropriate to the PIM server. The connectors use Web services to both retrieve user records and return them to the Engine. For more information, see Section 2.2, "Overview of Connectors."
For Oracle Fusion Middleware 11g release 2, BDSS ships with Oracle BDSS Connector for Microsoft Exchange 2007 (the Exchange 2007 Connector). The Exchange 2007 Connector uses the Exchange 2007 Exchange Web Service (EWS) when it interacts with a user's Microsoft Exchange mailbox. The Exchange 2007 Connector supports synchronization of Calendar and Task data.
Note:
Using the BDSS Connector API, you can create connectors that synchronize any domain, such as service requests or opportunities. For more information, see Appendix C, "Connector API."BDSS works on a set of users that are configured through MBeans (managed beans) by mapping a user login from each of the end systems to a central representation of the user called a Hub user. The Dispatcher can be triggered either by the schedule, or when a connector sends an event notification to the Hub when a user has changed a record. Scheduler-based synchronization synchronizes all users at each interval, even if some users have no changes. Event-based synchronization is more efficient, as users only synchronize when there is data to be synchronized.
You can set the following synchronization options for each user on each connector domain. For example, if synchronization is enabled for task items for a user, then BDSS automatically synchronizes the task for that user.
Inbound
The inbound direction limits the exchange of data for an entity (such as a domain, user, or a connector) to only pushing records and record updates to the PIM server. Changes to the records on the PIM server are not propagated to other systems.
Outbound
Outbound direction enables the connector to extract Create, Update, and Delete record event data from the PIM server. The outbound direction limits the synchronization for an entity by only allowing changes to be collected from a PIM server. No records or changes are pushed to a PIM server.
None
No synchronization of data occurs.
Full
Full synchronization enables bidirectional (that is, both inbound and outbound) synchronization.
You can configure the synchronization direction for any connector, domain, and user. For more information, see Section 4.1.2, "Specifying the Synchronization Direction."
A typical flow demonstrating a synchronization session between a BPEL server and the Microsoft Exchange server is as follows:
The Scheduler triggers the Dispatcher.
The Dispatcher searches for Hub users who are available for synchronization, meaning those users who, despite having been enabled for synchronization, are not currently synchronizing.
The Dispatcher chunks these users into batches.
The Dispatcher sends the batches to the Engine.
The Engine starts a synchronization session for each user.
The synchronization session performs the following operations:
Determines the appropriate PIM servers for the user.
Determines the domains (such as Tasks or Contacts) for the user.
Sends an extract message to the connector instance for each connector. This extract message lists the user domains for which record changes are requested.
The connectors return the extract response to the Engine. Each extract response contains information describing new, updated, and deleted records for a particular connector domain.
The Engine merges the extract response records, resolving conflicts as needed.
The Engine sends the appropriate record changes to each PIM server.
The user's synchronization process terminates.
The Engine tracks the user's domain records that have been exported successfully from a PIM server using connector-provided data known as the synchronization state. Synchronization state is monitored at the connector domain level. For more information about synchronization state, see Appendix C, "Connector API."
Event-based synchronization reduces the amount of processing required of the Hub. It also reduces network and database usage by eliminating unneeded user synchronization sessions. Using event-based synchronization, the Hub synchronizes users only when record changes occur. If there are no changes for a user, then the Hub does not synchronize the user.
User changes that affect the domains do not trigger synchronization sessions; as in standard synchronization (described in Section 2.1.2), the scheduler dictates the frequency of the synchronization sessions. The event-based synchronization process is initiated when a PIM server notifies its connector that a user's records have changed. The connector then notifies the Hub and sets an event flag that identifies the user as having changed records on the PIM server. When the Scheduler triggers a new synchronization cycle, the Dispatcher batches this user to the Engine to undergo synchronization.
BDSS works with connectors and PIM servers that can flag users for event-based synchronization and with PIM servers that cannot flag users for event-based synchronization. In systems where all of the connectors and PIM servers can flag users for event-based synchronization, the Dispatcher batches users with change flags. When synchronization is started for theses users, the Hub synchronizes them as it would in a scheduled synchronization session (that is, the Hub requests changes from the connector, since changes may have occurred to a user's PIM data after the Hub received the connector's initial notification). The Engine does not process users or send an extract message to the connector during the synchronization cycle. During these synchronization sessions, the synchronization direction is Inbound Only for the unflagged user. In systems having connectors that cannot flag events, the Hub synchronizes all of the users that belong to these connectors for event-based synchronization.
If a BDSS connector cannot support sending event notifications, then the Hub cannot support the event-based method to initiate user synchronization sessions. For example, if changes were made in a system where a connector was unable to detect changes, the Hub could not synchronize the records for a user unless a change to a record was made in a system that has a connector that supports event notification for that same user.
Each time BDSS starts (or restarts), it sets change flags for users who synchronize on all of the domains that are set for either Full or Inbound synchronization. These flags enable connectors to create subscriptions for the user. A connector creates separate subscriptions for each domain if it can to do so.
Note:
You enable event-based synchronization by setting the
SYNC_EVENTS_ENABLED_FLG, SUPPORTS_EVENTS_FLG, and USER_EVENT_FLG flags in the CONNECTORS table.The Event-Based Synchronization Flow
The Dispatcher retrieves Hub users who are available for synchronization.
The Dispatcher chunks these users into batches.
The Dispatcher sends these users to the Engine.
The Engine starts a synchronization session for each user. The synchronization session performs the following:
Determines the appropriate PIM servers for user.
Determines if there are changes made to the user's domains (such as Tasks or Contacts).
Sends an extract message to the connector instance for each connector. This extract message lists the user domains for which record changes are requested.
The connectors return the extract response to the Engine.
The Engine processes the extract responses and then pushes data to the connectors.
The user's synchronization process terminates. The Hub resets the change flag for the connector user. If the connector does not support events, then the Hub leaves the change flags in the state that causes synchronization.
The connectors use Web services to communicate user records to the Hub. They implement the BDSS Connector API as described in Appendix C, "Connector API," which details the BDSS Connector Interface, Connector Run-Time Interface, and Engine Callback Interface. A connector consists of the following three components:
Note:
Although you do not have to implement these three components, Oracle recommends their implementation as a best practice.The Hub Transport implements the connector interface and performs data exchange between the Engine and the connector.
The Transformer translates data into both the Hub schema and the schema of the PIM servers. You can define how the Hub formats the data and freely revise it to meet customer needs. Using Oracle JDeveloper you can create the XSLTs (XML Transformations) that map the XSDs (XML Schema Definitions) of the Hub and PIM server. See also Chapter 8, "Mapping Connector Fields to Hub Fields."
Note:
You can create and revise the Hub schema, but you cannot change the connector schema. The connector schema is created by the developers of the connector and must remain fixed.The PIM Transport uses the PIM API interfaces and performs data exchange between the connector and the PIM server. As part of the data exchange, the PIM Transport translates data between the PIM XML schema representation and the PIM server representation.
Synchronization between the Hub and connectors is bidirectional by default, but can be configured to restrict the synchronization direction to either inbound-only or outbound-only.
The components interact as follows upon receiving data from the PIM server:
The PIM Transport collects a record set for a domain using a native PIM server API. This data is in the format specific to the PIM Server.
The PIM Transport converts each record to a PIM XML format that conforms to the PIM XSD defined for the domain to which the record belongs.
The PIM Transport passes each PIM XML record to the Transformer, which performs the following actions to translate the PIM XML record into the Hub XML record:
Determines the synchronization direction (inbound) to apply the correct XLST document (PIM to Hub). See also Section 5.4, "Creating Connector Configuration Profiles."
Invokes an API that applies the XSLT document to each record. This XLST contains the schema definitions for both the Hub and the PIM server.
Returns the Hub XML record to the Hub Transport.
The Hub Transport calls an API to build a SOAP (Simple Object Access Protocol) message containing the Hub XML record set.
The Hub Transport then calls an API to push the SOAP message to the Hub.
Outbound synchronization begins with the Hub sending a SOAP message containing a single record in Hub XML format to the connector. The connector then transforms this XML record to an appropriate format required by the target PIM server.
The components interact as follows upon receiving data from the PIM server:
The Hub Transport receives the SOAP message containing the Hub XML record.
The Hub Transport then passes the Hub XML set to the Transformer.
The Transformer performs the following actions to translate the record from Hub XML to the appropriate PIM XML:
Identifies the synchronization direction (outbound) to apply the appropriate XSLT to the Hub XML record (Hub to PIM).
Calls an API to apply the XSLT.
Passes the converted record to the Hub Transport.
The Hub Transport passes the PIM XML record to the PIM Transport.
The PIM Transport converts the PIM XML into a format needed by the native PIM API used to push the record to the PIM server.
The PIM Transport sends the PIM API-formatted record to the PIM server.
Errors can be integrated into a BPEL task flow to alert about administrators data errors that occur during synchronization. For example, if a user inadvertently creates a record with a character in the description that a third-party PIM Server cannot accept, then that PIM Server rejects the record during the next synchronization session. As a result, BDSS raises a BPEL event with the record summary and the error. The administrator sets up a BPEL process that checks the error code and then sends an e-mail telling the user to remove the unsupported character from the record.
An event is raised whenever BDSS logs a Critical, Error, or Warning message to its log files. BDSS can also raise a BPEL event to a BPEL server or web service.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|