Siebel Synchronous and Asynchronous Server Requests

Requests are tasks processed by the batch components. SRBroker and SRProc components are responsible for routing the requests from the requestor to the target component.

SRBroker (Server Request Broker)

SRBroker routes requests to target components based on the information in the request. At least one instance of SRBroker component should be running on each Siebel server. SRBroker caches information from the Gateway name server and knows which component is running in which Siebel server. It also caches information from the shared memory and knows which component is running in the local Siebel server. Each instance of SRBroker communicates with other SRBroker components running on the same Siebel server or other different Siebel servers to route requests in the same Enterprise. 

For more details regarding SRBroker, click here

SRProc (Server Request Processor)

SRProc processes server requests that are stored in the Siebel database. SRProc has connection information to the Siebel database and it stores and retrieves information from the S_SRM_REQUEST table. SRProc communicates with only the SRBroker component running on the same Siebel server. Every SRBroker will connect to SRProc in the same Siebel server to send requests for storing them in the database. SRProc will connect to one of the SRBroker components in the same Siebel server to forward requests for processing. Successfully completed requests are removed from the S_SRM_REQUEST table by the component "Server Tables Cleanup" (SvrTblCleanup).

For more information regarding SRProc, click here

There are 2 different types of server requests:

1. Synchronous: The requests are send to the target component and the requestor waits for a response.
2. Asynchronous: The requests are send to the target component and the requestor does not wait for a response. The requestor also does not trigger any callback after it gets a response. We can also schedule a start time while submitting requests.

Server Requests - Routing logic

If the target component is running on the same Siebel server as the requestor, SRBroker will always route the request to the instance of the component running on the  same Siebel server. SRBroker will never route requests to other Siebel servers, if the component is running in the local Siebel server.

If the target component is not running on the same Siebel server, then SRBroker routes the request to other Siebel server where the component is running. If the target component is running on multiple Siebel servers, then it uses Round Robin fashion to route subsequent requests among the Siebel servers.

Routing logic - Same Siebel server

• Synchronous Request: SRBroker will route the request to the target component if it has already established a Siebel Internet Session API (SISNAPI) connection. If there is no connection, SRBroker will establish one upon getting the first request for the component. Once the component finishes processing the request, it sends the response to SRBroker. SRBroker then sends back the response to the requestor.
• Asynchronous Request (DirectDb Mode): Any requests from the requestor will be written to the S_SRM_REQUEST table first. Any SRProc component can pickup the request as long as the target component is running on the same Siebel server.
• Asynchronous Request (Asynch Mode): If the target component is running on the same Siebel server, then routing is same as synchronous mode without any response.
• Scheduled Asynchronous Request: SRBroker on the local server of the requestor will send the request to SRProc, which first writes the request to the S_SRM_REQUEST table. When the scheduled start time is current, any SRProc from any Siebel server can pickup the request from the database and send it to the SRBroker on the same Siebel server, which in turn routes it to the target component.After the component finishes processing the request, it sends response to SRBroker. SRBroker sends the response to SRProc. SRProc will update the record for the request in the database with the response.

Routing logic - Multiple Siebel servers

• Synchronous Request: If the target component is not available on the local Siebel server as the requestor, then the SRBroker in the local Siebel server will send the request to another SRBroker on the first Siebel server where the component is enabled and online. If the request's target component is running on that Siebel server, SRBroker on that server will route the request to the component. Once the SRBroker receives response from the component it will send the response back to the original SRBroker, which in turn sends the response back to the requestor. If the target component is not running on the first Siebel server, the SRBroker on the local Siebel server will try the next Siebel server that has the target component running. If the component is unavailable in any of the servers, then the request fails.
• Asynchronous Request (DirectDb Mode): Any requests from the requestor will be written to the S_SRM_REQUEST table first. Any SRProc component can pickup the request as long as the target component is running on the same Siebel server.
• Asynchronous Request (Asynch Mode): If the target component is running on the same Siebel server, then routing is same as synchronous mode without any response.
• Scheduled Asynchronous Request: SRBroker on the local server of the requestor will send the request to SRProc, which first writes the request to the S_SRM_REQUEST table. When the scheduled start time is current, any SRProc from any Siebel server can pickup the request from the database and send it to the SRBroker on the same Siebel server, which in turn routes it to the target component.After the component finishes processing the request, it sends response to SRBroker. SRBroker sends the response to SRProc. SRProc will update the record for the request in the database with the response.

Load balancing

1. If there are more than one instance of the target component are running on the local Siebel server as the requestor, SRBroker will use Round Robin logic to route the requests among the components.
2. If and only if the target component is not available on the local Siebel server as the requestor, SRBroker on the local Siebel server will send the request to other SRBroker on other Siebel servers on a Round Robin fashion.