Siebel Field Service Guide > Scheduling Using Siebel Scheduler >

About Siebel Scheduler and the Server Request Broker

When a request is made to Siebel Scheduler (through the user interface or the application programming interface), the Server Request Broker (SRB) routes the call to the correct server in the following manner:

1. When the ABS server is started, it loads all the activities into the cache. It registers all the unique service region keys in the shared memory file of the Siebel Server. The SRB uses the information stored in shared memory to determine the components that are running. No SRB threads are established at that time.
2. At the first attempt to connect to a service region (for example, a Book Appt request from a client), the Siebel Application Object Manager contacts the SRB on the Siebel Application Object Manager computer. That SRB sends the BookAppt request to the SRB on the ABS server. After the first request is submitted to the region, the SRB on that server establishes a connection to the local ABS.
3. The response is sent from Siebel Scheduler to the SRB on the service region computer. The SRB then sends the response to the SRB on the Siebel Application Object Manager computer. Then, the SRB on the Siebel Application Object Manager computer relays that response to the Siebel Application Object Manager.
4. Each local SRB connecting to the SRB on the service region computer makes subsequent connections from any Siebel Application Object Manager. Responses are similarly passed back through the 2 SRBs. The Siebel Application Object Manager connects only to the Server Request Broker. If there is a connection between the SRB and the ABS on the local computer, then it does not open another connection to the ABS.
5. The ABS contacts Assignment Manager, if used, by using the SRB mechanism. Having multiple rule sets does not affect the routing. Assignment Manager has a default rule set that applies when no rule set is defined.

The only persistent SRB threads are on the computer containing the SRB and the service regions on that computer.

For example, 3 servers exist in an enterprise. The Siebel Application Object Manager and an SRB run on Computer 1. Computers 2 and 3 have SRBs and 4 processes of ABS that run with 16 separate service regions (two for each ABS process). The user connects and books an appointment on each of the service regions. At this point, the environment looks as follows:

• The caches for all SRBs on all computers include the server key maps for all 16 service regions.
• The Computer 2 SRB has 8 open threads to the 4 ABS processes (two each). Each ABS service region listens on a unique port for calls from the Computer 2 SRB. Because there is a unique port for each service region in the ABS process, there is 1 connection (thread) from the Computer 2 SRB to that port on the ABS.
• Computer 3 appears the same as Computer 2.
• Computer 1 has connections only to the SRBs on Computers 2 and 3. The SRB on Computer 1 does not connect directly to the ABS on other computers because that defeats the broker purpose.

When Siebel Scheduler shuts down, the keys are deregistered in shared memory and the connection between the SRB and Siebel Scheduler is lost. If there are any Sync requests for Siebel Scheduler, then it fails and the user sees an error. If the request is an Async request stored in the Siebel database, then it remains in queued state until Siebel Scheduler is brought back up and the Service Request Processor (SRP) or the SRB then routes the request accordingly.