Only Siebel: Administration

Recently, we've had a lot of users complaining about the homepage taking too long to load. Why does the login page take long to load? What happens when the login page loads. Below are some of the tasks that Siebel performs while loading the application.

- Verifying Application Schema Version
- Loading / validating State Models (checks whether or not the expiration date is greater than current date)
- Verifying State Model values for transition
- Loading / Validating Personalization rules and rule sets for each event on applets, Business Components, - - Business services and application
- Loading / validating user profile data.
- Loading / validating System preferences
- Loading localized data (Phone format, date format, time zone, currency etc)
- Loads user reporting hierarchy
- Loads application view-responsibility data.
- Message Broadcast (This can be inactivated by inactivating the Message broadcast bar)

The reason behind such a behavior is that some of the static data (localization, license keys etc) and SRF data that are common to all business components are initialized for the object manager process with the first task or user login request. It is this initialization of tasks that causes the delay in service to the first user.

Setting the “OM - PreLoad SRF Data” (PreloadSRF) parameter to TRUE will trigger the loading of this global data for the object manager process when it is initialized upon starting the services. Now the first login should be faster as the burden of reading the static data is pushed to the component startup phase.

NOTE: After setting the parameter to TRUE, you must recycle the services for the parameter value to take effect.

If setting the parameter at the enterprise level, all the object managers in the environment will automatically inherit the parameter value (unless an administrator has specifically set the value on the lower object manager level).

Also, if this parameter is set to be TRUE in conjunction with the MinMTServers parameter, the static data will be loaded for the number of object manager processes specified for the MinMTServers parameter when the component is initialized. This way there will be no delay in service for a large volume of users since the minimum required multi threaded object manager processes would already be initialized.

M.O.S Reference: Doc ID - 476878.1

Get Started

Even though we have a local Siebel environment in our own machines, it is very important to sync up with the existing
server environment. There are multiple people working on one project or on one Siebel server instance. Each one
configures his portion of the project and then checks-in onto the server. So when a person joins a project and before s/he
starts to work, we have to adapt to the environment. This process is explained under "Generate Database", "DB Extract"
and "Get Process". These are normally a onetime process but could be done multiple times if desired. Also note that this
process is done on Development Environment.
After we adapt to the environment and before we start to make any changes, we "Check Out" projects to avoid multiple
developers working on the same project.
After Check-Out we do the actual configuration. Configuration can be anything small like adding a pick list or big like
adding a new screen with complex functionality in it. More information on actual development is explained under
Configuration section.
After necessary changes are made, we compile the object definitions into the SRF file and test. If need go back and
make changes compile again to test. This process is repeated until the desired result is achieved.
After the changes have been tested and the result is positive we check-in this onto Siebel server. This will now have
object definitions both locally and in Siebel server. So now your changes have to be made available for the end users.
For this we compile the server object definitions and deploy the SRF.
All the above process is explained in detail in the following tutorials.

Login Setup

Developers work on Siebel Tools to configure Siebel and they are connected to Local Database. Local database contains
all the object definitions plus the subset of actual data from the server. To get all this information from the server, we
essentially follow a process of extracting all the object definitions from the server and storing into our local database.
Before we connect to the server and be able to extract the database, following steps have to be done. These steps are as
per the Siebel Version 7.7.
After the installation modify the tools.cfg & Siebel.cfg
[Note:] Change the Enterprise name in [Local] and [ServerDataSrc] to the Name of the Enterprise Server
As in the below cfg’s the Enterprise Server Name is ‘ENTSIA8_srv4’

Create a Database User Account:

This is the first step to the whole process. Request a database account either to the DBA or Siebel Administrator. This will be the login account.

For example: GROYSTON. (Logins can be created by the Admin Account only) since he has
the Create Users Privilege.

Code:

use siebeldb8
go
sp_dropuser GROYSTON
go
use master
go
sp_addlogin GROYSTON, GROYSTON, siebeldb8
go
use siebeldb8
go
sp_adduser GROYSTON, GROYSTON, SSE_ROLE
go

This login account should be created and should be added to the group SSE_ROLE. This is a server database account
and should be able to login to the database directly using DB tools like TOAD or SQL-Plus.
Setup Developers as Siebel Employees:

Setup each developer to be a Siebel Employee as described in the steps below.
· Login to Siebel Server using the login SADMIN/SADMIN or as any other account having access to add Siebel
Users. Normally Siebel Administrators have this.
· Go to Site-Map -> Administration-User-> Employees
· Create a new Record with First Name, Last Name and desired login Id.

· Password will be the same as that mentioned while creating the Database User Account above.
· Assign a Position and Responsibility to this User. This would normally be Siebel Administrator. But might
change depending on the setup. This is very important otherwise the database extract would fail.
Setup Developers as Mobile Clients:
After setting up developers as employees, you must register developers as mobile client. This will provide information
for extracting local database for that user. Follow the steps below.
· Login as either SADMIN or any other account having access to employee screens.
· Go to Site Map -> Administration-Siebel Remote -> Mobile Clients
· In the parent server form, choose the appropriate ones. Normally there is only one unless there are multiple
implementations of Siebel on the same server.
· In the Mobile Clients list, click New and fill up the following details.

o Mobile Client Name Example: GROYSTON (Login Account Name)
o User Id. Example: GROYSTON (Login Account Name)
o Routing Model as Mobile Client - Extract Only.

Generate Database

Generate New Database Template commonly known as GenNewDb or GenDb, is process of capturing the physical
representation of Siebel Tables and Indexes from the Siebel Server Database. Siebel Remote uses this template to
extract the database which is done in the next step. (FYI, Make sure Siebel Remote is selected during Server
Installation).
This template is created by running the GenNewDb Server component.

Following is the process of Generating a New Database Template:
· From application level menu, go to SiteMap -> Administration-Server Management-> Jobs
· On the top applet, click New to create a new job and enter the following parameters
o Under Component/Job Field pick Generate New Database
o Under Requested Server, enter server name where the job should run. Siebel Admins would know this or
find out by navigating to Sitemap -> Administration-Server Configuration -> Servers
· In the bottom applet, enter Job Parameters by clicking New

o Under Name field, open pick applet and choose “SQL Anywhere Database” and click ok.
o Under value field it would default to sse_utf8.dbf
o There are other optional parameters that could be used. This is not covered here as it is not required. If
needed refer BookShelf.
· Now on the top applet click Start to submit the Job.
After few minutes refresh and check the status of the Job should change to Success. If so you have successfully created
the Database Template.

This process is done every time a new database extract is requested.
Next we will extract the database which has actual data.

Extract Database

This process extracts data from the server database for the requested mobile user and stores temporarily into a
compressed file onto the server. This file contains the data and it is downloaded into the local machine as explained in
the next step.
Make sure the user has been assigned a position and responsibility as explained under previous steps and follow the
below steps to extract data.

· Go to SiteMap -> Administration-Server Management-> Jobs
· On the top applet, click New to create a new job and enter the following parameters

o Under Component/Job Field pick Database Extract
o Under Requested Server, enter server name where the job should run. Siebel Admins would know this or
find out by navigating to Sitemap -> Administration-Server Configuration -> Servers
· In the bottom applet, enter Job Parameters by clicking New

o Under Name field, open pick applet and choose Client Name and click ok.
o Under value field enter the name of the Client Name Example: GROYSTON. Remember that this is
normally a login name.
o Now on the top applet click Start to submit the Job.
This will take a few minutes and the job status changes to Success.
After successfully running this step, you should now observe that a directory structure gets created normally under
$siebsrvr_root\DOCKING\ GROYSTON. Under this you will see folders inbox, outbox and dobjinst.dbf file. The
outbox folder contains several other files which is needed for the next step.
As you can see the Folder GROYSTON has been created with the .dbf file

Initializing Client

Now you have to download the database file into your local computer. This process is called initializing. For this make
sure you have installed Siebel Tools as explained under Installing Siebel.
Follow the steps as mentioned below.
· Launch Siebel Tools. Connect to Local.
· When the login using the machine name as entered previous steps.

Example: GROYSTON. The following message will appear "The local Siebel database was not found. Would
you like to connect to the Siebel Remote server to initialize the local database?"

This message appears because Siebel Tools could not find the database file see_data.dbf under "C:\Program
Files\Siebel\7.7\Tools\LOCAL" This directory location may change depending upon the settings in your
tools.cfg file. The parameter to check is ConnectString under the section [Local]. Note that if there is already
sse_data.dbf this message might not show.

· Click Yes. Siebel Tools will start downloading and would take a while.

After this process is complete your Siebel Tools will Open.
If the initialization was successful you will see the database file see_data.dbf under "C:\Program Files\Siebel\7.7\Tools\
LOCAL"

Do the necessary Configurations inorder to connect the Local Datasource
View  OptionsDebug tab
Executable: D:\Program Files\Siebel\8.0\web client\BIN\siebel.exe
CFG File: D:\Program Files\Siebel\8.0\web client\BIN\ENU\siebel.cfg
Browser: C:\Program Files\Internet Explorer\iexplore.exe
Working Directory: D:\Program Files\Siebel\8.0\web client\BIN

Troubleshooting:
· For any reason if Siebel Tools is not able to connect to the server, check your tools.cfg file for the server it is
trying to connect under the section [Local]. Parameter to check is the DockConnString and EnterpriseServer.
· If the initialization gets stuck or ends abruptly, delete the sse_data.dbf file and redo the steps above.
Now you are almost done in starting your development step but there is one other important step you need to do before
starting your work. This step is called the Get Process which is explained next.
Get Process
After all the initialization and login into Tools, the object definition and configuration information that you would see in
there is the out of the box configuration which Siebel supplies. But this is won’t be in sync with the object definitions or
any changes that have been made previously in the server. So we do a Get Process to sync up with the existing
configuration or projects.
Follow these steps for Get Process:
· Login into Siebel with connecting it to Local
· Go to Tools -> Check Out

· Choose the Repository. Normally this will be Siebel Repository.
· Click on the radio button for All Projects
· Click Get

All the server definitions will start to copy into your Local Repository. Once completed, your repository will be in sync
with the one on the server.

Troubleshooting:

It is very common for people to complain that they are not able to a Get or Check-Out. This would happen only when
the server data source parameter is not set correct in Tools. To set this right, in Tools go to View-> Options ->Check In/
Out tab. Change the server data source name to the ODBC Data Source which connects to the server. ODBC Data
source is defined under Windows Control Panel -> Administrative Tools -> Data Sources (ODBC). Fix this and this
should solve the problem.
Note that Get process is very similar to Check-Out except that the Get Process won’t lock the project on the server.
Check out process syncs the object definitions and lock the project on the server, but the Get process only syncs the
object definition between your local machine and the server. We will see the Check-Out process in detail in the next
step.

Now that your repository in the local machine is current, the complied version of this that is SRF file needs to have this
info. So we need to do a full compile. This will ensure that when you making changes later on and testing it, you will
test with all updated information. Check the other topic on how to compile.
Next we will look at the topic of making changes.
Siebel Check Out Process
All Siebel configurations should be done on your Local Environment. It is a very bad practice to make changes directly
on the server because you can’t roll back. So making changes directly onto the server may lead to loose current
configuration. So we checkout projects to get all the current configuration definition into your local machine and you
could further configure as needed. It also helps in locking the projects onto the server so that no other person can make
changes while your changes are progress. This way we know which developer is working on what project.

To checkout a project:

· In Siebel Tools, choose Tools -> Check Out. A checkout box will appear.
· Select single project or multiple projects for which you want to make changes. If the project has already been
locked then it would show the name of the person who has checked out or locked and the date.
· You might click on options to make sure that your tools are pointing to the right local and server database.
· Click Check Out.
· Tools will start to checkout and will take a little time to copy information from the server to your local client.
To undo checkout:
After checking out and making modifications on your client machine, you might want to undo all the changes you have
done to the project. The only way you can do this is by undoing check out. To undo,

· In Siebel Tools go to Tools -> Check In
· Select the project you want to undo
· Click Undo check out. This will remove the lock on the server without any modifications.
· On object explorer select Project
· Query for the project to which you want to undo project changes.
· Remove the lock on the project by clicking on the locked property.
Note that after you undo check out, your local object definitions is out of sync with the server. So if you want to be in
synch again with the server either do a Get on the project or Check out that project again.
After we are done check out, we can start making changes as per requirement. Changes could be any where from
creating a pick-list to creating a whole screen. These changes are nothing but configuration which is covered under
Siebel Configuration section. Assuming that the changes have been made, these changes need to be compiled and tested
which is covered next.

Compile Siebel

After changes are made in Siebel Tools, it is important to test locally before moving those to the server. To test the
changes we should compile and check in our local machine.

As already mentioned in the Siebel SRF section, all the object definitions defined in Siebel Tools have to be compiled
into one SRF. So to test, compile into the SRF that the Siebel application is referring to and this normally would be
"[install directory]\Siebel\7.7\web client\OBJECTS\ENU\siebel.srf"
To compile, in Siebel Tools go to Tools => Compile. Here you will have the option of selecting individual projects or
you could do a full compile by selecting all projects.
Below is the snapshot of Siebel Tools.

There is also an option to choose the SRF you want to compile to by browsing for the SRF. When testing locally point
the compilation to the SRF the local client application is referring to.

Testing Siebel

Any software development has to be checked for its correctness and accuracy before it finally available for use to the
end user. So testing the software also popularly known as QA (Quality Assurance) is very crucial.
There are different methodologies and different stages at which testing is done. Below are some very basic and common
testing practices.

Unit Testing:

This testing is the first stage where the developer who changed or configured the application test himself for correctness
locally before it is available to the actual designated testing individual. For example a new View is to be created with
certain applets associated to certain Business Components. So the developer finishes the job of creating a view and
other required stuff and then compiles locally and checks if the view developed is actually the one desired. If the results
are not what is expected, the developer makes again necessary changes, compiles and then test again. Only after this
stage is complete we check in onto the server which is the next stage of development.

Testing on Dev Server:

After Unit Testing, all the changes are checked in onto the development server and the server is compiled. After

compiling the server, we test the changes on the server through Thin Client. The results of this are compared to the
requirements and are approved in development environment. If the results don’t match the requirement, the developer
goes back again to the local environment and makes necessary changes and repeats the process of testing.

Testing on Staging Server:
Staging server is a temporary stage to test new or revised work before it is made live in production. This server is very
similar to the production server. So any thing seen here will be reflected later onto production server later after
approved over here. There are certain individuals assigned to do testing on this server. These individuals called as
testers or QA personnel’s check closely any new or revised work and match up with the requirements. They also look
for any conflicts or potential problems called defects. These defects are logged using soft wares like “Mercury Test
Director” and are assigned to developers and will have test cases and description to replicate the defect. Then the
developer makes again necessary changes and follows the whole process again. Once the changes or any other work is
approved in staging server, this is moved onto the production server where the end users see it.

Testing on Production Server:

This server is where the actual end users connect to. This server will have all the production data. In spite of thorough
testing on the staging server, it is quite possible that there could be some defects on the production server. The QA
personnel do some final testing on the production server and if everything seems to look fine, then it is approved in
production and will be called as successfully deployed.
Please note that the above description is only a basic level of testing just for our understanding, but most often testing
process is very rigorous and complicated. This process differs from company to company.
Check In Process
After making changes, compiling and testing to make sure the changes meets the desired output, we would like to make
the changes be available to all the other users as well. So the first step is to check-in your changes, which is explained
here.
All the changes are in your local machine database and still not in the server. To have this available on the server
database we check-in using Siebel Tools.

Follow these steps to check-in:
· Launch Siebel Tools connecting it to the Local
· go to Tools -> Check In

· A check in box will appear as shown in the screenshot below.

· This box will show all the projects that is been checked out or locked locally
· You could either choose one, multiple or all projects to check-in
· If you observe there are multiple button on the box that you could select.
· It is highly recommended to select the project and click the Diff button. Under Diff it would list all the changes
that you have made locally and not yet available on the server. This step is called Project Diff. This process
could take a little while. If you notice in the screenshot below, the objects defined locally are compared with the
server. In this Compare Object box, uncheck the Show All objects. This will show only the differences. If you
observe in the screen shot, the difference is the value of Drill-Down object.

· Once you confirm that the changes you have made is what you intended and have not done anything nondesired,
you are ready to Check-In
· So choose the projects to check-in and click on Check-In. After a little time changes would be updated onto the
server and the lock will be removed from both the local machine and on the server.
Now that the changes are now available on the server, that project is now available for other developers to check-out
and start making their changes or compile can compile the server.
Compiling Server

After checking-in all the changes on the server we have to compile the changes into the SRF. There are two places
where we can do this. We could do this on the server itself or we could do it locally by connecting to the server. We will
discuss here on how to compile in our local machine by connecting to the server.
Follow the step below for compiling:
· Stop Siebel Services
· Copy the srf file from the server on to the local machine
· Login into Siebel tools by connecting to the Server as shown in the screen shot below.

The server connectivity information is stored in the config file. Check the config file if you have any problems
connecting to the server.
· After logging in, under menu choose Tools -> Compile. Choose the projects you would like to compile.
· Under Siebel repository file, browse for the srf file you copied in the previous step and hit compile
· Back up the srf file on the server (Just for possible rollback)
· Replace the srf file on the server with the new srf file that was just compiled
· Start Siebel services.
After the above steps all the changes should be now available on the server. Logon to the thin client and test.

-Editor: Royston Goveia

Only Siebel

Pages

Tuesday, January 15, 2013

How to time trigger workflows through command prompt

Tuesday, September 11, 2012

How to Optimize Siebel Application Login Time

Monday, September 21, 2009

Unable to initialize the Upgrade Wizard

Sunday, September 6, 2009

How to extract your Local DB in Siebel