Siebel eRoadmap Methodology 1
Siebel’s eRoadmap Methodology to implement each one of its implementation phases. Siebel eRoadmap provides a six-stage framework for implementing Siebel eBusiness Applications. The stages are,
Project Definition:
The project team assembles or collects, defines the project approach and scope, and implements project management controls.
Discovery:
The project team refines or filters and documents functional and technical requirements that support the business goals.
Design:
The project team designs a hard-copy mock-up of the solution and uses the discovery stage requirements to develop application screen flows and design layouts.
Configuration:
The project team configures the application, extensions, and external interfaces required to support the new system.
Validation:
The project team conducts a full-function test, including a user acceptance test of the application using production data.
Deployment:
The project team first conducts a Production Pilot that field tests and revises all aspects of the new system, user training, technical infrastructure, the network, and the help desk. The team then focuses on a successful transition from the production pilot to a full rollout.
Difference between Siebel 6.0 and Siebel 7.0
1) In Siebel 6.0, you have got many tables namely S_ORG_EXT, S_OPTY, S_CONTACT, etc.
2) In Siebel 7.0 you have got a table named S_PARTY that is the main reference table & it stores the references to other tables namely S_BU, S_ORG_EXT, S_CONTACT, etc.
3) In addition to S_PARTY we have other independent tables like S_OPTY, S_EVT_ACT, etc.
4) The tables such as S_EMPLOYEE, S_ORG_INT, etc have become obsolete.
5) Most of the Person related data is stored in S_CONTACT as the main table in addition to S_EMP_PER, etc.
6) Most of the Organization related data is stored in S_ORG_EXT.
7) In Siebel 7.0 you have the option of compiling a single Object such as an Applet, BC, etc or an entire Project as per the requirements; whereas in Siebel 6.0 you have to compile a Project each time even for minor changes.
8) There are also a lot of differences in terms of Scripting like Client Side & Server Side Scripting in Siebel 7.0 compared to only Server side scripting in Siebel 6.0.
2) In Siebel 7.0 you have got a table named S_PARTY that is the main reference table & it stores the references to other tables namely S_BU, S_ORG_EXT, S_CONTACT, etc.
3) In addition to S_PARTY we have other independent tables like S_OPTY, S_EVT_ACT, etc.
4) The tables such as S_EMPLOYEE, S_ORG_INT, etc have become obsolete.
5) Most of the Person related data is stored in S_CONTACT as the main table in addition to S_EMP_PER, etc.
6) Most of the Organization related data is stored in S_ORG_EXT.
7) In Siebel 7.0 you have the option of compiling a single Object such as an Applet, BC, etc or an entire Project as per the requirements; whereas in Siebel 6.0 you have to compile a Project each time even for minor changes.
8) There are also a lot of differences in terms of Scripting like Client Side & Server Side Scripting in Siebel 7.0 compared to only Server side scripting in Siebel 6.0.
Siebel Data Model:
Physical User Interface Layer:
This layer contains Siebel Web template files that control the style and structure of the user interface.
Logical User Interface Layer:
Object definitions in this layer are the visual representation of objects in the Business Objects Layer. They define the interface presented to the user at run-time, and allow users to manipulate data. Examples of user interface objects include applets, views, and controls, such as buttons and check boxes. User interface objects also define the information that associates objects in the repository with the Siebel Web templates.
Business Objects Layer:
Object definitions in this layer describe individual business entities (such as Accounts, Contacts, or Activities) and the logical groupings and relationships among these entities. Business objects are based on data object definitions.
Data Objects Layer:
Object definitions in this layer provide a logical representation of the underlying physical database. For example, object definitions such as table, column, and index describe the physical database. These object definitions are independent of the installed RDBMS.
DBMS:
The third-party database management system manages the Data Objects Layer. It is not a part of the Siebel eBusiness Applications.
Each layer of the Siebel object model contains several principal object types. Most of these object types contain child objects that further define the given object type.
Siebel Architecture
Client Types
Siebel provides five client types. The three major client types are,
1. Siebel Web Client
2. Siebel Mobile Client
3. Siebel Dedicated Web Client
The other two are,
4. Siebel Wireless Web Client
5. Siebel Handheld Web
n Access to Siebel data differs based on client type
} Web and Wireless Web Clients connect through the Web server
} Handheld and Mobile Web Clients connect through the Siebel Server
} Dedicated Web Client connects directly to the Siebel database
Siebel Web Clients:
Siebel Web Client Accesses the Siebel Gateway and Siebel Server through the Web Server running SWSE.
Web Clients Accesses Siebel data through AOM.
SWSE (eapps.cfg) parameters identify AOM.
AOM component parameters specify Enterprise Server, Siebel Server, .cfg, and .srf that the Siebel Web Client uses.
Web Server:
Web Server Identifies and passes Siebel requests from Siebel Web Clients to the Siebel Servers
Web Server Consists of a third-party Web server with the following additional Siebel components:
Virtual directories
Siebel Web Server Extensions (SWSE)
Configuration file (CFG)
Virtual directories:
Virtual Directories Exists on the Web server to receive inbound Siebel Web Client requests for each installed Siebel application, and forwards these requests to SWSE
Siebel Web Server Extension (SWSE)
n Receives and parses inbound HTTP requests from Siebel Web Clients
n Creates and manages TCP connections to the Siebel Servers or Load Balancer (if implemented)
Eapps.cfg
n Contains configuration information, including connectivity information, login, and security settings.
Siebel Gateway Name Server
[It provides to access and availability Siebel servers that are Name Server and Connection Broker]
Siebel Gateway Name Server dynamically registers Siebel Server and component availability.
Stores component definitions and assignments, operational parameters, and connectivity information.
Stored in siebns.dat file located in \\sea77\gtwysrvr\ADMIN
Siebel Server 7.7 supports two methods of Siebel Server load balancing:
} Software-based, Siebel load balancing (built into the SWSE)
} Certified, third-party, hardware- and software-based HTTP load balancers
[Group of Siebel Servers that connects to same database server]
Enterprise Server is a logical collection of Siebel Servers that support users accessing a single database server and a single file system.
n Logically groups Siebel Servers for common administration via Siebel Server Manager
n Supports sharing of common configuration information
n It execute tasks to manage the business data
} Interactive processing (for example: supports the Siebel Web Client running Siebel Call Center
} Background processing (for example: workflow and business process automation)
} Batch processing (for example: volume data importing)
Siebel Server Architecture
Siebel Server Architecture Consists of the following entities:
1. Siebel Server
2. Siebel Repository File (SRF)
3. Configuration File (CFG) and Component Parameters
4. Siebel Web Templates (SWT)
5. Server Components
a. Group Siebel servers that access the same database server.
b. Siebel Server is the platform that supports interactive, batch, and background processing for all Siebel clients
c. Siebel Server controls server components running on a machine
Siebel Repository File (SRF)
n Siebel Repository File separate binary file that defines one or more Siebel applications
n Specifies the:
} Data presentation
} Business rules and processes
} Data organization and storage
Siebel Configuration File (CFG) and Component Parameters
Cfg file specify initialization settings of the application at run time, for example:
} Application parameters
} Security settings
} Siebel Gateway Name Server
} Enterprise
Siebel Web Templates (SWT)
Web Template is a layout which formatting elements in the User Interface such as views, applets and controls
Server Components
n Is a program that executes on a Siebel Server
n Performs a specific function or job
n Examples include:
} Importing and exporting data
} Configuring the database to monitor for user-defined conditions
} Processing of client requests
Examples:
• Application Object Manager
• File System Manager
• Synchronization Manager
• Assignment Manager
• Enterprise
Database Server
n Stores data used by Siebel applications in a predefined database schema
n Supports a variety of third-party relational database management systems (RDBMS).
Siebel File System
It is a shared directory that stores compressed files used by Siebel applications.
S_PARTY:
It is the base table for all party business components and it Stores the party name and party type.
It has multiple extension tables that store the business data for the party business components.
Party Business Components
n It Represent a variety of people and organizational entities
} Person-related entities
} Organization-related entities
} Groupings created for access to master data
Considerations for Joining Party Data
n Implicit joins
} Map fields in party extension tables to party business components
n Explicit joins
} Bring party data into a non-party business component
} Bring party data into another party business componen
We have non party entities also that are
1. Opportunities
2. Activities
Siebel Tools.
Siebel Tools is an integrated development environment for configuring aspects of a Siebel application, including elements in the data objects, business objects, and user interface objects layers. Siebel scripting languages are also managed in the Siebel Tools environment.
Siebel Tools configurations and scripting play a critical role in the performance and scalability of a configured Siebel application. Customizations made through Siebel Tools partly determine the degree to which performance and scalability of a particular deployment differs from the original installation.
Appropriate configuration optimizes operations in the Siebel Database and does not add unnecessary overhead to supporting user sessions. (Siebel Tools itself does not play a role in the Siebel applications at run-time.)
Checking Out Projects from the Server 3
You typically do your configuration work in a local database, checking out object definitions (projects) from the development server as needed.
To check out a project
1. In Siebel Tools, choose Tools > Check Out.
The Check Out dialog box appears.
2. Make sure the correct repository is selected.
The default value is Siebel Repository.
3. Select the project or projects whose objects you want to check out.
4. Click the Options button.
The Development Tools Options window appears, with the Check In/Out tab
selected.
5. In the Development Tools Options window, make sure the Server and Client data sources are specified correctly.
6. Close the Development Tools Options window.
The Check Out dialog box appears.
7. In the Check Out dialog box, click Check Out.
The process of copying projects from the server database to your local database is known as performing a get. The get process differs from checking out in the following ways:
- Getting projects does not lock them on the server database.
- Getting projects overrides all the projects on your local database, whether they are locked or not locked.
To perform a full get
6. In the Development Tools Options window, make sure your Server Data Source is pointing to your server development database and your Client Data Source is pointing to the local database you previously initialized and are currently running against.
Checking In Projects 3
After you confirm completion of your configuration changes, you need to check the project back into the development server. Here are some guidelines for checking in projects:
■ Test objects before you check them in.
■ Validate projects using the Validate button in the Check-In dialog box.
■ Check in all dependent projects at the same time to make sure the configuration on the server remains consistent.
■ Keep in mind that the work of other developers may depend on the objects you are configuring. In some cases, this may require you to check in projects before your work is complete because other developers may be dependent on a feature you have added to your project.
To check in changes
1. Choose Tools > Check In.
The Check In dialog box appears.
2. Click the Options button.
The Development Tools Options dialog box appears.
3. As you did during check-out, make sure the server and client Data Sources are pointing to the correct databases.
4. Close the Development Tools Options dialog box.
5. Select the Locked/New Projects radio button.
6. Click Check In.
Compiling Projects
After you’ve made your configuration changes, you must compile them into a Siebel repository file. Until you do so, your Mobile Web Client application that reads the repository file, will not reflect the changes you’ve made.
There are various options for compiling the repository. You can compile at the project level—selected projects, all locked projects, all projects—or you can compile individual objects. Compiling individual objects is faster, but you must remember to do it for each object you modify.
To compile projects
1. Exit Web client applications that are running on the .srf file to which you want
to compile.
While running, a client application maintains a lock on the .srf file.
2. In Siebel Tools, choose Tools > Compile Projects.
The Object Compiler window appears.
3. In the Object Compiler window, select whether you want to compile selected projects, locked projects, or all projects.
Compiling only the locked projects (those currently checked out) is faster than compiling all projects. Compiling locked projects is also often easier than selecting individual projects from the list.
4 In the Object Compiler window, click the Browse button to select the .srf file you want to compile.
The .srf file for your application is in the objects subdirectory of your Siebel application client directory. For example, a typical path is to the Mobile Web client installed for testing on a developer’s machine is:
■ D:\sea702\client\OBJECTS\siebel.srf
5. Click the Compile button in the Object Explorer window.
After compilation is successful, the .srf file you specified contains all the configuration changes you made.
To compile individual objects
1. In the Object Explorer, select the object type you want to compile.
You can only select top level objects such as, applets, views, business components, or business objects. You cannot compile child-level objects.
2. In the Object List Editor, select the object or objects you want to compile.
The objects can belong to different projects.
3. Right-click the mouse and choose Compile.
The Compile dialog box appears.
4. In the Compile dialog box, select the repository file (.srf) to which you want to direct your changes.
5. Click Compile.
After compilation is successful, the .srf file you specified contains all the configuration changes that you made.
No comments:
Post a Comment