Siebel Universal Queuing Administration Guide > Overview of Siebel Universal Queuing > Universal Queuing Architecture >

Overall Architecture

Siebel Universal Queuing includes the following components:

• The Siebel Universal Queuing routing engine, which is installed separately from Siebel Server and runs either on the same machine as Siebel Server or on a separate machine. For performance reasons, it is recommended that you install the Siebel Universal Queuing routing engine on a separate machine by itself.
• Siebel Universal Queuing business service methods, which handle communications with Siebel Communications Server and other Siebel modules.
• The Siebel Universal Queuing application programming interface (API), which provides the mechanism for routing engine functionality to interface with Siebel eBusiness Applications. The Siebel Universal Queuing API is application-independent, allowing customers to integrate a third-party routing engine with Siebel eBusiness Applications, if desired, and to configure channels, route, and other elements in the manner described in this book.

  You can request additional information about the Siebel Universal Queuing API from Siebel SupportWeb (http://ebusiness.siebel.com/supportweb/).

• The UQ Administration screen included with Siebel eBusiness Applications, which allows administrators to configure and administer the routing engine.

Siebel Universal Queuing works with a number of Siebel modules or products, such as Siebel Communications Server, Siebel CTI, and Siebel eMail Response. These modules work together to make the routing process work.

The communication protocol between Siebel Server and the Siebel Universal Queuing routing engine is HTTP. Because the communication protocol is HTTP, the routing engine may be run on a separate platform from Siebel Server.

Communications with the Siebel Universal Queuing routing engine are through the Siebel Universal Queuing API. The API will package the internal Siebel Universal Queuing request data into Simple Object Access Protocol (SOAP) format with embedded XML. The data is embedded into the body of an HTTP packet and the packet is sent directly to the routing engine through HTTP.

Each Siebel Universal Queuing client, such as Siebel Communications Server establishes a connection to the routing engine through the Universal Queuing API. Voice calls and email requests are sent through the Communications Inbound Manager.

When requests are sent through the Universal Queuing API, the request data will be converted into XML. Siebel Universal Queuing business service will add a SOAP envelope on top of the XML. Once the XML document is ready, it is sent to the Siebel Universal Queuing routing engine using the client's established connection.

Upon receiving the request, the Siebel Universal Queuing routing engine always responds synchronously about whether the request has been processed or not. Depending upon the request, the routing engine will also send back an asynchronous response to the Siebel Web server. The Siebel Web server will route this request to the Siebel EAI Object Manager. The EAI Object Manager then invokes the Siebel Universal Queuing business service, based upon the EAI external services configuration. When EAI Object Manager receives the request in HTTP format, it extracts the data from the body and converts it to a Siebel internal format.

The Siebel Universal Queuing routing engine sends requests back to Siebel Server using a number of established connections to Siebel Web server. The information about how to establish a connection to the Web server is provided to the routing engine during the initial OpenConnection request. In this request, Siebel Server tells the Siebel Universal Queuing routing engine the URL that needs to be sent to the Siebel Web server in order to establish the connection.

Because each connection to EAI Object Manager through the Web server is only served by one thread, it is important to establish the optimum number of connections so that maximum performance is achieved. The number of connections is set using the MaxConnections parameter when defining the Siebel Universal Queuing configuration. For more information about this parameter, see Table 7.

Figure 1 illustrates the general architecture of a communications system using Siebel Universal Queuing. Refer to Siebel Communications Server Administration Guide for more information on the Siebel Communications Server architecture.

Figure 1. Siebel Universal Queuing Architecture

The Siebel Universal Queuing routing engine comprises the following major components:

• UQ Connector. Provides the gateway between Siebel Server and the Siebel Universal Queuing routing engine, using the HTTP protocol.
• SOAP interface adapter. Bridges the gap between the UQ Connector and the SOAP interface, and manages the details of the SOAP protocol.
• ADU Server. Stores agent state, including the channel state for each channel type for which the agent can receive work items. The Agent Data Unit (ADU) is created for each agent upon login and remains until the agent logs out.
• Contact Record Server. Stores work item state from the time a work item is first introduced into the Siebel Universal Queuing routing engine until the last agent completes work on the work item. Support services are called as needed. For example, the Data Unit (DU) Store Server provides a persistent copy in the database (DUStore table) of items stored in the ADU and Contact Record servers; the Directory server supplies configuration information to the servers.
• ATD Server. Contains the logic for managing work item state, agent state, and work item routing based on work item data properties and agent skills. To match a work item and an agent, the Automatic Task Distributor (ATD) Server performs these basic operations:
  • Assigns an available agent to a new work item when it arrives, and queues the work item if no agent is available.
  • Finds a work item for an available agent, and leaves the agent available if no work item is found.
  • Looks for work items that expire in each escalation step and moves them to the next escalation step. Then tries to assign an available agent, queuing the work item if no agent is available.