5 Configuring the BDSS Hub Services

This chapter describes the basic configuration for the Hub and connectors.

This chapter includes the following topics:

5.1 Overview of Hub Configuration

Configuration for the Hub and Dispatcher components is exposed as the attributes and operations of MBeans. You can configure these MBeans using the Oracle Enterprise Manager's System MBean Browser or through any JMX console (such as JConsole) that is supported by a J2EE-compliant server. For more information, see Section 4.1.1, "Managing BDSS Components Using MBeans."

5.2 Configuring the Dispatcher

The attributes for the Hub and Dispatcher are exposed through the DispatcherSettings MBean. Table 5-1 lists these attributes.

Table 5-1 Attributes of the DispatcherSettings MBean

Attribute Description

ChunkSize

The number of users contained in the message sent to the Hub for synchronization. Use this attribute to balance the load to each instance of a running Engine. The default value is 20 users per message

HubEndPointURL

The URL used by the Dispatcher to connect to the DispatcherHub web service on the server hosting the Hub. For example, a typical Hub URL for Oracle WebLogic Server is http://<HUB_SERVER_IP_ADDRESS>:7001/BDSSHubWebServices/DispatcherHubWebService?WSDL


5.3 Configuring the Engine

The attributes of the Engine are exposed through the EngineSettings MBean. Table 5-2 lists these attributes.

Table 5-2 Attributes of the EngineSettings MBean

Attribute Description

EngineEndPointURL

The URL used by the Engine to enable the connectors to extract requests and data update request responses to the Engine.

To find this URL using the Oracle WebLogic Server Administration Console:

  1. Select Deployments.

  2. Expand the tree structure of BDSSHub.

  3. Select the EngineCallBackInterface node. The Settings for EngineCallback page appears.

  4. Select the Testing tab.

  5. Expand the EngineCallbackInterface node.

  6. Select the ?WSDL test point.

ExtractResponseTimeOut

The number of milliseconds that the Engine waits to process an extract response from a connector. The default value is 60000 milliseconds. The timeout value must be sufficiently large to prevent a timeout from occurring under normal circumstances. This value depends on several factors that include:

  • The size of the largest record set that can be extracted.

  • The number of Hub domains that are to be extracted. This has bearing because Hub domains are processed serially by the Engine for a synchronization session. Therefore, Hub domain B must wait longer to retrieve its extract responses if Hub domain A were processed first.

  • Other factors, including system load and communication latency, that affect the ability of a Engine to retrieve and process extract response messages from connectors before the timeout occurs.

If a timeout occurs, then synchronization of the corresponding Hub domain is terminated for the affected user synchronization session.

MessageTimeToLive

The number of milliseconds that a message containing an extract response remains on the JMS queue before being removed. The default value is 60000 milliseconds. Calculate this timeout value using an analysis similar to the one performed for the ExtractResponseTimeOut attribute.

RuntimeLibraryURL

The URL that the Engine sends to the connectors to enable them to communicate with the Connector Runtime Library.

To find this URL using Oracle WebLogic Server Administration Console:

  1. Select Deployments.

  2. Expand the tree structure of BDSSHub.

  3. Select the ConnectorRuntimeInterface node. The Settings for ConnectorRuntimeInterface page appears.

  4. Select the Testing tab.

  5. Expand the ConnectorRuntimeInterface node.

  6. Select the ?WSDL test point.


5.4 Creating Connector Configuration Profiles

Using the setProfileParameter operation described in Section 4.8.2, "Managing Profile Parameters," you can create or update the parameters for configuration profiles.

5.5 Configuring the FtsKeyFields Profile

The FTSKeyFields is a Hub profile used by all connectors. BDSS uses key fields when it first synchronizes a record to determine if a record from one PIM server is the same as a record from another PIM server. If the values in all key fields of a record match, then BDSS assumes that the record is the same. If any key field does not match, then BDSS assumes that the record is a unique record.

Note:

BDSS does not continue using key fields to identify a record after it has made a match. From that point, BDSS uses record IDs.

Table 5-3 lists the parameters grouped into the FtsKeyFields profile.

Table 5-3 Parameters of the FtsKeyFields Profile

Parameter Description

KeyField1

The first field used for record matching

KeyField2

The second field used for record matching