Siebel Field Service Guide > Setting Up and Using Scheduling >

About the Relationship of Scheduler to the Server Request Broker

When a request is made to Scheduler (through the user interface or the application program interface [API]), the call is routed to the correct server by the Server Request Broker (SRB) in the following way:

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 Siebel Server's shared memory file. SRB uses the information stored in shared memory to determine which components are up and 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 Object Manager contacts the SRB on the Object Manager machine. That SRB sends the BookAppt request to the SRB on the ABS server. After the first request is submitted to the particular region, the SRB on that server establishes a connection to the local ABS.
3. The response is sent from Scheduler to the SRB on the service region machine. The SRB then sends the response to the SRB on the Object Manager machine. Then, the SRB on the Object Manager machine relays that response to the Object Manager.
4. Subsequent connections from any Object Manager are made by each local SRB connecting to the SRB on the service region's machine. Responses are similarly passed back through the two SRBs. The Object Manager connects to the Server Request Broker only; if there is a connection between the SRB and the ABS on the local machine, then it does not open another connection to the ABS.
5. Assignment Manager, if used, is contacted by the ABS using the SRB mechanism. Having multiple rule sets does not affect the routing. Assignment Manager has a default rule set that is always used whenever no rule set is defined.

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

For example, assume you have three servers in the enterprise. The Object Manager and an SRB are running on Machine 1. Machines 2 and 3 have SRBs and four processes of ABS running on them 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 should look like the following:

• All SRBs on all machines should have the server key maps for all 16 service regions within their cache.
• Machine 2's SRB has eight open threads to the four ABS processes (two each). Each ABS service region is listening on a unique port for calls from the Machine 2 SRB. Because there is unique port per service region in the ABS process, there is one connection (thread) from the Machine 2 SRB to that port on ABS.
• Machine 3 should appear the same as Machine 2.
• Machine 1 only has connections to the SRBs on Machines 2 and 3. The SRB on Machine 1 does not connect directly to the ABS on other machines, as that would defeat the purpose of brokering.

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