SCBroker, SRBroker and SRProc

SCBroker or Siebel Connection Broker:

The main purpose of this component is to listen to port 2321 for user requests (Users log in to the application)on the servers hosting the Object Manager Component and forward it to Object Manager. 

SCBroker accepts the incoming user requests and after accepting the user requests assigns it to the Process from the Object Manager that has the least Load. 

How does it do this?

It reads the shm file on the server. The shm file has a section for the processes running on the server which tells the SCBroker about the load on different Processes for the Object Manager running on the server.

Thus SCBroker does load balancing amongst Object Manager Processes in siebel There is normally only one task running for SCBroker on a server. There can be multiple instances of SCBroker on the same server however each will listen to the same port 2321.

SRBroker or Server Request Broker:

SRBroker does the same work as of a broker in a real world. It is used for inter-server and intra-server communication. Let’s see this with an example.

Let’s say we have File System Manager (FSM) Component running on an server along with Object Manager. Now suppose the Object Manager needs to access some attachment from the file system. 

How will the Object Manager do this? The Object Manager will give a call to the FSM But through SRBroker this is the case of inter server communication. Let’s say after sometime the Object Manager needs to access another attachment from the file system but this time the FSM component is down on the server for some reason. Under this scenario as the request from the Object Manager to the File System Manager is going through SRBroker

SRBroker will sense that File system Manager on the local server is not running and will forward the request to the next server for FSM component on that server to get the request processed through SRBroker on that server

this is the case of intra server communication. SRBroker maintains a consistent connection with all the components on the local server plus with all the SRBroker components in the enterprise.The number of tasks for SRBroker is generally kept as the sum of the count of components on the local server and the number of servers in the enterprise Plus 20.

SRProc or Server Request Processor:

SRProc is responsible for processing asynchronous requests. It picks the requests from S_SRM_REQUEST Table for the components that are hosted on the server on which particular SRProc is running.  

SRProc works in conjunction with SRBroker meaning that once SRProc picks up the requests from S_SRM_REQUEST Table for the components on that server it will pass on the requests to the destined components through SRBroker.

The number of running tasks for SRProc on the server should be 3 while in actual it is 4. There is one hidden task. One SRProc maintains consistent connection with the SRBroker on the server. So if the SRBroker is down on the server for some reason and you try to bring up SRProc it will not start you first need to start SRBroker.