Siebel Synchronous and Asynchronous Server Requests

Requests are tasks processed by the batch components. SRBroker and SRProc components are responsible for routing the requests from the requestor to the target component.

SRBroker (Server Request Broker)

SRBroker routes requests to target components based on the information in the request. At least one instance of SRBroker component should be running on each Siebel server. SRBroker caches information from the Gateway name server and knows which component is running in which Siebel server. It also caches information from the shared memory and knows which component is running in the local Siebel server. Each instance of SRBroker communicates with other SRBroker components running on the same Siebel server or other different Siebel servers to route requests in the same Enterprise. 

For more details regarding SRBroker, click here

SRProc (Server Request Processor)

SRProc processes server requests that are stored in the Siebel database. SRProc has connection information to the Siebel database and it stores and retrieves information from the S_SRM_REQUEST table. SRProc communicates with only the SRBroker component running on the same Siebel server. Every SRBroker will connect to SRProc in the same Siebel server to send requests for storing them in the database. SRProc will connect to one of the SRBroker components in the same Siebel server to forward requests for processing. Successfully completed requests are removed from the S_SRM_REQUEST table by the component "Server Tables Cleanup" (SvrTblCleanup).

For more information regarding SRProc, click here

There are 2 different types of server requests:

1. Synchronous: The requests are send to the target component and the requestor waits for a response.
2. Asynchronous: The requests are send to the target component and the requestor does not wait for a response. The requestor also does not trigger any callback after it gets a response. We can also schedule a start time while submitting requests.

Server Requests - Routing logic

If the target component is running on the same Siebel server as the requestor, SRBroker will always route the request to the instance of the component running on the  same Siebel server. SRBroker will never route requests to other Siebel servers, if the component is running in the local Siebel server.

If the target component is not running on the same Siebel server, then SRBroker routes the request to other Siebel server where the component is running. If the target component is running on multiple Siebel servers, then it uses Round Robin fashion to route subsequent requests among the Siebel servers.

Routing logic - Same Siebel server

• Synchronous Request: SRBroker will route the request to the target component if it has already established a Siebel Internet Session API (SISNAPI) connection. If there is no connection, SRBroker will establish one upon getting the first request for the component. Once the component finishes processing the request, it sends the response to SRBroker. SRBroker then sends back the response to the requestor.
• Asynchronous Request (DirectDb Mode): Any requests from the requestor will be written to the S_SRM_REQUEST table first. Any SRProc component can pickup the request as long as the target component is running on the same Siebel server.
• Asynchronous Request (Asynch Mode): If the target component is running on the same Siebel server, then routing is same as synchronous mode without any response.
• Scheduled Asynchronous Request: SRBroker on the local server of the requestor will send the request to SRProc, which first writes the request to the S_SRM_REQUEST table. When the scheduled start time is current, any SRProc from any Siebel server can pickup the request from the database and send it to the SRBroker on the same Siebel server, which in turn routes it to the target component.After the component finishes processing the request, it sends response to SRBroker. SRBroker sends the response to SRProc. SRProc will update the record for the request in the database with the response.

Routing logic - Multiple Siebel servers

• Synchronous Request: If the target component is not available on the local Siebel server as the requestor, then the SRBroker in the local Siebel server will send the request to another SRBroker on the first Siebel server where the component is enabled and online. If the request's target component is running on that Siebel server, SRBroker on that server will route the request to the component. Once the SRBroker receives response from the component it will send the response back to the original SRBroker, which in turn sends the response back to the requestor. If the target component is not running on the first Siebel server, the SRBroker on the local Siebel server will try the next Siebel server that has the target component running. If the component is unavailable in any of the servers, then the request fails.
• Asynchronous Request (DirectDb Mode): Any requests from the requestor will be written to the S_SRM_REQUEST table first. Any SRProc component can pickup the request as long as the target component is running on the same Siebel server.
• Asynchronous Request (Asynch Mode): If the target component is running on the same Siebel server, then routing is same as synchronous mode without any response.
• Scheduled Asynchronous Request: SRBroker on the local server of the requestor will send the request to SRProc, which first writes the request to the S_SRM_REQUEST table. When the scheduled start time is current, any SRProc from any Siebel server can pickup the request from the database and send it to the SRBroker on the same Siebel server, which in turn routes it to the target component.After the component finishes processing the request, it sends response to SRBroker. SRBroker sends the response to SRProc. SRProc will update the record for the request in the database with the response.

Load balancing

1. If there are more than one instance of the target component are running on the local Siebel server as the requestor, SRBroker will use Round Robin logic to route the requests among the components.
2. If and only if the target component is not available on the local Siebel server as the requestor, SRBroker on the local Siebel server will send the request to other SRBroker on other Siebel servers on a Round Robin fashion.

Siebel: Increase Tracing for Workflow Process Manager and Workflow Process Batch Manager

Workflows in Siebel can be run in the below ways:

• Server Component: Workflow Policy, Repeating component request, srvrmgr, submitting a task for the component, eScript (submitting request for the component), Runtime events (submitting request for the component). In all the above ways, the request for the Workflow process execution is done by the Workflow Process Manager component (WfProcMgr) or the Workflow Process Batch Manager (WfProcBatchMgr) component.
• Application Object Manager:  Runtime event, Scripting and simulation in the Thin Client.
• Client: Runtime event, Scripting and simulation in the mobile web Client or the Dedicated Client.

Tracing on Server:

Increase the Log level for the below events for the Workflow Process Manager component (WfProcMgr) or the Workflow Process Batch Manager (WfProcBatchMgr) component.

Event Type	Log Level
Task Configuration	5
Object Manager SQL Log	5
Workflow Definition Loading	5
Workflow Engine Invoked	5
Workflow Process Execution	5
Workflow Step Execution	5
Object Manager Business Component Operation and SetErrorMsg Log	5
Object Manager Extension Language SetErrorMsg Log	5
Object Manager Business Service Operation and SetErrorMsg Log	5
SQL Tracing	5

The changes will take effect immediately and does not need a server bounce.The Workflow Process Batch Manager log file (WfProcBatchMgr_xxx.log) and the Workflow Process Manager log file (WfProcMgr_xxx.log) are located in the SIEBSRVR_ROOT\log directory.

Tracing on the Application Object Manager:

Increase the log level for the below for the Application Object Manager component like the Callcenter Object Manager.

Event Type	Log Level
Task Configuration	5
Object Manager SQL Log	5
Workflow Definition Loading	5
Workflow Engine Invoked	5
Workflow Process Execution	5
Workflow Step Execution	5
Object Manager Business Component Operation and SetErrorMsg Log	5
Object Manager Extension Language SetErrorMsg Log	5
Object Manager Business Service Operation and SetErrorMsg Log	5
SQL Tracing	5

The changes do not need a server bounce and the log for the application Object manager is generated at SIEBSRVR_ROOT\log directory.

Tracing on the Client:

Set the below environment variable and the siebel.log will be generated in <ClientRootDir>\log directory

SIEBEL_LOG_EVENTS = 5

Siebel: How to manage the size of Siebel Log Files

2 Siebel component parameters will help us in managing the size of the logs and also to restrict the amount of disk space that is used.

• LogSegmentSize

This parameter defines the size of each segment of the log file. If we give the value as 128, then each segment will be of 128 kilo bytes. A value of  '0' turns off segmenting.

• LogMaxSegments

This parameter defines the maximum number of  segments that are kept. when it reaches the maximum value, it overwrites the segments. A value of '0' turns off segmentation.

Configuring Log Segments on the Siebel Server

 Run the below commands from the server manager command line interface (SIEBEL_HOME\siebsrvr\BIN\srvrmgr.exe):

change param LogSegmentSize=<value> for comp <comp name>

change param LogMaxSegments=<value> for comp <comp name>

Restart the component for the changes to take effect.

Configuring Log Segments on Siebel Web Server Extension

We set the parameters "LogSegmentSize" and "LogMaxSegments" in the eapps.cfg file.

The eapps.cfg file is located in the SIEBEL_HOME\SWEApp\BIN directory.

Bounce the web server for the changes to take effect.

To set the parameters back to default, set them to '0'.

Siebel: How to Analyze FDR output in Siebel

FDR or Flight Data Recorder is a Siebel server framework which collects the data about the siebel application in a buffer and flusher the data into a binary file with .fdr extension in the event of a crash. The file is located in the /bin directory. This binary .fdr file can be processed into a readable csv file to help us analyze and understand the exact prior steps before the crash has happened.

Identifying the correct FDR file when a crash occurs

We can use the information in the file name of the .fdr file to identify the correct file.

The file name has the timestamp and the process id that crashed in the below format:

T<YYYYMMDDHHMM>_P<process id value>.fdr

for example:

T201503130749_P017144.fdr 

Is a file name that is based on a component that was started on March 13, 2015 at 7:49 AM where the process id value was 17144.

If we know the process id that has crashed, we can find the file by it or else we can look at the files at with the timestamp.

If we have the crash_***.txt , we can convert the hexa decimal process id found in the file to a decimal value and then find the correct fdr file.

Process Binary .fdr file to .csv file

• In UNIX environment, run the environment variables before running the sarmanalyzer.  run the below command from the $SIEBEL_ROOT/siebsrvr directory:
• . ./siebenv.sh
• Run the sarmanalyzer by issuing the below command:

                       sarmanalyzer -o <output_csv_file> -x -f <fdr_file>

                       For example:

                       sarmanalyzer -o T201503130749_P017144.csv -x -f T201503130749_P017144.fdr

 The output .csv file will be written to the SIEBSRVR_ROOT\bin directory.

Analyze output of fdr file

1. Open the csv file using microsoft excel and add custom filters to the top column as below
   
2. Filter the SubAreaDesc column by the value ** CRASHING THREAD **.
   
3. Note down the value in the "ThreadID" column. in this case it is 163. This is the crashing process Id.
   
4. Now, remove the filter for the "SubAreaDesc" column and filter the "ThreadID" column with the earlier noted down Process Id (pid) which is 163 in this case like below
   
5. Now navigate to the end of the document to reach the crashing thread and then we can see the steps that got executed just before the process crashed. you can get more details from SubAreaDesc, UserInt1, UserInt2, UserStr1, UserStr2 columns
   
6. The fdr output file created by sarmanalyzer.exe is not sorted in chronological order fro performance reasons. we can sort the csv file on the "FdrID" column to sort in reverse chronological order.
   

Siebel: Testing Siebel Inbound Web Service on a Mobile Web Client

Siebel Mobile Web Client can serve the same web services that are deployed on the Siebel server.
This helps developers in testing their Inbound Web Services without going through installing the whole Siebel enterprise.

The Web service functionality is an extension of the Siebel mobile web client and is processed by a second siebel.exe process. As soon as the siebel mobile client is started, this second siebel.exe process also starts and listens on a specific port which we define in the client's .cfg file. The child process exits once we logoff the mobile web client.






This setup supports authentication in URL format, SOAP headers, WS-Security headers.
It does not support Single sign-on,  stateful and stateless.

We need to add the below 2 parameters in the client's .cfg file to enable Web services on mobile web client.

• set the following parameters in the [siebel] section of the client's .cfg file:
• EnableWebServices = TRUE
• WebServicesPort = port number to lister (default is 2330)

After this, once the siebel mobile web client starts, you can see 2 siebel.exe processes, one if which will accept and process web service requests.

We can also start the siebel.exe process which will support the web services without starting the siebel mobile web client by running the below command:

• SIEBEL_CLIENT_ROOT\bin\siebel.exe /l <language_code> /c <configuration_file> /u <username> /p <password> /d <datasource_in_cfg> /webservice <port_number>

• for example:  C:\Siebel\8118\client1\bin\siebel.exe /l enu /c enu\uagent.cfg /u SADMIN /p SADMIN /d Sample /webservice 2330
• To stop the process, you have to manually end the process from Task manager.

You can use the netstat utility from the DOS prompt to determine if the siebel.exe process is listening to accept and process requests:

• From the DOS prompt, give the below command:
• netstat -a -p TCP
• examine the output for the port number and it should be "LISTENING"

Now, we can invoke Web services on the Siebel mobile web client by passing credentials in the URL, in the SOAP header, or in the WS-Security header.

Example of Passing User Credentials in the URL

The URL format is:

http://<host>:<port>?SWEExtSource=WebService&Username=<username>&Password=<password>

For example:

http://localhost:2330?SWEExtSource=WebService&Username=<username>&Password=<password>

The following is an example of a request:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header/>

  <soapenv:Body>

<asi:SiebelContactQueryById>

<PrimaryRowId>1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById >

  </soapenv:Body>

</soapenv:Envelope>

Example of Passing User Credentials in the SOAP Header

The URL format is:

http://<host>:<port>?SWEExtSource=WebService&WSSOAP=1

For example:

http://localhost:2330?SWEExtSource=WebService&WSSOAP=1

The following is an example of a request:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header>

<UsernameToken xmlns="http://siebel.com/webservices">SADMIN</UsernameToken>

<PasswordText xmlns="http://siebel.com/webservices">SADMIN</PasswordText>

<SessionType xmlns="http://siebel.com/webservices">None</SessionType>

  </soapenv:Header>

  <soapenv:Body>

<asi:SiebelContactQueryById >

<PrimaryRowId>1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById >

  </soapenv:Body>

</soapenv:Envelope>

Example of Passing User Credentials in the WS-Security Header

The URL format is:

http://<host>:<port>?SWEExtSource=SecureWebService&WSSOAP=1

For example:

http://localhost:2330?SWEExtSource=SecureWebService&WSSOAP=1

The following is an example of a request:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header>

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<wsse:UsernameToken xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">

<wsse:Username>SADMIN</wsse:Username>

<wsse:Password Type="wsse:PasswordText">SADMIN</wsse:Password>

</wsse:UsernameToken>

</wsse:Security>

  </soapenv:Header>

  <soapenv:Body>

<asi:SiebelContactQueryById soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<PrimaryRowId xsi:type="xsd:string">1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById>

  </soapenv:Body>

</soapenv:Envelope>