Siebel Port

Default Port Allocations for Siebel Business Applications

Siebel Component	Port Number	Comments
Web Server	80 and 443	Port 80 is used for standard Web traffic. If Secure Sockets Layer (SSL) is implemented, then port 443 is used.
Gateway Server	2320	Load-balancing components use port 2320.
Siebel Server	2321	SCBroker listens on port 2321.
Siebel Server	49150 and higher (dynamic allocation of ports) 49149 and lower (static allocation of ports) 49152 to 49250 (dynamic ports listening on Siebel Servers)	Siebel Business Applications use dynamic allocation of ports for the server-based components. Static port allocation is also supported. The dynamic port allocation starts from port number 49150 onwards. If you choose to assign static ports to the components, then make sure that you choose ports below port number 49150.  Dynamic ports can go up to port number 65535. These ports have to be opened on Siebel Servers. The Siebel system administrator allocates a port to a specific Siebel component.
Synchronization Manager	40400	None.
Enterprise Application Integration (EAI) Server	Allocated by the system administrator.	Ports must be opened for the Siebel EAI and Workflow components. The Siebel system administrator allocates these ports.
SMTP Mail Server	25	None.
FTP Port	21	None.
Lightweight Directory Access Protocol (LDAP) Server	389 and 636	Port 389 is used for standard communications. Port 636 is used for secure communications.
Active Directory Server	389, 636, 3268, and 3269	Port 389 is used for standard communications. Port 636 is used for secure communications. Port 3268 is used for the Global Catalog and port 3269 is used for the Global Catalog with SSL.
Siebel Server or Siebel database	1433	Port 1433 is used for communications between the Siebel Server and Microsoft SQL Server database.
Siebel Server or Siebel database	5000	Port 5000 is used for communications between the Siebel Server and IBM DB2 database for Linux, UNIX, and Windows.
Management Server (Remote Method Invocation (RMI) registry)	1099	Registry port number 1099 is used by the Siebel Management Server to listen for requests.
Management Agent (RMI registry)	1199	This port is also used by the Siebel Charts server. If you are using Siebel Charts, then install the Siebel Charts server and the Siebel Management Agent on different computers, or specify different ports during the installation.
File Server	139 Transmission Control Protocol (TCP) 137 and 138 User Datagram Protocol (UDP)	Port numbers for communications between the Siebel Server and the Siebel File System and Database Server are dependent on the file system type. The default TCP port number is 139. The default User Datagram Protocol (UDP) port numbers are 137 and 138.
Siebel Management Server (Apache Tomcat)	8005	Siebel Management Server uses Apache Tomcat internally. Port 8005 is used for shutting down Apache Tomcat.
Search Server	2048	None.
Siebel Charts Server	8001	This port is used by the Web browsers connecting to the Siebel Charts Server.
Siebel Charts Server	8002	This port is used for shutdown requests.

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.

Siebel Architecture

User Request Flow in Siebel Business Applications:

Siebel Archiecture

Siebel client request flows from the user's Siebel Web Client through the system, and back again:

1. A user performs an action that initiates a request. For example, the user clicks a link in the Site Map to navigate to a particular view. The request is generated by the Web browser and Siebel Web Client framework.
2. The request goes through the network, using an existing or new HTTP connection. The request might go through a network router, proxy server, cache engine, or other mechanism.
3. If present, Web server load balancing software evaluates the request and determines the best Web server to forward the request to. It then forwards the request to a Web server.
4. The Web server receives the HTTP request, determines that it is a Siebel application request, and forwards the request to the Siebel Web Server Extension (SWSE) installed on the Web server.
5. The SWSE parses the HTTP message and generates a Siebel Internet Session Network Application Programming Interface (SISNAPI) message, based on the content of the HTTP message. SWSE also parses the incoming cookie or URL to obtain the user session ID.
   • If you are using Siebel load balancing, then SWSE forwards the request to a Siebel Server in round-robin fashion.
   • If you are using a third-party HTTP load balancer, then SWSE forwards the request to the load balancer. The load balancer uses user-configured routing rules to forward the request to a Siebel Server.
     SISNAPI is a messaging format that runs on top of the TCP/IP protocol. It is used for network communication between Siebel Servers and SWSE.
6. On the Siebel Server, the SCBroker component receives the initial request for a session and forwards it to a Siebel Application Object Manager process. Subsequent communication for the session does not use SCBroker.
7. The Siebel Application Object Manager receives and processes the SISNAPI message sent from SWSE.
   If a database query is needed to retrieve the information, then the Siebel Application Object Manager formulates the SQL statement and sends the request to the Siebel Database over a database connection. The database request goes through the database connection, using a protocol format that is specific to the database connector.
8. The database executes the SQL statement and returns data back to the Siebel Application Object Manager. The Siebel Application Object Manager forwards the message to the Web server that originated it. If using a third-party HTTP load balancer, then the message might go through the load balancer before reaching the Web server.
9. The SWSE on the Web server receives the SISNAPI message, and translates it back to HTTP. It then forwards the HTTP message to the Web server. The message is now in the form of Web page content.
10. The Web server load balancer, if present, then forwards the Web page content through the original HTTP connection to the end user's Web browser.
11. The Web browser and the Siebel Web Client framework process and display the return message.

SIEBEL USER REQUEST FLOW

Siebel Web Client (thin client) High Level overview:

1) Request from client goes to Web sever 
2) Web server will send the request to SWSE 
3) SWSE will refer to eapps.cfg for particular application 
4) example: application emedical_enu will have connect string details in eapps.cfg 
5) Connect string will be used to connect to Siebel Server based on load balancing used. there are two options for load balancing 1) Siebel native load balancing(lbconfig.txt) 2) third party load balancing 
6) SCbroker component will receive the request in siebel server from Web Server. 
7) SCbroker will send the request to AOM component 
8) Based on Authentication mode used. AOM will decide to whom the request should be sent 
9) example: if Authentication mode is Database then request will be sent to Database. 
10) database will authenticate the user if authentication mode is database and based on the position and responsibility of the user. user will be given access to data and application views.