Do you know what SC Broker, SR Broker and SR proc server components do?
Well, very few people got a good idea about these. Let me tell you what I know.
Siebel Connection Broker is the component that connects the application from a Web Server. If I hit https://webserver/fins_enu/start.swe in IE, it sends a request to Web Server. Web Server sends the request to SWSE. SWSE identifies the fins_enu component and it sends the request to available app servers through Gateway. Web Server has a file call lbconfig.txt which is a native load balancer for siebel web server. It routes the request to available SC Broker component in any app server. SC Broker receives the request and checks the available app servers for fins_enu component. It forwards the connection request based on a parameter ConnForwardAlgorithm in a LL (Least Load) or RR (Round Robin) fashion. This establishes a connection and thats it. SC Broker's job is done.
Server Request Broker is the component that connects one component to another. In the above example, if on click of a button, I need to call a workflow process manager component, SR Broker comes into play. SR Broker also takes care of asynchronous requests (like Server Requests (Asynchronous) service calls from one component to another)
SRBroker decides where to run a server request using the following criteria:
1. If the required component is available locally i.e, on the same application server, then SRBroker runs the task locally.
2. If the required component is not available locally, then SRBroker identifies any Siebel Servers in the same Enterprise that have the component online. It uses RR algorithm to send requests.
3. If the required component is not available anywhere in the Enterprise, then the server request will fail.
Server Request Processor is another component that handles requests within the server. For example, a Workflow process Batch Manager job or a Workflow Policy, etc need to be executed even if the server does not receive any request from a user. They should be taken by server. SR Proc does this job. SR Proc will pick the requests and send the request to SR Broker. SR Broker will call respective component (like Workflow Monitor agent or Workflow Process Batch Manager). SR Proc communicates only to SR Broker.
All the jobs we run in Server Administration - Jobs view will be picked up by SR Proc.
Now from this we understand the following.
1. After connecting to the application, if we bring down all SC Brokers, application will run fine. It will not accept any new connections.
2. If SR Broker is not available in any of the app servers, you can not run any other component Job.
3. If you bring down SR Proc components, no server job will be run. All jobs will be in failed status.
I will give you more information on Server Architecture in future posts.
Well, very few people got a good idea about these. Let me tell you what I know.
Siebel Connection Broker is the component that connects the application from a Web Server. If I hit https://webserver/fins_enu/start.swe in IE, it sends a request to Web Server. Web Server sends the request to SWSE. SWSE identifies the fins_enu component and it sends the request to available app servers through Gateway. Web Server has a file call lbconfig.txt which is a native load balancer for siebel web server. It routes the request to available SC Broker component in any app server. SC Broker receives the request and checks the available app servers for fins_enu component. It forwards the connection request based on a parameter ConnForwardAlgorithm in a LL (Least Load) or RR (Round Robin) fashion. This establishes a connection and thats it. SC Broker's job is done.
Server Request Broker is the component that connects one component to another. In the above example, if on click of a button, I need to call a workflow process manager component, SR Broker comes into play. SR Broker also takes care of asynchronous requests (like Server Requests (Asynchronous) service calls from one component to another)
SRBroker decides where to run a server request using the following criteria:
1. If the required component is available locally i.e, on the same application server, then SRBroker runs the task locally.
2. If the required component is not available locally, then SRBroker identifies any Siebel Servers in the same Enterprise that have the component online. It uses RR algorithm to send requests.
3. If the required component is not available anywhere in the Enterprise, then the server request will fail.
Server Request Processor is another component that handles requests within the server. For example, a Workflow process Batch Manager job or a Workflow Policy, etc need to be executed even if the server does not receive any request from a user. They should be taken by server. SR Proc does this job. SR Proc will pick the requests and send the request to SR Broker. SR Broker will call respective component (like Workflow Monitor agent or Workflow Process Batch Manager). SR Proc communicates only to SR Broker.
All the jobs we run in Server Administration - Jobs view will be picked up by SR Proc.
Now from this we understand the following.
1. After connecting to the application, if we bring down all SC Brokers, application will run fine. It will not accept any new connections.
2. If SR Broker is not available in any of the app servers, you can not run any other component Job.
3. If you bring down SR Proc components, no server job will be run. All jobs will be in failed status.
I will give you more information on Server Architecture in future posts.
This is good information.. Thanks for sharing..
ReplyDeleteVery Good Information. Thanks
ReplyDeletegood one guy.
ReplyDeleteThank you for providing good information from Kexlin
ReplyDeleteYou are in the right place for a perfect solution for any app development company in hyderabad. We are well known for delivering the best quality Mobile Application Development Solutions to our clients.