Running WLST from Ant

WebLogic Server provides a custom Ant task, wlst, that invokes a WLST script from an Ant build file. You can create a WLST script (.py) file and then use this task to invoke the script file, or you can create a WLST script in a nested element within this task.

For more information about Ant, see Apache Ant 1.7.1 Manual.

The wlst task is predefined in the version of Ant that is installed with WebLogic Server. To add this version of Ant to your build environment, run the following script:
WL_HOME\server\bin\setWLSEnv.cmd (or setWLSEnv.sh on UNIX)
where WL_HOME is the directory in which you installed WebLogic Server.

If you want to use the wlst task with your own Ant installation, include the following task definition in your build file:

classname="weblogic.ant.taskdefs.management.WLSTTask" />

Parameters
Below are the wlst task parameters that you specify as attributes of the element.


properties="propsFile"

Name and location of a properties file that contains name-value pairs that you can reference in your WLST script.

WLST Help

To display information about WLST commands and variables, enter the help command.

If you specify the help command without arguments, WLST summarizes the command categories. To display information about a particular command, variable, or command category, specify its name as an argument to the help command. To list a summary of all online or offline commands from the command line using the following commands, respectively:

help('online') help('offline')The help command will support a query; for example, help('get*') displays the syntax and usage information for all commands that begin with get.

For example, to display information about the disconnect command, enter the following command:

wls:/mydomain/serverConfig> help('disconnect')

The command returns the following:

Description:
Disconnect from a weblogic server instance.

Syntax:
disconnect()

Example:
wls:/mydomain/serverConfig> disconnect()

WLST Eg: Redirecting Error and Debug Output to a File

Redirecting Error and Debug Output to a File
To redirect WLST information, error, and debug messages from standard out to a file, enter:

redirect(outputFile,[toStdOut])
stopRedirect()

This command also redirects the output of the dumpStack() and dumpVariables() commands.

For example, to redirect WLST output to the logs/wlst.log file under the directory from which you started WLST, enter the following command:

wls:/mydomain/serverConfig> redirect('./logs/wlst.log')

Syntax for WLST Commands

Follow this syntax when entering WLST commands or writing them in a script:

■Command names and arguments are case sensitive.
■Enclose arguments in single or double quotes. For example, 'newServer' or "newServer".
■If you specify a backslash character (\) in a string, either precede the backslash with another backslash or precede the entire string with a lower-case r character. The \ or r prevents Jython from interpreting the backslash as a special character.
For example when specifying a file pathname that contains a backslash:

readTemplate('c:\\userdomains\\mytemplates\\mytemplate.jar') or
readTemplate(r'c:\userdomains\mytemplates\mytemplate.jar')

■When using WLST offline, the following characters are not valid in names of management objects: period (.), forward slash (/), or backward slash (\).
If you need to cd to a management object whose name includes a forward slash (/), surround the object name in parentheses. For example:

cd('JMSQueue/(jms/REGISTRATION_MDB_QUEUE)')

Syntax for WLST Commands

Follow this syntax when entering WLST commands or writing them in a script:

■Command names and arguments are case sensitive.
■Enclose arguments in single or double quotes. For example, 'newServer' or "newServer".
■If you specify a backslash character (\) in a string, either precede the backslash with another backslash or precede the entire string with a lower-case r character. The \ or r prevents Jython from interpreting the backslash as a special character.
For example when specifying a file pathname that contains a backslash:

readTemplate('c:\\userdomains\\mytemplates\\mytemplate.jar') or
readTemplate(r'c:\userdomains\mytemplates\mytemplate.jar')

■When using WLST offline, the following characters are not valid in names of management objects: period (.), forward slash (/), or backward slash (\).
If you need to cd to a management object whose name includes a forward slash (/), surround the object name in parentheses. For example:

cd('JMSQueue/(jms/REGISTRATION_MDB_QUEUE)')

WLST Examples

Examples
To use WLST in script mode:
java weblogic.WLST c:\myscripts\myscript.py

To run a WLST script on a WebLogic Server instance that uses the SSL listen port and the demonstration certificates:
java -Dweblogic.security.SSL.ignoreHostnameVerification=true
-Dweblogic.security.TrustKeyStore=DemoTrust weblogic.WLST
c:\myscripts\myscript.py

To use WLST in interactive mode:
java weblogic.WLST

To connect to a WebLogic Server instance after you start WLST in interactive mode:
wls:/offline> connect('weblogic','weblogic','localhost:7001')

Exiting WLST
To exit WLST, enter the exit() command:

wls:/mydomain/serverConfig> exit()Exiting WebLogic Scripting Tool ...c:\>

WLST Interactive Mode, Script Mode, and Embedded Mode

Interactive Mode, Script Mode, and Embedded Mode
You can use any of the following techniques to invoke WLST commands:

■Interactively, on the command line—Interactive Mode
■In batches, supplied in a file—Script Mode
■Embedded in Java code—Embedded Mode
Interactive Mode
Interactive mode, in which you enter a command and view the response at a command-line prompt, is useful for learning the tool, prototyping command syntax, and verifying configuration options before building a script. Using WLST interactively is particularly useful for getting immediate feedback after making a critical configuration change. The WLST scripting shell maintains a persistent connection with an instance of WebLogic Server.

WLST can write all of the commands that you enter during a WLST session to a file. You can edit this file and run it as a WLST script. For more information, see startRecording and stopRecording.

Script Mode
Scripts invoke a sequence of WLST commands without requiring your input, much like a shell script. Scripts contain WLST commands in a text file with a .py file extension, for example, filename.py. You use script files with the Jython commands for running scripts.

Using WLST scripts, you can:

■Automate WebLogic Server configuration and application deployment
■Apply the same configuration settings, iteratively, across multiple nodes of a topology
■Take advantage of scripting language features, such as loops, flow control constructs, conditional statements, and variable evaluations that are limited in interactive mode
■Schedule scripts to run at various times
■Automate repetitive tasks and complex procedures
■Configure an application in a hands-free data center
For information about sample scripts that WebLogic Server installs, see WLST Sample Scripts.

Embedded Mode
In embedded mode, you instantiate the WLST interpreter in your Java code and use it to run WLST commands and scripts. All WLST commands and variables that you use in interactive and script mode can be run in embedded mode.

Listing 2-1 illustrates how to instantiate the WLST interpreter and use it to connect to a running server, create two servers, and assign them to clusters.
--------------------------------------------------------------------------------

WLST

This document describes the WebLogic Scripting Tool (WLST). It explains how you use the WLST command-line scripting interface to configure, manage, and persist changes to WebLogic Server instances and domains, and monitor and manage server runtime events.

The WebLogic Scripting Tool (WLST) is a command-line scripting environment that you can use to create, manage, and monitor WebLogic Server domains. It is based on the Java scripting interpreter, Jython. In addition to supporting standard Jython features such as local variables, conditional variables, and flow control statements, WLST provides a set of scripting functions (commands) that are specific to WebLogic Server. You can extend the WebLogic scripting language to suit your needs by following the Jython language syntax. See http://www.jython.org.

Using WLST Online or Offline
You can use WLST as the command-line equivalent to the WebLogic Server Administration Console (WLST online) or as the command-line equivalent to the Configuration Wizard (WLST offline). For information about the WebLogic

WLST Online Scripts

You can use WLST to connect to a running Administration Server and manage the configuration of an active domain, view performance data about resources in the domain, or manage security data (such as adding or removing users). You can also use WLST to connect to Managed Servers, but you cannot modify configuration data from Managed Servers.

WLST online is a Java Management Extensions (JMX) client. It interacts with a server’s in-memory collection of Managed Beans (MBeans), which are Java objects that provide a management interface for an underlying resource

The WLST online scripts helps to perform administrative tasks and initiate WebLogic Server configuration changes while connected to a running server. WLST online scripts are located in the following directory: SAMPLES_HOME\server\examples\src\examples\wlst\online, where SAMPLES_HOME refers to the main examples directory of your WebLogic Server installation, such as c:\beahome\wlserver_10.3\samples.

WLST Offline Scripts
The WLST offline scripts helps to create domains using the domain templates that are installed with the software. The WLST offline scripts are located in the following directory: WL_HOME\common\templates\scripts\wlst, where WL_HOME refers to the top-level installation directory for WebLogic Server

Without connecting to a running WebLogic Server instance, you can use WLST to create domain templates, create a new domain based on existing templates, or extend an existing, inactive domain. You cannot use WLST offline to view performance data about resources in a domain or modify security data (such as adding or removing users).

WLST offline provides read and write access to the configuration data that is persisted in the domain’s config directory or in a domain template JAR created using Template Builder


Note the following restrictions for modifying configuration data with WLST offline:

■Oracle recommends that you do not use WLST offline to manage the configuration of an active domain. Offline edits are ignored by running servers and can be overwritten by JMX clients such as WLST online or the WebLogic Server Administration Console.
■As a performance optimization, WebLogic Server does not store most of its default values in the domain’s configuration files. In some cases, this optimization prevents management objects from being displayed by WLST offline (because WebLogic Server has never written the corresponding XML elements to the domain’s configuration files). For example, if you never modify the default logging severity level for a domain while the domain is active, WLST offline will not display the domain’s Log management object.
If you want to change the default value of attributes whose management object is not displayed by WLST offline, you must first use the create command to create the management object. Then you can cd to the management object and change the attribute value

OBIEE Request Flow

The below diagram shows the basic architecture of OBIEE and its components:

Now, first of all lets understand the flow in which a request flows from Client to Data Source.
If a client runs a report, the request first goes to the Presentation Server and then it gets routed to the BI Server and then it gets further routed to the underlying Database or the data source.
Client -> Presentation Server -> BI Server -> Data source
Now, the request is routed back through the similar route to the client. Which means, the data is fetched from the Data source and it gets routed to Presentation server through BI server and then to the client.
Client <- Presentation Server <- BI Server <- Data Source
The above flows provide a very basic idea of how the data is fetched and showed in a report in OBIEE.
Now, lets understand it more properly by dividing the above diag. into segments and then :
1) Client and User Interface
2) Presentation Server & Presentation Catalog
3) BI Server & Admin Tool
4) Datasource
Client & User Interface: This level has the UI of OBIEE which is accessible to the clients and users. The OBIEE UI has several components like OBIEE Answers, Interactive Dashboards etc.
• Oracle BI Answers is a powerful, ad hoc query and analysis tool that works against a logical view of information from multiple data sources in a pure Web environment.
• Oracle BI Interactive Dashboards are interactive Web pages that display personalized, role-based information to guide users to precise and effective decisions.
• BI Delivers is an alerting engine which gives users flexibility to schedule their reports and get them delivered to their handheld devices or interactive dashboards or any other delivery profile and helps in making quick business decisions.
In simpler terms we can say that, this is a web application which is accessible to the users for preparing their reports/dashboards and do Ad-Hoc reporting to cater the business needs.
We have divided OBIEE Architecture in 4 segments to better understand it.
1) Client and User Interface
2) Presentation Server & Presentation Catalog
3) BI Server & Admin Tool
4) Datasource
We have covered the first segment in the previous post. So, lets understand the second segment.

Presentation Server & Presentation Catalog:
The BI Presentation server is basically a web server on which the OBIEE web application runs. It processes the client requests and routes it to the BI Server and vice versa. It can be deployed on any of the following IIS or Oc4j. It makes use of the Presentation catalog which contains the aspects of the application.
The Presentation catalog stores the application dashboards, reports, folders and filters. It also contains information regarding the permissions of dashboards & reports created by users. It is created when the Presentation server starts and can be administered using the tool called Catalog Manager.
In other words we can say that the Presentation server and the Presentation Catalog are together responsible for providing the clients with a web server on which the web application runs and also administers the look and feel of the User Interface.
BI SERVER AND ADMIN TOOL
BI Server is a highly scalable query and analysis server. It is the heart of the entire architecture. It efficiently integrates data from multiple relational, unstructured, OLAP application sources, both Oracle and non-Oracle.
It interacts with the Presentation server over TCP/IP and takes the reporting request from the presentation server. Then the BI server processes the request and form logical and physical queries(in case of database as data source) and this physical query is sent to the underlying data source from which the data is processed. The BI Server interacts with the underlying database using ODBC. Hence, the entire processing of request is done by the BI server.
In the above paragraph I have mentioned that the BI server creates a logical and physical query. But how will the BI server generate this query?? How will the BI Server know what all joins need to be used?? I guess all these questions must be coming to your mind. So, lets understand the underlying process..
The BI server makes use of the BI Repository for converting the user request into logical and physical queries. The BI Repository is the metadata using which the server gets the information of the joins and the filters to be used in the query. It is the backbone of the architecture.
Now, this is the place where all the modelling is done and the role of OBIEE developers come into picture . The BI Repository is created using the Administration Tool. The repository contains three layers: Physical, BMM and Presentation Layer.

Physical Layer: Contains the tables imported from the underlying DB with appropriate joins between them.
BMM Layer: This is the Business Model layer and hence all the Business logics are implemented on this layer eg: Calculation of %age Sales, Revenue etc.
Presentation Layer: As the names specifies this layer is used for Presentation of required tables and columns to the users. The columns pulled in this layer are directly visible to the users.
Where BI Server and Admin Tool come in picture???
Now, when the users log into the BI Answers i.e the user interface, they see all the columns that are pulled on the Presentation Layer in the Repository. They choose the desired columns from there and click results button to view the report. After that the request is sent to the BI Server through the Presentation server, the BI server makes use of the BI Repository to formulate a query out of the requested report based on the joins and tables specified in the repository. This query is sent to the underlying DB and hence results are fetched.
4th segment DataSources.
This is a rather simple one as we all know till now that OBIEE is a reporting tool and works on data from underlying Databases, so here DataSources are the underlying Databases with which the OBIEE server interacts. OBIEE is a very smart tool and it has got the capability of reporting on multiple Databases and also multiple types of Databases like XML, Oracle, SQL Server etc.
Now, in the previous posts you have seen what is an OBIEE Repository and what is the Physical Layer and what are connection pools. I am reminding you of these things because our current segment is based on this and we will see how.
Now, when we design the OBIEE Metadata or repository for reporting, we import the tables on which we need to perform reporting into the physical layer from the respective DBs. And then we apply appropriate joins between the tables and furthur pull them to BMM and then to Presentation Layer for reporting.
The question that comes out here is “How does the BI Server interacts with the underlying DBs for showing the reports???”
The answer to this question lies in the Connection Pools. If we open the Connection Pool we can see that we need to select the Call Interface, give the name of the DSN, give a Username and password. These things help up to connect to the Database.
Call Interface – There is a drop down from where we can select the appropriate Call Interface. Some examples are ODBC, OCI etc. Both ODBC and OCI can be used for Oracle. The main difference between using them is, In ODBC we need to create a DSN in the system where the server is installed but OCI is a native DSN and we can use it directly without creating the DSN in the system.
DSN- This is the name of the DSN which OBIEE uses to connect to the underlying DB.
Username- The user with which OBIEE connects the DB. Generally the user used for reporting should only have the read priviledges on the DB.
Password- Password of the user with which OBIEE connects to the DB.
Now, when a user runs the report in Answers the OBIEE server accesses the DB using the connection pool with the specified Call Interface and username and returns the data.
The next question is “How does the BI server takes care of a report formed using columns and tables from multiple DBs???”
As I have told you earlier also that BI server is very intellegent and is built in such a way that it can process request formed form multiple DBs. When the user generates a report involving multiple DBs, the request navigates to the Navigator section in the BI Server which checks the underlying DBs with which OBIEE needs to interact to. Then the BI server generates separate queries for the DBs and fire them on the respective DBs. Then it fetches the data from the underlying DBs and combines the result set in its own memory and displays the result in the report.
With this post we have covered the 4 segments of the OBIEE Architecture. I hope this will help you alot in understanding the BI Architecture and also in understanding the OBIEE behaviour. In the upcoming posts I will also try to go into the details and throw some more light on the BI Server components.

Java Host Server Usage

Sometime back I was under the impression that the Java Host server is only used for displaying Charts,Graphs and all those flashy images, but, after the below incident I found one more usage of the Java Host server.

Today, I had a requirement to create some reports in BI Publisher. When I logged in to OBIEE and tried to access BI Publisher from More Products then I got the below error:

“An error occurred during execution of “connect“. No connection could be made because the target machine actively refused it”

I was amazed when I got this idiotic error as I just did a fresh OBIEE install. Another interesting thing was that I was able to access the BI Publisher Standalone application and was able to login into the application successfully.

When I read the error, it said ‘target machine refused to connect’ which meant the server is shut down but that was not the case as I was able to login in standalone application. So, this thing brought up more confusions.

After all this confusion, I went and checked all the servers and found that except Java Host server all the servers were started. So, just as a trial I started the Java Host Server and to my surprize my problem got resolved.

Siebel CRM Main Modules

Siebel CRM Systems as main player in CRM Industry provides basic modules generally used in the CRM industry. Such modules involves general business process in CRM. Those modules are:

Siebel Sales Module
Siebel CRM Sales Module provides up-to-the-moment, proactive intelligence to maximize sales revenue. With Siebel CRM Sales all levels of the selling organization can access the facts required to confidently pinpoint problems and deploy resources. Siebel CRM Sales allows managers to monitor sales pipelines and evaluate the performance of the entire sales distribution network. Siebel CRM Sales enables sales professionals to identify critical trends in sales cycle length, win rates, discounting, and competitive engagement. This level of visibility is vital to any organization deploying a high-performing sales force.

Siebel Marketing Automation Module
Siebel CRM Marketing Automation Module provides the campaign management, customer management and marketing communications functionality. Users can design and manage outbound campaigns through direct sales, call centers, and channel partners. Siebel CRM Marketing also provides list management capabilities to develop internal lists and load external list files and prospect management with promotion of prospects to contacts. Siebel Marketing's response management enables marketers to track customer responses and evaluate campaign effectiveness.

Siebel Service Module
Siebel CRM Service module enable customer agents interact quickly and consistently across a broad range of communication channels, such as telephone, email, fax, and page. Service representatives become productive faster, supporting a broader range of products and services, resulting in higher satisfaction levels in each customer interaction.

Siebel – Deploying SRF without Server/OM Re-start!!!!

1. Navigate to the Enterprise configuration screen.
2. Click the Component Definition view tab.
3. In the upper Component Definition list, select the component definition you want to reconfigure.
4. Click the menu button and then click Start Reconfiguration.
The Definition State field changes to Reconfiguring.
5. In the lower Component Definitions list, change the Value field of parameters that you want to reconfigure for the component.
In this case, since the SRF name would be the same, we do not have to change the value of the Application Repository File.
6. Stop the object manager.
7. Navigate to the object/enu folder and change the current SRF name to something else. For example, Siebel_bak.srf
8. Copy the new SRF file over.
9. Navigate back to the Component Definitions and commit the new configuration by clicking the menu button and the clicking Commit Reconfiguration.
10. Start the object manager.
Note: When you stop the object manager, all users who will be using the this object manager will be disconnected from this application.
However, if you would like to keep all users active on the object manager and change the SRF file, we recommend giving a new name to the new SRF file.
Here are the steps to change the SRF without disconnecting users from the application and use a different name of the SRF file.
1. Before reconfiguring server component, make sure that any external resources that will be accessed by current tasks running on the existing component configuration remain available. Also make sure that any external resources that will be defined in the new component configuration are available.
Examples of external resources include the SRF and .cfg files that are defined in the component configuration.
2. Navigate to the Enterprise configuration screen.
3. Click the Component Definition view tab.
4. In the upper Component Definition list, select the component definition you want to reconfigure.
5. Click the menu button and then click Start Reconfiguration.
The Definition State field changes to Reconfiguring.
6. In the lower Component Definitions list, change the Value field of parameters that you want to reconfigure for the component.
You can also change the values of fixed parameters, but you cannot change whether parameters are fixed.
Provide the new value for Application Repository File parameters that reflects your new SRF file.
7. After parameter values have been reconfigured, commit the new configuration by clicking the menu button and the clicking Commit Reconfiguration.
The new parameters values will be merged at the enterprise level. To cancel the reconfiguration before it has been committed, click the menu button and then Cancel Reconfiguration.

Siebel Admin – Gateway Name Server

Siebel Admin – Gateway Name Server – An overview

We discussed about the basic Siebel Server Architecture in our previous posts. I will try to elaborate on some of them as per my understanding one by one. I amm trying to detail out the Siebel Gateway Server today.
The first thing we need to understand is that Siebel Gateway Server is a LOGICAL Siebel server, and not a PHYSICAL Siebel server. Its primary purpose is to provide the services of a Name Server. It is for this reason that it is also referred to as a Siebel Gateway Name Server.
This server comes the highest in the hierarchy (there is actually no such thing, but good from understanding point of view), and can contain multiple Siebel Enterprise Servers within it.
A Siebel Gateway Server contains the following information within it:
Definitions & Information about the Siebel Server Component Groups and the Siebel Server Components
Connection Parameters & other connectivity information
It is the connectivity information it contains, which actually links Siebel Servers to the outside world, and allows us to access Siebel by just entering a URL. A Siebel Gateway Server interacts with the Web Server, which receives the actual HTTP requests.
There is an important file by the name of “siebns.dat” which houses all the information discussed above. The availability of various Siebel Components (both vanilla and custom) is saved here. The Server Components who need any resources from some other Server Components, then ask the Name Server for the Availability & Connectivity Information.
Setting up failover clusters is a common way of ensuring high availability Siebel Servers nowadays.

Siebel Jargons

Some of the most common jargon that you would come across in Siebel is given below
Siebel File System:

This refers to the actual hard disk space that is configured at the time of setting up of Siebel Servers. Siebel writes a lot of files on its own, for eg. the Log Files. Siebel Servers will use Siebel File system to store data and the physical files used by Siebel Thin Clients and the Enterprise Servers.

Siebel Database Server:

All data at the end of the day, has to be stored in a Database. In case of Siebel, the backend database may be IBM DB2, Oracle DB, etc. This database may be set up on the same server box as the Siebel Server, however, it is strongly recommended to set it up separately on a separate machine in the Network.
We create a lot of records when working with any CRM system. These may be Account Data, Contacts data, List of Products, etc. All this data is saved in the Siebel Database. All Siebel tables, indexes, seed data, etc. are saved in this Database.

Siebel Application Server:

This is the actual Siebel Application Server which performs the tasks. A Siebel Server Installation is implied to mean a Siebel Application Server Installation.

Siebel Enterprise Server:

This is a logical grouping of the Siebel Application Servers discussed above. An Enterprise Server may have just one Siebel server, but, generally in Production environment, it contains, multiple Siebel Application Servers in the grouping. Lots of components, and their groups are defined at this level in the hierarchy, and control most of the Siebel Server environment.

Siebel Gateway Server:

It generally contains the Siebel Name Server, which is from amongst one of the most important components in Siebel System. This is a logical server which has the grouping of single/multiple Siebel Enterprise Servers. The Gateway Server provides a consistent backing of the Siebel Enterprise Server configuration data. It has the Siebel Connectivity information, and controls connectivity via the Siebel Connection Broker, also called SCBroker.

Siebel Web Server:

This is the Web Server which will receive all requests and forward it to the Siebel Servers, just like in a typical Web Access scenario. This could be IIS on Windows, or Apache, or anything similar.

Siebel Clients:

These are of many types, all with different characteristics – Sample, Dedicated, Thin, Mobile. These are the different clients which access the Siebel Application. I will not dwelve into the details of each one of them here.
The type of client most commontly used is the Siebel Thin Client. In this case, the user accessing the Siebel Application, need not install any component on his local machine. He can just type in the URL of the Siebel Application in his Web Browser, and Siebel Login page pops up. The user may login with his valid credentials, and continue with his processes within the Application.
Siebel does install a few add on components for the Web Browser on its own. However, if the user has Admin rights on the machine, most of this stuff will be automated. In case the user is not the Administrator of the machine, some of the components may not install properly, leading to a hampered navigation in the Application.
The above is a simple outline, which can vary greatly with each environment, its requirements and limitations. Especially, when it comes to clustered, failover, high availability systems, and all, things begin to get complicated.
I will try to cover each one of these in more detail in further posts.

Siebel Request Flow

I will approach Siebel Architecture in a different way. Then I will take each technical term used in this article that is important and requires further exploration and explain it further in next articles of Back to Basics series.Ever wondered what happens once you have put the URL of your siebel Application in the browser and hit enter?

This is different approach to Siebel Architecture. The answer to this question will be an explaination of Siebel Architechture. So, Let’s start.==> You have opened your browser window and have enterned the URL and Clicked Go button of your browser window
http://yourseiebelapp/apptype_lang/start.swe
Before going into background I would like to explain or dissect the above given URL.
http : Is the protocol that is being used to transfer the data over web from one computer to another.
yoursiebelapp : is the host name of the Web Server on which your Siebel Component resides. We will go into details of these components later
apptype_lang can be divided into two parts
apptype : Represents the module you are using can be sales, callcenter, mkt etc.
lang : Represents the language of your implementation can be enu, fin etc.
start.swe : It might be used or might not be used but represents a command recoganized by siebel component called ‘SWSE’ which stands for Siebel WebServer Extensions.
Now we know the meaning of the URL we have just entered we will move behind the scenes.
==> The Request goes to the Webserver (Discussing Webserver is out of scope for this post) where an important component resides called Siebel Webserver Extensions (SWSE).

SWSE :
The responsibility of this component is to identify if the request that has arrived on webserver is a Siebel request or not and also it helps to format the html pages that are server to the Web Clients of siebel. It also supports Load balancing if you have more than one siebel server which generally is the case.
==> If the request received is a siebel request then SWSE contacts Siebel Gateway Name Server to obtain information about Siebel Servers and Siebel Enterprise Server.

Siebel Gateway Name Server (SGNS):
SGNS can be considered as Sieber Server contact information storehouse for all the siebel servers. It serves as the dynamic address registry for Siebel Servers and components. At start up, a Siebel Server within the Siebel Enterprise Server stores its network address in the Gateway Name Servers nonpersistent address registry.
It also has a important file called siebns.dat containg information of Siebel Servers such as
1. Operational parameters
2. Connectivity information
3. Definitions and assignments of component groups and components
Siebel Enterprise Server (SES) :
SES is not a physical server it is just a logical entity in simple terms SES is a logical grouping on serveral siebel servers such as Siebel Server shaing one database can part of SES.
The Siebel Servers in a Siebel Enterprise Server are configured, managed, and monitored as a single logical group which helps the Siebel Administrator to start, stop, monitor, or set server parameters for all Siebel Servers within the Siebel Enterprise Server.
==> Once the SWSE gets information about Siebel Server it forwards the request to the Siebel Server on Round Robin basis due its load balancing feature.
Siebel Server (SS) :
Siebel Server is the system on which Siebel Server Components are installed and it functions as Application server. Each server component performs a defined function.Server components or groups of components determine what applications and services a Siebel Server supports. The Siebel Server runs as a system service under Windows and a process under UNIX. This system service or process monitors and controls the state of all server components on that Siebel Server. Each Siebel Server is one instantiation of the Siebel Server system service or process within the current Siebel Enterprise Server.
==> Once the request is received by siebel server it is passed to a component called Application Object Manager (AOM)
Application Object Manager (AOM) :
One of the most important types of server components is the Application Object Manager (AOM).They process user requests and are application or service-specific. For example A Sales Application will have Sales AOM and Call center application will have a Call Center AOM.This Application Object Manager provides the session environment in which this application runs. When an AOM receives a user request to start an application, it does the following:
==> The business object layer starts an application user session, processes any required business logic, and sends a data request to the data manager.
Data Manager (DM) :
Data Manager is that another component that is a part of AOM. Its primary function is to receive user request create corresponding SQL and Forward it to database Server. It also receives results from Database server and forwards it to Siebel Business Object Layer for additional processing.
==> Siebel Business Object Layer forwards the results to Siebel Web Engine (SWE) another component residing in AOM.
==> SWE helps create UI for the data and forwards the web pages to the SWSE Component which resides on Web Server.
==> Webserver then sends back the results to the users who had intially requested it.