The Three main pillars of Siebel Architecutre

e 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.

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.

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.

Advertisements

Configuration of Native Load Balancing and SCBroker in Siebel 8.1.x

Client configuration

The client configuration file, such as eapps.cfg, must be changed depending on the type of load balancer being used.

In the release version, the installer and config wizard will prompt the user for the necessary parameters and add them to eapps.cfg.  If the config wizard is not used, these parameters must be made manually.

There are three mutually exclusive options for load balancing that may be configured on the client.  The options are no load balancing, native load balancing, and third party load balancing.

No load balancer

If using only one server, it may be less work to configure the SWSE client to use no load balancer.  The only thing that may need to be modified is the connect strings in eapps.cfg so that the SCBroker listening port is referenced.

The format of the connect string is as follows:

ConnectString = siebel://<hostname>:<SCBroker port>/<enterprise> /<component>

SCBroker port, which defaults to 2321, can be verified by running the following srvrmgr command:

srvrmgr> list param portnumber for comp scbroker show PA_VALUE

Example change for eapps.cfg

[/sales_enu]

ConnectString = siebel://HOSTNAMENAME:2321/siebel/SSEObjMgr_enu

Native load balancer

To use the native round robin load balancing provided by the Siebel session manager, there are 3 changes that must be made.

1. Modify [ConnMgmt] section of eapps.cfg

Create a new section in eapps.cfg called [ConnMgmt].  To enable round robin load balancing, the variables listed in the following table must be set.

[ConnMgmt] variables for round robin load balancing

Variable name Acceptable values Description
EnableVirtualHosts true or false EnableVirtualHosts is used to enable internal load balancing.  A value of true means that the Client has enabled Session Manager based load balancing.
VirtualHostsFile path to LB config VirtualHostsFile contains the Session manager load balancing configuration file.  This file describes virtual server to host mapping

Example change for eapps.cfg

[ConnMgmt]

EnableVirtualHosts=true

VirtualHostsFile=m:\siebel\admin\lbconfig.txt

2.  Create virtual hosts file

The load balancer parses a file containing a mapping of virtual servers to hosts.

Each line of VirtualHostsFile must be in the following format:

vservername=<sid1>:<hostname1>:<SCBroker port>;…;

<sidn>:<hostnamen>:<SCBroker port>;

 

Details on creating the virtual hosts file

  • The first value of each host declaration (server ID) can be determined by running the following srvrmgr command:srvrmgr> list server show SBLSRVR_NAME, SV_SRVRID
  • The third value of each host declaration (SCBroker listening port) can be determined by running the following srvrmgr command:srvrmgr> list param portnumber for comp scbroker show PA_VALUE
  • Each virtual host declaration should be specified on one line.  Each line will be parsed as a separate virtual host.
  • A line starting with “#” is ignored.
  • If the file has syntax errors and is unable to be parsed, there will be a corresponding error in the client log file after the first connect attempt has been made, and users will not be able to connect to any components through the Web server.

Example load balancer config file (lbconfig.txt)

#

# Sample session manager load balancing file.

#

# Format: each line has the format of

# vservername=sid1:hostname1:port1;…;sidn:hostnamen:portn;

SalesVserver      =3:host1:2321;4:host2:2321;5:host3:2321;

CallCenterVserver =7:host4:2321;9:host5:2321;10:host6:2321;

3. Modify connect strings in eapps.cfg with virtual hosts

The connect strings in eapps.cfg must be changed to refer to the virtual servers in VirtualHostsFile.

Example change of connect strings in eapp.cfg

[/sales_enu]

ConnectString = siebel://SalesVserver/siebel/SSEObjMgr_enu

[/callcenter_enu]

ConnectString = siebel://CallCenterVserver/siebel/SCCObjMgr_enu

Upon making these changes to eapp.cfg, the Web server should be restarted.

Third party load balancer

To use a third party load balancer, such as Resonate, first configure the scheduling rules in the third party load balancer, using the appropriate third party configuration tools.  Next, modify the connect strings eapps.cfg to reference the virtual IP and virtual port.

For example, if using the Sales application with virtual IP 172.20.74.100 and virtual port 2512, modify eapps.cfg to contain the following:

Example change for eapps.cfg

[/sales_enu]

ConnectString = siebel://172.20.74.100:2512/siebel/SSEObjMgr_enu

After these changes, browser clients can simply connect to
http://<web server hostname>/sales_enu and the load balancer will route the request to an available OM.

Third party load balancer server configuration

When using a third party load balancer, 3 types of rules must be configured for each component:

Rule type Rule format Use of the rule
Connect */<enterprise>/<component> Initial connect from the client (SWSE) to the Siebel server
Reconnect */<enterprise>/<component>/!<server ID>.* Reconnect to the server where the session was initially established, in case of disconnect or errors.
Round robin */<enterprise>/<component>/RR To enable the client to choose another OM process to connect to in case the initial connect fails.

The same virtual port should be used for each rule, and the physical port for each rule is the listening port of the SCBroker component.

The procedure for configuring the rules in the third party load balancer is as follows:

  1. Use srvrmgr to connect to the server.  Run the following command to determine the SCBroker listening port:srvrmgr> list param portnumber for comp scbroker show PA_VALUE

    PA_VALUE
    ——–
    2321

    In this case, the port is 2321.  This will be the physical port used for the rules.

  1. Use srvrmgr to determine the server IDs of the servers for which scheduling rules will be registered.srvrmgr> list server show SBLSRVR_NAME, SV_SRVRID

    SBLSRVR_NAME  SV_SRVRID
    ————  ———
    srvr1         3
    srvr2         5

  1. Choose an unused port to use as the virtual port, such as 2512.
  1. Use the appropriate third party load balancer configuration tool to create the scheduling rules.  In the Resonate case, use CDAction or DispatchManager can be used.

Example configuration

Suppose the server is to be configured with CallCenter.  We already have determined the following using the steps above:

  • SCBroker is listing on port 2512
  • Srvr1 has server ID 3 and is running on physical host “host1
  • Srvr2 has server ID 5 and is running on physical host “host2

Suppose we also know:

  • The virtual IP for our load balancer is 172.0.0.1, and the virtual port is 2512

Then for the current example, the following rules would need to be registered:

Rule VIP VPort Host Port Description
*/siebel/sccobjmgr_enu 172.0.0.1 2512 host1 2321 Connect rule for srvr1
*/siebel/sccobjmgr_enu 172.0.0.1 2512 host2 2321 Connect rule for srvr2
*/siebel/sccobjmgr_enu/RR 172.0.0.1 2512 host1 2321 Round robin rule for srvr1
*/siebel/sccobjmgr_enu/RR 172.0.0.1 2512 host2 2321 Round robin rule for srvr1
*/siebel/sccobjmgr_enu/!3.* 172.0.0.1 2512 host1 2321 Reconnect rule for srvr1
*/siebel/sccobjmgr_enu/!5.* 172.0.0.1 2512 host2 2321 Reconnect rule for srvr2

Once these rules have been registered and the connect strings in eapps.cfg have been modified to use the VIP and VPort, the configuration is done.

Server parameters for SCBroker

In Siebel 7.7 there is a new system component called SCBroker, which will be started along with server.  If this component does not start, clients will not be able to connect to any OM processes.  The SCBroker has a number of associated parameters which can be configured.

Component parameters for SCBroker

Parameter name Description Default value
DfltTasks Default number of service tasks to start 2
MaxTasks Maximum number of running tasks for a service 2
PortNumber Static TCP/IP port number used by the service or the Siebel Connection Broker 2321
AutoRestart This component is restartable automatically True

New server parameters for SCBroker

Parameter name Description Default value
ConnectionTimeout Incoming connection timeout (msec) 500
TransferTimeout Connection Transfer timeout (msec) 500

New events

SCBroker events can be traced by setting the “SCBroker” event.  For example, in srvrmgr:

srvrmgr > change evtloglvl SCBroker=4 for comp scbroker