Module Overview
Welcome to Technical Architecture Overview
This module discusses the major concepts related with Technical Architecture and provides a brief overview of Technical Architecture in Siebel 7
This module will accomplish the following:
Describe Siebel 7.0 Technical Architecture Schematic
Discuss Siebel 7.0 Technical Architecture Components
Explain Siebel 7.0 Application Server Components
Technical Architecture is the set of products, tools, standards, procedures, and documentation that support and constrain the development and operation of a business application.
You need a Technical Architecture in order to develop more efficiently and effectively. To reduce the maintenance effort, to enhance availability/performance and to provide robust security
This presentation will cover the main components of a Siebel Technical Architecture. It will overview these main architecture components and then discuss several of the Siebel specific Server components that are typically implemented.
The Siebel Application Architecture leverages existing Internet, security, application, management, and middleware infrastructure in the implementing new front office solutions
Siebel fits into customer’s overall environment. It is continually adding features to improve the Siebel Application Architecture by supporting more platforms, interfaces and standards. Integration with J2EE is an example.
Distributed transactions. Siebel doesn’t function as a transaction monitor, instead it distributes transactions. Our recommendation is, if you have an update that affects multiple back-end systems. You should update synchronously, or use a store and forward. Websphere/Weblogic can then control transaction.
One of the key fundamental aspects of the Siebel eBusiness architecture is the underlying levels of abstraction in the application.
If we start at the bottom and work our way up we have the physical storage. Physical storage in the Siebel environment is in a relational database whether that be IBM's DB2 UDB, Oracle or Microsoft SQL Server.
On top of the database is a data abstraction layer where Siebel defines a set of data objects which is used by the other components in the system.
The data objects layer in the Siebel eBusiness Platform dynamically generates SQL and eliminates the need for application developers to understand the SQL programming language.
Built on top of the data objects layer is the Siebel Business Objects Layer. This is the layer in which business objects are defined along with the corresponding business logic as well as business process definition.
Sitting on top of the Business Objects Layer there is the UI Layer. The UI Layer is divided into two separate layers; logical user interface and on top of that there's the physical user interface.
The logical user interface defines a common way to represent information in terms of screens or pages, the applets that go on that page, not to be confused with Java applets, but applets in such as list applets, form controls, tree controls or charts. The physical rendering then dictates how that information gets actually displayed on a device, whether this is HTML, whether it is WML for a wireless device, or whether it is XML which could then be transformed into different presentation technology.
Objects in each layer depend on the definitions of the objects in the layers below. And objects in each layer are insulated from each other. Changes in one layer require little or no changes in the layers below. For example, you can change the color and other style characteristics of the user interface by simply modifying the Web templates and style sheets. Or you can control how data is presented, by modifying objects in the logical user interface layer, without having to modify business logic. Web templates and style sheets are modified using a text editor or a raw code HTML editor. Siebel object definitions are modified using Siebel Tools.
If we take the diagram in the previous slide and turn it on its side, we're now going to focus on some of the key objects in the Siebel eBusiness Architecture.
At the logical UI layer there is what is called Siebel screens. A screen is a set of related pages in an application. Screens are made up of views.
A Siebel view is the equivalent to a single HTML page. Views are made up of applets, and these are Siebel applets not Java applets, and the applets contain controls.
At the business logic layer we have business objects. Business objects are then made up of business components and components are made up of component fields.
The way to think about the relationship between business objects and business components is that business objects are an aggregator of business components. All the data in Siebel is stored at the business component level. Business components can be shared across a number of business objects and can be used across multiple applications. A Siebel business object is really the holder of a shared foreign key which unifies all of the related business components.
At the data object level there is an object entitled the data source which determines which physical repository the information is stored in. A data source then contains database tables and the relationships between those tables, and contains database columns.
If we then look at the relationships across the layers, a screen is associated with a business object. Applets are associated with a business component, and controls are related to a component field. Business components are then in turn related to a data source and a set of database tables, and component fields are related to a database column.
Other objects which I want to mention at this point include Siebel Business services which provide the way to write a custom code module much like a UNIX daemon or NT service or perhaps a session bean in J2EE that operates in the context of the Siebel Object Manager. Siebel provides a number of its components written as Siebel businesses services including workflow, the pricing configurator engine, and the Siebel Web engine.
An integration object is a special type of object that's designed for interacting with external systems and represents a subset of a given business object. A business object could typically contain 20 to 30 business components, and each business component in turn could contain 20 or 30 fields. An integration object allows the developer to define a subset of a business object for the purposes of communicating with a specific external application or participating in a specific business process. Integration objects also allow the XML representation of that data to be specified. Integration objects can be customized to determine which fields represent XML elements and which fields represent XML attributes. All of these objects are grouped together into an application, and all of this information is stored in the Siebel repository. These objects are all defined and maintained using Siebel Tools, which is an integrated toolset that covers both data definition, business object definition and user interface definition.
Siebel Web page production or the physical UI layer is done by using HTML templates.
Templates are HTML files that contain special Siebel tags and optionally JavaScript.
Siebel templates are associated with Siebel views and with Siebel applets. When the Siebel Web Engine goes to render a Web page it essentially looks to determine what view the application is being requested to display. And then from that information it determines what template is associated with the view, and then also what applets are contained on that view, then determines which applet templates to be used to render the HTML.
Let me start off by explaining the Siebel Web Architecture as it forms the basis of all our further discussion.
The Siebel Web architecture consists of a Web Client which is primarily a browser, the extended Siebel Web Server, the Gateway Server, one or more Siebel Servers, and the Siebel Database server.
The Web client connects to an industry standard Web Server to display the Siebel application.
The Web Server Extension plugs into the Web servers and handles all communication between the Web client and the Application Server.
Finally on the Web Server is the Siebel Image Cache. This cache is a new component in Siebel 7 and is designed to reduce the load on the Siebel Server by publishing images up to the Web server and allowing the Web server to handle requests for those images directly.
Sitting underneath the Web server is the Gateway Server. The Gateway Server acts as a name server for the Siebel Enterprise server components. If Resonate Central Management is deployed, the Gateway Server also provides load-balancing services.
The Enterprise Server is a virtual grouping of all of the different machines and components which execute in the middle tier environment to support a Siebel application. There can only be one Enterprise Server per database instance. The Enterprise Server can also contain multiple components on the same physical machine.
A Siebel Server is an abstraction for a given machine running Siebel components.
Inside of a Siebel Server there are a number of server components. There are a minimum set of components such as the Server Manager, the Server Object Manager, Server Request Processor and File System Manager that are required to be running.
Depending on the implementation, there are additional components such as Workflow Manager, Assignment Manager and Synchronization Manager, which may also be running. The Siebel Server processes all requests from the Siebel Web clients as well as from other eBusiness applications and support batch operations.
The Siebel Server interacts with a third party RDBMS on the Siebel Database Server. The Database Server provides data to the Siebel Servers upon request.
The Siebel Enterprise Server can be managed directly by the Siebel Server Manager. The Siebel Server Manager is an administrative console for IT professionals to manage the configuration and runtime environment of the Enterprise Server and the Siebel Servers which it contains. It is essentially a standard Siebel client with access to server management views. The Enterprise Server can also be managed directly on the server using command line utilities.
Lets look into the architecture in more detail.
In the Siebel architecture, no components are hosted on the client. The client interacts through a Web browser. The user accesses a specified URL which navigates to a Web-server hosted application. This Web server application is, in turn, supplied with HTML pages generated by the Siebel Web Engine service in the object manager. A Siebel plug-in (one for Microsoft Web server software, and one for Netscape) runs on the Web server, and interfaces with the Siebel Web Engine component in the object manager. Most of the work takes place in the Siebel Web Engine; the Web server plug-in maintains the session and functions as a communication intermediary.
Putting this all together, here’s what happens when a user enters a URL on the Web browser:
The Siebel Web Server recognizes that the URL contains a Siebel request and passes it to the Siebel Web Engine.
The Siebel Web Engine retrieves the appropriate template files to construct the HTML page and requests the retrieved data from the Object Manager.
Finally, the Siebel Web Engine builds the HTML page with data and template tags which is passed via the Web server to the browser.
The SRF file is a critical system file which is a binary representation of the repository data.
Siebel 7 supports a number of different access devices for supporting different
channels.
Wireless Web client for running WML browsers on a cell phone and accessing the application using the WAP wireless protocol.
Traditional Web browsers running the Web client such as Microsoft's Internet Explorer or Netscape's browser, support the mobile Web client for running in a disconnected mode on a laptop or PDA in which the user interface, business logic, and data storage are all on the device.
Dedicated Web client running on a workstation where the business logic and user interface are on the workstation and the data is accessed on a centralized server is supported.
Interacting with Siebel eBusiness Applications using a voice interaction technology, which allows you to call up on a phone to access information such as contacts in your calendar is supported.
Interacting with the data in an eBusiness application using email is also available. One can send a structured email message to the Siebel eBusiness Platform to get information and have that information returned to them in the form of an email message.
Siebel Call Center also supports interacting with customers sending unstructured email requests by facilitating the response to those in their email response component.
Siebel eBusiness Platform also interacts with other technologies and applications using the Enterprise Application Integration or EAI framework.
If we look at each of these in a little more detail, the wireless Web client is supported by using a WAP Gateway Server which can sit either at a Telco providing the wireless access or within the enterprise. The WAP Gateway Server translates the request from a WAP request into an HTTP request which is then processed by a standard Web server running the Siebel Web Server Extension. The Web client uses standard browser technologies to interface with a Web server. An example would be notebook or workstation with a dedicated LAN connection.
For the mobile Web client, the Web browser, the Object Manager, and the data manager, as well as a data storage mechanism, such as a local database like SQL Anywhere, are running out on the client machine. An example would be a notebook with a dial-up network connection.
And then the dedicated Web client. We have the Web browser, Object Manager and the data manager running out on the workstation device accessing the Web server. An example would be a workstation with a dedicated LAN connection.
If a client has both dial-up and network connectivity, it can behave in both mobile and connected modes.
The Siebel 7 Architecture is made up of the Technical Architecture Schematic, Technical Architecture Components, and Siebel Application Server Components.
Now we’ll discuss the Technical Architecture Components.
Client Web browsers connect to Web servers to display Siebel Web Client applications.
The Siebel Web server identifies and passes client requests to the Siebel Server.
The Siebel Web server also passes completed HTML application pages back to the browser.
Messages between the Web Server and the Siebel Server can be compressed. Type of compression for network communications - NONE or PKWARE.
Messages between the Web Server and the Siebel Server can be encrypted. Type of encryption for network communications - NONE or MSCrypto.
Image cache is a new component. To allow parallel requests for images, once an image is requested the Server extension caches the image in the web server, the web server then accesses the image directly.
Normal configuration for the Web server is an outer firewall with Port 80 and SSL, inner fire has SISNAPI port open. For situations where web server is in a different facility in enterprise server, you would use a VPN connection. HTTP tunneling is not supported between server extensions and the OM.
The Gateway Server is a logical entity that provides both the Name Server and Connection Brokering functions.
It serves as a single entry point for accessing the Siebel Servers.
With Resonate, the Gateway Server provides enhanced scalability, load balancing, and high availability.
The Gateway Server can have one or more Enterprise Servers assigned to it.
Only one Gateway Server can be installed on a physical machine. It can control Enterprise and Siebel Servers on other separate physical machines.
Typically, we will setup one Gateway for all development environments and another unique Gateway for the execution environment.
All parameters are stored in a binary file called siebns.dat.
Siebel Bookshelf has additional information in the ‘Server Administration Guide’ 1-4
*Note, the pages referenced are based on the 7.0 bookshelf, but there are several versions so please use your specific manuals wisely.
Enterprise Server is a virtual entity; It has not physical components other than some parameters registered within the Gateway server.
It is installed as part of the first Siebel Application Server installation.
It only has to be configured once; if a new Siebel Application Server is built for an existing Enterprise, it is told to point to that Enterprise.
Altering the configuration for an Enterprise Server is accomplished through changing the parameters set within the Gateway Server.
You typically build one Enterprise Server for each database schema/table owner. It has parameters like:
Database Alias
Table/Schema Owner
File Server
Default Admin Database/Application User Account
Siebel Bookshelf has additional information in the ‘Server Administration Guide’ 1-7
This is a diagram showing the Siebel Application Server Architecture. We will be discussing this in the following slides
Several Siebel Application Servers can be installed on one physical server (usually done for the development environment; one for each of build, test, training, etc). At least one Siebel Application Server is required for each Enterprise Server. Typically install individual Siebel Application Servers for the same Enterprise Server on separate physical boxes.
The Siebel Server is a middle-tier platform that supports both back-end and interactive processes for all Siebel clients. These processes perform business functions such as: Routing data for Mobile Clients, assignment of leads based on territories, and interfacing with data from legacy systems. These processes can be spread across many Siebel Servers to enhance performance. In the Siebel architecture, these processes are referred to as components.
Siebel Application Server Components are available to meet business needs. Multiple modes of operation are available (Interactive, Request based, or Batch). Components can be operated as either processes or threads. Below is a list of some of the available components:
Assignment Manager—Data assignment engine
Enterprise Integration Manager—Batch database data loading utility
Object Manager—Siebel Application Object Managers host the Business Objects layer and Data Objects layer of the Siebel architecture. The Web clients host the Siebel application user interface layer. The Siebel Application Object Manager is used primarily to support Siebel Web client connections.
Workflow Manager — Automates business workflow process
Remote Manager — Group of components that merge, route, and prepare the transactions for the Siebel Remote Clients.
Replication Manager— Synchronizes Node databases with the HQ database
The Siebel Database Server contains the business data in a set of predefined tables on a third-party relational database management system. It provides data to the Siebel Servers and the Siebel Web Clients upon request.
The Siebel database server is a relational database. Tables in this database store information on organization structure, job responsibilities, sales personnel, sales territories, accounts, opportunities, and product lines. Business logic is stored at the application level. The architecture design of the database allows for high performance, scalability, and maintainability.
A DBA is required to build the database instance (independent of Siebel) and create several administrative database users, before any specific Siebel database components are created within that database.
DBMS-specific indexing schemes: The Release 7.0 system takes advantage of specific optimizer mechanisms in the various supported database management systems.
The File Server is a directory structure that stores physical files used by Siebel clients. These files consist of correspondence templates, encyclopedia items, file attachments, literature, and other files for client access and downloads.
A File Server is required for each Enterprise Server. Multiple File Servers can reside on the same physical server. Siebel will create the actual files that reside in this directory. They are compressed by Siebel.The File Server has to remain in sync with its corresponding database, since the Siebel created files correspond to actual database records.
In Siebel 7, the client no longer has direct read / write access to the File System. A new component called the File System Manager that runs on the Siebel Server controls the read/write access to the files.
The Server Manager connects to a Gateway Server, which provides the status of all the Enterprise and Application Servers beneath it (Gateway Server). The Server Manager can be accessed through two possible interfaces; GUI or command-line. Both options basically allow the user to manipulate the various parameters registered within the Gateway Server.
The GUI based option runs as part of the Connected Client. Even though it runs through the Connected Client, it is not accessing the Database Server (since it talks to the Gateway Server).
The Command-Line interface runs in a DOS shell (on NT). The executable is found in the Siebel Application Server install directory. In a UNIX environment, all Server Manager commands are executed using the command-line interface.
The Siebel 7 Architecture is made up of the Technical Architecture Schematic, Technical Architecture Components, and Siebel Application Server Components.
Now we’ll discuss the Application Server Components.
To use a software component, it must first be enabled in the Enterprise Configuration. Here are some details on the various software components:
Assignment Manager is the tool used to assign a Siebel Position (or Employee) to an Entity that has a Siebel Team (i.e. Account, Opportunity, Contact). The assignment is based on rules that are built within the application by an administrator.
An Assignment policy is triggered when a specific event occurs. This event can be configured, if it does not already exist in the vanilla code. An example of a rule is; Assign a particular position to a any account that has an address with zipcode 12345. The triggering event would be creation of an address for this account with the zipcode of 12345.
There are several ways to run assignment manager:
Batch - This will run through all records in a specific entity and check if they fall into any particular rule, then execute the rule they fall into. You have to run Batch assignment the first time you ever run Assignment Manager (or add a new rule)
Dynamic - This will automatically run assignment manager, whenever a triggering event occurs. The triggering event is caught by database triggers created by assignment manager. The triggering events are stored in a ‘log’ table (S_PROC_REQ) and removed once Assignment Manager has processed them.
Interactive - This is where a user can start assignment manager manually, for a particular record. This function has to be enabled in the GUI for users.
EIM is Siebel’s batch data loading tool. It is always used to load the initial set of client specific data into a Siebel database. It is also used for on-going batch interfaces with legacy or other applications that only require batch interfaces.
EIM uses a special set of staging tables, called Interface Tables. These are de-normalized tables that map to several normalized base tables. The mapping of these interface tables to base tables is fixed by Siebel out-of-the-box. It is not possible to alter these mappings, but it is possible to create new mappings for new columns created by the developers.
EIM works by mapping Unique Keys for a base table record to the Unique Key loaded into the proper columns (that reference that base table) in a given Interface Table.
EIM is executed as a Server Task and is controlled by an IFB file.
Siebel Application Object Managers host the Business Objects layer and Data Objects layer of the Siebel architecture.
The Web clients host the Siebel application user interface layer.
The Siebel Application Object Manager is used primarily to support Siebel Web client connections. To do this, the Application Object Manager operates like a Siebel Dedicated Web Client with two key differences: it does not require any software installation on the client machine and it handles multiple users simultaneously by making requests on their behalf.
There can be several Object Managers running concurrently on one Siebel Application Server. Each Object Manager can support several active ‘user’ connections at a time.
Each Object Manager references a CFG file, that provides information about where it will connect to and the SRF file that it should be using to access the business code.
The Object Manager is the process that Resonate can load balance through the Gateway Server.
Siebel Remote is the name given to the various processes that enable a Mobile Client and the server database to remain in sync, so that business data is continually shared.
There are both server-side and client-side processes that work together to successfully enable Siebel Remote.
Siebel Bookshelf has additional information in the ‘Remote and Replication Manager’ Part 1
This process is very similar to Siebel Remote. It actually shares several of the components that will be discussed as part of Siebel Remote. Replication Manager is part of the discussion on Regional Databases that will be covered in a later presentation.
Siebel Bookshelf has additional information in the ‘Remote and Replication Manager’ Part 2
This utility runs through the Siebel application software loaded on a user’s PC. No additional software has to be loaded to make it function. It uses the Siebel Remote and the Siebel File Server architectures to operate.
Only functioning Siebel clients can receive Siebel Anywhere upgrades.
Siebel Anywhere allows the Siebel System Administrator to apply upgrades to dedicated Web clients, mobile Web clients, and Siebel Servers. Upgrades can include custom configuration, new versions of Siebel eBusiness Applications (as licensed), customer extensions to the database schema, custom files, or third-party files or applications.
Siebel Anywhere uses pull-based technology for retrieving upgrade kits. There are two server components and one executable for the creation and installation of Siebel Anywhere upgrade kits.
Siebel Bookshelf has additional information in the ‘Siebel Anywhere Administration Guide’
Now that you have completed this module, you should be able to explain:
Siebel 7.0 Technical Architecture Schematic
Siebel 7.0 Technical Architecture Components
Siebel 7.0 Application Server Components
