The Three main pillars of Siebel Architecutre

The Three main pillars of Siebel Architecutre

The following 3 components are the three main pillars in the siebel architecture:

1. SCBroker
2. SRBroker
3. SRProc

I will explain these 3 siebel components one by one as most people do not have a clear understanding of the same.

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. But does it all end here? Is it all that it does?

The answer is NO – It does one more work and that’s why I call it as an intelligent component. 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? Well the answer is – 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.

该组件的主要目的是为用户请求听端口2321(用户登录到应用程序)在服务器上托管对象管理器组件和转发对象管理器。但这一切都在这里结束吗?这是它做的所有事情吗?

答案是否定的,它还有另外一个工作,这就是为什么我叫它作为一个智能组件。SCBroker接受传入的用户请求,并接受用户请求后分配给进程的对象管理器加载。如何做到这一点呢?答案是——它在服务器上读取shm文件。shm文件有一部分关于在服务器上运行的进程的内容——告诉SCBroke关于运行在服务器上的不同的进程对对象管理器的负载情况。因此SCBroker在siebel中起到负载均衡siebel对象管理器进程的作用.


通常在一个siebel 服务器上只有一个运行SCBroker的任务。当然也可以有多个SCBroker的实例运行在同一台服务器上，但无论如何每个SCBroker实例都只会监听相同的端口-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 filesystem 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 Filesystem 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.

SRBroker做同样的工作,代理在一个真实的世界。用于内部服务器和外部服务器的通信。让我们来看看这一个例子。

假设我们有文件系统管理器(FSM)组件运行在一个服务器对象管理器。现在假设对象管理器需要从文件系统访问一些附件。对象管理器将如何做到这一点呢?对象管理器将通过SRBroker调用FSM而是——这是内部服务器通信的情况。

假设在某个时候对象管理器需要从文件系统访问另一个附件,但这次的FSM组件服务器出于某种原因不运行了。在这种情况下,作为从对象管理器到文件系统管理器的请求将通过SRBroker——SRBroker会意识到本地服务器上的文件系统管理器未运行,并将请求转发到下一个运行FSM组件的服务器进行处理——通过在该服务器上的SRBroker——这是外部服务器通信的情况。

SRBroker维护着与本地服务器上的所有组件一致的连接外加所有SRBroker组件的企业。

SRBroker任务的数量通常作为本地服务器运行组件的数加上在enterprise上运行的服务器的数量的总和再加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.

SRProc负责处理异步请求。它拿起请求从S_SRM_REQUEST表组件的服务器托管在特定SRProc正在运行。SRProc结合SRBroker工作意味着——一旦SRProc从S_SRM_REQUEST表中拿起该服务器上的组件的请求,它将把请求通过SRBroker传递到注定组件。

在服务器上运行任务的数量当实际是4个的时候SRProc应该是3个。有一个隐藏任务。在服务器上一个SRProc维护着与SRBroker一致的连接。所以如果SRBroker服务器由于某种原因不运行了,你想再试图启动SRProc就会启动失败,您首先需要启动SRBroker。