Siebel 开发规范

Siebel Configuration and Development Guideline

1

2

2.1

2.2

2.3

11.

2.4

2.5

3

3.1

3.2

3.2.1

3.2.2

3.3

3.4

3.4.1

3.4.2

3.4.3

3.5

3.5.1

3.5.2

3.5.3

3.5.4

3.5.5

3.6

3.7

4

5

5.1

5.2

5.3

5.4

6

7

7.1

7.2

7.3

8

1       Objectives

The intent of this document is to provide a guide to developers toset
standards for designing the graphical user interface as well as
theunderlying logic driving the Siebel application.  The standards
document provides a tool thataids new developers with
understanding the configuration team’s developmentapproach.  This
effectively decreases theamount of time needed for new developers to
become familiar with the currentdevelopment process and ensures that the
application maintains a consistent‘look and feel’. 
The intent of thisdocument is to ensure that any configurations
performed:

·        are accurate

·        provide an intuitive userinterface

·        are easy to maintain andupgrade

·        and, maintain optimumperformance of the RCM Application

This document is a collection of suggestions for
developmentprocedures and standards specific to Siebel application
development.  The document is not intended to give step bystep
instructions on how to perform specific configurations.

Thefollowing abbreviations are used throughout this document:

MVF	Multi-Value Field	BO	Business Object
MVG	Multi-Value Group	BC	Business Component
MVL	Multi-Value Link	OBLE	Object List Editor
SRF	Siebel Repository File	OE	Object Editor
CFG	Configuration File	CDM	Conceptual Data Model
UI	User Interface	VWT	View Web Template
AWT	Applet Web Template	VWTI	View Web Template Item
AWTI	Applet Web Template Item

2     ApplicationDevelopment and Customization
Guidelines

2.1       Pointsto Ponder

a.   Keep it simple.  Always take the time up front
tolook at different options to implement a solution.  The first solution
is not necessarily thebest or the most efficient.  If itrequires
significant configuration, take a step back and
consider doing it adifferent way.

b.   Keep it vanilla.  Always make an effort to
keepthe application as vanilla as possible and to leverage
vanillafunctionality.  Read the documentation onthe module and any
applicable Technical Notes. There are often rich pieces of vanilla
functionality that gounnoticed.  Take a look at the Clientdemo to see
how it works and the Tools demo to see how it has beenconfigured.  The
smaller amount ofconfiguration the easier the application will be to
maintain.  We will not be renaming any of the
vanillaobjects.

c.   COPY vs. CREATE: Whenever possible, you
shoulduse existing Siebel objects versus creating new ones.  This will
reduce redundancy in theconfiguration.  However, there are someinstances
where creating a new object is necessary.  In this
case, you should copy an existingobject, if possible, and make the
necessary additions.  This will save development time and make iteasier
to set the relevant properties for that object type.

d.   Upgrade Ancestor: When copying Business
Components, Applets, Integration Objects and Reports,use your best
judgment to set the “Upgrade Ancestor” property.  If you want the cloned
object to behaveexactly as the original, with minor
modifications (e.g. search spec, sortspec), you should set the upgrade
ancestor.  By setting the Upgrade Ancestor property, Siebel will upgrade
the objectwith new functionality.   When Siebelupgrades the object,
nothing is removed, it does not affect any custom
fields,etc. that you have added.  Considerfollowing scenarios if you
are stumped with upgrade ancestor property.   You would not want to use
this property ifthe object is completely different from the original
from a functionalperspective. You would set the
Upgrade Ancestor property if you want the objectto maintain similar
functionality (special class logic, User Properties, etc)as the
original.

e.   Avoid creating new Business Components. This
will result in an application that is easier to maintain, andeasier
upgrades. If there is an absolute necessary to create a
businesscomponent, use your best judgment to set “Upgrade Ancestor”
property toinclude/exclude new business components during an upgrade.

f.    Avoid deleting existing Siebel data management objects. 
In general, you should avoid deleting existing Siebel data
managementobjects even if you do not appear to be using them in your
configuration.  If you must remove an object, inactivate itwith caution
rather than deleting it. You can delete fields/columns from
applets.  However, if the applet is based on aspecialized class, it is
suggested that you inactive the field or list columnversus deleting it.

g.   Extension table or column against database? 
Ifyou want to store additional data that should always be displayed when
the baserecord is displayed, extend the base table to store this data. 
By doing this, the extra join to theextension
table is avoided and performance is improved.  If you want to display a
large number ofadditional profiling fields together on one view, use
the extension table,either using the pre-defined static columns or by
manually adding additionalcolumns.

h.   Follow the project naming conventions. When
creating new objects in Tools, be sure to give the object a namethat
complies with the project naming standard. For the HW
Siebelimplementation, always preface the name of the object with
“HW” For example, if you create a new field and you want to call it
TotalAmount and it is different from the OOB field, name the field “HW
TotalAmount”.  This will make it much easierfor all developers to
identify new objects.

i.     Always consider performance.  Try the following tips:

§  Outer joins are not necessary formandatory foreign keys

§  Use primaries for multi-valuegroups.

§  Use primaries for multi-valuefields in form applets.

§  Keep the number of businesscomponents used in a view small.

§  Ensure indexes exist to supportsort and search specifications. Indexes cannot span multiple tables.

§  Avoid sorting on un-indexedcolumns.

§  Avoid setting the Force Activeproperty of joined fields to TRUE. 
Evenif the field is not displayed, the join will be performed to
retrieve the valueof that field.

§  Avoid setting the linkspecification property to true.

§  Avoid using certain functions forcalculated fields that will be
used in a search spec.  For more information consult the Siebel
ToolsReference Guide.

§  Avoid calculated fields that arenot supported by RDBMS.

§  Avoid Specifying outer joins whenrelationship is mandatory.

§  Avoid creating a large number ofjoins in a business component.

§  Avoid displaying totaled columnsin list applets unless the number of records will always be small.

§  Spool out the SQL using the /Sparameter and check the query plan in the server and local database

§  Always test against a realisticdata set and distribution

§  Use switch statement inpreference of if…elseif. Switch statements
group together areas offunctionality in a way that makes it far easier
to locate and understand scriptflow later in the application lifecycle

§  Cursor Mode, preferably use“ForwardOnly”

j.     Plan your configuration project from the top down. First
determine what the UI andapplication will do when you have finished,
then determine what changes to thebusiness objects layer this will
require, and finally determine what changesyou
must make to the data layer.

k.   Make the changes from the bottom up. First,
edit the data layer definitions (ifnecessary), then, edit the business
object layer definitions as required,finally edit or create the
templates and UI layer definitions to display thedata
correctly.

l.     Avoid using negative terms for true/false. “Not Require” vs “Optional”.

2.2       Configurationsof Siebel Objects

Developersshould follow this workflow to complete their activities:

1.   Lock out Objects/Projects for making changes

2.   Find objects in your Siebel tools

3.   Work on your objects.

4.   Complete your objects.

5.   Test and Verify.

6.   Check in and finish objects.

2.3       TopTen Configuration Tips

1.    Think vanilla - Leverage vanilla or existing configuration.

2.    Modularize, be dynamic - Avoid configuring the same thing twice.

3.    Avoid scripting, it’s hard - Avoid VB/eScript unless absolutely necessary.

4.    Test, test, test! - Test your work thoroughly and locallybefore check-in.

5.    Comments, be verbose - Provide meaningful comments with datesand initials.

6.    Check in regularly  - Check in stable and unit tested projectsregularly to avoid “big bangs” and hoarding projects

7.    Avoid new BCs, think next upgrade - Avoid creating new Business Components.Use Upgrade Ancestor property wisely.

8.    Research, before asking - Check Bookshelf and
SupportWeb before askingcolleagues.

9.    Avoid Deleting, inactivate - Avoid deleting dataobjects.  Inactivate instead(cautiously).

10.   Realitycheck - If the configuration effort is huge, discuss other options

11. DevelopmentEnvironment

Oraclerecommends creating a complete configuration environment that
includes both aSiebel Database Server and a Siebel Application Server.
This environment mustbe completely separated from the production
environment. Only authorizeddevelopers and Data Administrator
should have access to the developmentenvironment. The authorization can
be obtained from the Project Manager orFunctional Team Lead. There
should be no configuration work performed in theproduction environment.
You (authorized developers) should also have
a separatetest environment into which your configuration can be
migrated for systemtesting prior to installation in the production
environment. As with theconfiguration environment, the test environment
should include both a SiebelDatabase Server and an Application
Server.

Theconfiguration database will store the working copy of all
repositories beingconfigured by your developers. Configuration work
should only take place on theconfiguration database. Once you have
finished configuring a repository, youwill use the Siebel
DEV2PROD utility to transfer that repository to a testenvironment and
to a production environment, please refer to subsequent sectionfor more
details on backup.

Beforemigration of the Development Repository to any Testing or
Productionenvironment, all projects newly created or modified should be
unit tested andreviewed by either the Configuration Team Lead or his
delegates.

Afterall reviews and corrections are performed with satisfactory
results,Configuration Team Lead will recommend the qualified projects to
FunctionalTeam Lead for approval to migrate to the destined server.

2.4       ConfigurationFile and Siebel
Repository File Standards

It is agood practice to be consistent in the naming, location, and
contents of theSiebel configuration (cfg) and Siebel Repository File
(srf) for all developerworkstations.  This will make it easy fora
developer to work on different machines. This will also
allow consistency within each of the applications.  CFG and SRF files
can be copied from LAN.

Application	Siebel CFG File	Siebel Repository File (srf)
Siebel Loyalty	loyalty.cfg	Siebel_sia.srf
Siebel Loyalty eMember	eLoyalty.cfg	Siebel_sia.srf
Siebel Loyalty eMember	loyaltyscw.cfg	Siebel_sia.srf

2.5       DeveloperConfiguration

Local Environment:Siebel developers should be set up
for local development as indicated inthe Siebel Tools Guide.  Siebel
Toolswill have a local development database on each Siebel
configurator’sworkstation.  This database should beinitialized
via Siebel Remote and is located in c:\Program
Files\Siebel\7.8\WebClient\Local and will be named sse_data.dbf by
default.

 

All development work should be done on a local database
(sse_data.dbf)within the Siebel directory.  Thisapproach allows proper
configuration control. It also serves as a control and checkpoint
against the newconfigurations before they are checked back into
the server and made availableto the entire development
machine. Development work should
NEVER be done on the server.

For consistency, all views should be constructed and verified in thefollowing font and screen resolution standards.

Target BrowserGroup and Language:

 

Target Browser Group: I.E 6.0.

Set the tools language mode to ENU by navigating to View -> Options-> Language settings.

System Settings:

Resolution:  1024 x 768 and 800x600

Font Size:  Small Fonts

SiebelConfiguration File Settings:

LargeFont                = Verdana-8-normal

SmallFont                = Verdana-8-normal

DefaultChartFont         = Verdana-10-normal

NavBarItemFont           = Verdana-8-bold

NavBarSelectFont         = Verdana-8-bold

NavBarTitleFont          = Verdana-10-bold

AppletTitleFont          = Verdana-10-bold

3     ConfigurationStandards

3.1       ApplicationDefinition

We
will use “Siebel Financial Services” Application, existing in theSiebel
Repository to store the configured application.  Make sure to reference
your webpages/menus/logos/screens/page
tabs to this application within Tools. Assignthe application level
menu-items to the “Generic Web Menu”.  This project will be shared among
all developers.

Application	Application Object Name	Application Object’s Project
Siebel Financial Services	Siebel Financial Services	FINS Financial Services

a.   Page Tabs: Page Tabsshould be assigned
to those screen groupings that will be accessed by the userfrequently. 
The Name of the Page Tabshould begin with a capital letter and
logically describe the views that fallunder the tab
(i.e., Contacts).  Page Tabnames should be plural (e.g., Contacts and
not Contact).  Note: Avoid assigning long names to the application’s
Page Tabs.  For initial rollouts, consider limiting thenumber of Page
Tabs utilized in the application so as not to overwhelm
newusers. The sequence of the screens in the Screen Menu Item and Page
Tab shouldcorrelate with the business process flow.

b.   Symbolic String:Symbolic string is commonly
used when you work on Siebel application. Sincestrings are used through
out the application, be sure the new definitions alsomake sense in other
area. Do not modify the existing string, create
a new oneto meet your requirements instead.

c.   Error Web Page: Set the error web page in
theapplication object definition. This will ensure that a standard error
page willbe displayed when the error occurs.

3.2       Projects

3.2.1  ProjectDefinition

A project is a named set of objects. This is used to group related
object definitions. The projects will beused to check in, check out,
lock for modification and compile.  There are several general things to
rememberabout projects:

a.    Once you create a project, youcannot delete it.

b.    Never change the name of aproject with which standard Siebel Object definitions are associated.

c.    All the envisioned projectsshould be created
before any configuration is started.  A single individual will do this
task.  As a general rule, a developer should notcreate new projects
without first coordinating with Oracle Siebel ConfigurationLead. 
Special care should be taken increating the new projects as once they
are created; they cannot be renamed ordeleted.

d.    Never move an object definitionbetween
projects. Changing the project of an object causes considerable harm
toALL developers and can cause work to be lost. All existing objects in
Siebel should remain assigned to their vanillaSiebel
(or current) projects.  However,there are some instances where custom
object definitions movement acrossprojects is necessary.  In this
case,Oracle Siebel Configuration Team Lead should perform this activity
usingfollowing steps as guidance.

·        Check out both projects.

·        Change the project property of the object definition you intend to move,so that reflects the name of the new project.

·        Check in both projects together (failure to do so can leave therepository in an inconsistent state).

·        Inform all colleagues they must do a simultaneous get of the
two projectsbefore any further development on those projects

All newprojects to be created start with “HW”.  All projects are singular (e.g., HW Product(UI) and not HW Products (UI).

Thefollowing tables represent all the custom projects to be created:

Project Name*	Description
HW Project Name	HW project for all new non-visual (data manipulation) objects such as Business Objects, Business Components, etc.
HW Project Name (UI)	HW project for all new  visual (presentation) objects such as Views, Applets, etc.

*Replace Project Name with an entity name

3.2.2  Checkingin and out Projects

There are several important things to remember about checking projectsin and out:

a.    Share with others. You are most likely working
with other developers.  Avoid holding projects.  Only check out
projects that you absolutelyneed and check them back in as soon as you
are done.

b.    Work locally. If you want to try out something
small, avoid checking outprojects.  Lock the project locally andthen
test out your solution.  This meansboth you and the developer harassing
you for the project can worksimultaneously. 
If you are happy withyour work, export it, check out the project, and
then import it.

c.    Check in regularly (Only stableand tested objects). 
If you are working on a largeunit, check in your work regularly to
avoid “big bangs” to the repository.  This will make things much easier
totroubleshoot if there are problems with
your configuration.  Avoid checking in unstable projects, Check in only stable and unit tested objects/projects.  Do a “Diff” on the project before every checkin and make sure that you are checking in correct and stable objects.  This will
eliminate the risk of repositorygetting corrupt.

d.    Do regular “Gets.” Before you approach other
developers informing them that something isbroken, be sure you have done
a “Get” of the appropriate project (and relatedprojects).  This will
save you both timeand embarrassment.  In addition,
duringthe development phase, you should be kicking off a “Get” of all
updatedprojects before you leave at night.  Youcan then compile these
projects first thing in the morning and proactivelyplace the new SRF in
the designated directory on the LAN for the
otherdevelopers.  This saves time and money.

e.    Avoid canceling check ins/outs. This is
neither a good practice for your local repository nor theserver’s.  In
theory, Siebel can fullysupport canceling these actions (hence the
“Cancel” buttons) but this canoccasionally cause corruption
and can leave a repository in an unstablestate.  Just be patient, wait
for theprocess to finish, and then move on.  Youand your colleagues will
be much happier and the overall likeliness of problemsis greatly
reduced.

f.     If in doubt, leave it out! If you have a
project checked out and someone else is asking for it,think about
changes you’ve made before you check it in.  Do a “Diff” on the project
before every checkin.  If you have any uncertainty
aboutthe stability of the project, do not check it in.  Export your
work, do a “Get” over theproject, and then check it in.  It is notworth
the hassle of checking in a broken project and watching your
colleaguestry to figure out what you broke.

g.    Errors, report them immediately. If you
receive an error checking a project in or out, report this toyour Oracle
Siebel Configuration Team Lead and the Oracle Siebel
Administratorresponsible for server repository maintenance. Do not
ignore this problem and continue working.  There could be a problem
with the repositorythat needs to be handled immediately.

h.    Never login tools using genericlogin id.
Neverlogin in tools using generic id such as “SADMIN” when checking out
projects.This is not best practice in terms of keeping track of
developer’s activities.

3.3       ObjectNaming Conventions

Thefollowing naming conventions should be used for all new or copied
objects (withthe exception of backup copies). However, no Vanilla Siebel
objects should be renamed to follow theseconventions.  All
new or copied objects, whether a data manipulation object or a datapresentation object should begin with
HW(the only exception is Links.  Eachtype of object should follow the following guidelines:

Object Type	Naming Convention	Example
Business Component	HW Buscomp	HW Address
Business Object	HW Busobj	HW Account
Link	Parent Buscomp/Child Buscomp	Quote/Contacts
Pick List	HW Picklist	HW Account Picklist
Applet	HW List Applet HW Form Applet HW Entry Applet HW Tree Applet HW Pick Applet HW MVG Applet HW Associate Applet HW Chart Applet	HW Quote List Applet HW Quote Form Applet HW Quote Entry Applet HW Quote Tree Applet HW Quote Pick Applet HW Quote MVG Applet HW Quote Associate Applet HW Quote Chart Applet
View	HW View	HW Quote View
Screen	HW Screen	HW Quote Screen
Report	HW Report	HW Quote Detail Report

3.4       PresentationObject Configuration

All data presentation objects canbe modified if little or even
moderate modifications are required to thatobject (the only exception is
Screens). However, before any major modifications are made to that
vanilla Siebelobject, a backup of that object should
be made. To make a backup of the object, copy the object and keep the
originalname with “VANILLA” added to the end of the name.  Finally,
inactivate the backup object.    If substantial change is required to be
madeto the presentation object, and then a new
object should be created (this canbe copied from an existing
object). These new and/or copied objects should begin with “HW”.  Data
Presentation objects include:

q Applets (List, Form, Tree, Pick, MVG, etc.)

q Views

q Screens

3.4.1  ScreenDefinition

·        New screen names should always begin with “HW” (i.e., HW
ContactScreen).  This name should also logicallydescribe the overall
purpose of the screen within the customized application.

·        For each screen definition, a default view must be
assigned.  This view should always be the first positionof the menu item
on the Screens menu and/or the View-bar for the application.

·        If a Siebel defined screen will not be used in the
application, use theResponsibility Administration Screen to disassociate
all views on the redundantscreen from those responsibilities used by HW
project.  This approach reduces the amount ofconfiguration
that you need to maintain and upgrade.  It also provides for an easy
upgrade pathshould you decide to expose the screen or views in a later
phase.  At that time no configuration or softwareupgrade would be
required, you would merely reassign the views to the
relevantresponsibility.

3.4.2  ViewDefinition

During theDesign stage of Siebel implementation the design team
should define the viewsrequired for the implementation.  Theseviews will
usually be in one of the following categories:

·        Views that closely align with an existing view in Siebel,
require thesame applet layout, but require other configurations such as a
title change,inactivating or adding fields, changing field labels etc. 
The recommended approach for this category
ofview is to configure the existing view object.  Most configurations in this category willactually be performed on the applets rather than views.

·        Views that closely align with an existing view in Siebel but
require amoderately different applet layout, possibly displaying
applets based on newbusiness components, or adding toggles. The
recommended approach for this category of view is also
to configurethe existing view object.  Thedesign may or may not require configuration of the existing applets also.

·        Views that consolidate two views already existing in Siebel.  The recommended approach for this category ofview is to
configure one of the existing views by modifying the viewobject, and remove visibility to the redundant view using the ResponsibilityAdministration Screen.

·        Views that do not have an obvious equivalent already
existing inSiebel.  These will tend to be views thatexpose new
functionality specifically configured for your implementation,exposing
new business objects, and/or business components.  The recommended
approach for this category ofview is to create a new view object,
and to avoid extensively modifying anexisting definition that will not
be utilized in your implementation. Theresulting configurations will be
much cleaner, and easier
to maintain andupgrade (both manually and automatically).

Eithercopy an existing view or use the View Wizard to create new view
and assignapplets. The default mode for the applets in a new view is
base. Set the appletmode appropriately.

To enable thread bar, ensure that the applet template identifiedincludes an “SWE threadbar” tag

3.4.3  AppletDefinition

An appletis a visual representation of underlying business objects and businesscomponents.

During theDesign stage of Siebel implementation the design team
should define the viewsrequired for the implementation.  Theapplets
displayed on these views will usually be in one of the
followingcategories:

·        Applets that closely align with an existing list applet in
Siebel butrequire minor configurations such as a title change,
inactivating or addingfields, changing field labels etc.  Therecommended
approach for this category of applet is to
configure the existing appletobject and its child objects.

·        Applets that represent a relationship already existing in
Siebel (e.g. Opportunity contacts), but require extensive modificationof
the existing applet to produce a new applet web template.  The
recommended approach for this category ofapplet is
to create a new applet object. The resulting configurations will be much cleaner, and easier tomaintain and upgrade (both manually and automatically).

·        Applets that do not have equivalent applet already existing
inSiebel.  These will tend to be appletsthat expose a new business
component. 
A newapplet should always be created for this
category of list applet. Makesure you are not using the specialized
class when creating new applets.  Select the appropriate applet web
templatefor each applet mode. Edit Mode for Form
Applets, Edit List Mode for ListApplets

Applet Toggle: Whendefining applet toggles, ensure that the applet template identified includes an“SWE togglebar” tag

Pick,MVG and Associate Applets

 

·        All Pick applets must display the Find Box functionality in the upperright corner of the applet.

·        All new Pick, MVG, andAssociate applets should be copied from an existing Pick, MVG, or AssociateApplet with the same template/style.

·        Wherever possible, Pick, MVG, and Associate Applets should
be sharedacross the application. Each business component belongs to a
particular workstream, some business components are cross functional. It
is the responsibilityof the work stream lead
to make sure duplicate PickLists and Pick Applets areminimized in their
work stream business components.

 

Form Applets and Applet Web Templates

Text Labels:  Alltext labels on forms should be left
aligned. All text label names should be prefixed with ‘Label’.  Avoid
display names that occupy a largeamount of applet real estate. 
Useabbreviations, if possible.  Avoid usingtext attached
to check box controls. Instead, re-size the check box control so that
only the box remains andformat a regular text label so that it is
aligned with the box control.  Following these steps allows more
flexibilitywith the text label and the label does not become
grayed out when the controlitself is read only.

Tab Order: Tab order should follow the steps the
userwill take while manipulating data on the form applet. Read only
fields shouldnot have a tab stop. Exceptions are read only fields that
have MVG glyphs andpopup edit glyphs.

Glyphs: Read only controls and calculated
fieldsshould not display any glyphs.  Disablethese glyphs by Specifying
Runtime = False and Popup Edit = False on thecontrol definition. 
Exceptions are whena glyph is needed to open a MVG applet,
Detail applet, or popup edit field toview additional information.

Text Control: All text control fields should be
alignedto the left.  This includes calculatedcontrol fields.  Number
control fields(including Currency) should be aligned to the right. If
the value of a field isnot entirely displayed within
the Control, the HTML type for the control shouldbe TextArea, and the
HTML Attributes should define what the dimensions of thefield are. All
controls should be assigned the same name as the ‘Field Name’that the
control is accessing (i.e., If the control displays
the value held inthe ‘Account’ database field, the name of the control
should be ‘Account’).

Attempt to place MVG applets in form appletsas opposed to list applets. 
This practice can improve theapplication’s performance since the
children of only a single record needs tobe retrieved from the database.

Search Specification: The Search Specification
forapplets is functional in Siebel Tools. Use of the Search
Specification propertyon an Applet should only be used when such
functionality is supported by thedesign of the application.  The
fieldsused in the Search Specification should be included in an index
for thebusiness component data entity.

List Applets

• All list applets should be assigned a title that logically describes
  the information displayed in the applet.  Titles should be in plural.

• All list applets should display a record tracker (i.e., 1 of 20 records).

• Every column in the list applet should be assigned a logical display
  name.  This display name should remain consistent across the
  application.

• Read only and calculated fields displayed in the list applet should
  not display a glyph.  Disable these glyphs by specifying Runtime = False
  and Popup Edit = False on the control definition.  The only exception
  occurs if a glyph is needed to open a MVG
  applet, Detail applet, or popup edit field to view additional
  information.

·        Whencreating list column definition set the appropriate HTML type for the control.

• If the value of a field is not entirely displayed within the List Column its HTML type should be TextArea

• Column widths should take into consideration the length of the
  display name and the length of data held in the field.  Generally, the
  entire display name should be visible to the user.  This is editable in
  the HTML Width property.

• All check marks (DTYPE_BOOL) should be justified in the center of the column.

• All text fields (DTYPE_TEXT) should be justified left in the column.

• All date fields (DTYPE_DATE or DTYPE_DATETIME) should be justified left in the column.  The calendar popup should be available.

• All number and currency fields (DTYPE_NUMBER, DTYPE_CURRENCY, AND DTYPE_INTEGER) should be justified right in the column.

• All phone fields (DTYPE_PHONE) should be justified left in the column.

• All numeric calculated fields should be justified right in the column.

• Avoid placing an excessive number
  of columns in a list applet.  It is unlikely that a user will scroll
  through the columns unless they can do so quickly.

• When creating a new list applet, consider using the ‘New’ option
  under the File screen menu in Tools.  This option walks the developer
  through the list creation including the assignment of business
  components, titles, and column order. 
  Note:  This method assigns each column a width of 20
  and does not assign field level attributes.  The developer must assign
  these values individually to the list’s columns.

• Use of the Search Specification property on an Applet should only be
  used when such functionality is supported by the design of the
  application.

• Attempt to keep the Applet Titles as short as possible.  This allows for enhanced usability.

·        List applets require the list control in order todisplay the collection of list columns. Do not edit this control.

3.5       DataObject Configuration

All dataobjects (e.g., business components, business objects,
PickLists, etc.) shouldbe used in their original form with little or
moderate modifications.  However, before any major modifications aremade
to that object, a backup of that object should be
made.  To make a backup of the object, copy theobject and keep the
original name with “VANILLA” added to the end of thename.  Finally,
inactivate the backupobject.

3.5.1  BusinessObject Definition

• Typically you will create a new business object when your design
  requires a new screen that groups a number of new business components
  together or groups existing business components in a way that is not
  supported by an existing business object.

• Business Component declarations for a Business Object should be
  limited.  Only Business Components needed for application functionality
  should be declared under a Business Object.

• Unused Business Objects: The recommended approach is to leave
  unmodified any business object definitions that you are not utilizing in
  your implementation.  These definitions should not be deleted as other
  objects may reference them.

3.5.2  BusinessComponent Definition

Creating and Modifying Business Components

 

·        Often, while configuring Siebel Enterprise Applications, a
need arisesfor a business component that is similar – but not identical –
to an existingbusiness component.   In such cases, youmust choose
between a) creating an entirely new business component
based on theexisting one, or by modifying the existing one so that it
can be reused.   The
latter solutionis almost always
preferable because it reduces the number of businesscomponents, which,
in turn, leads to a configuration that is easier to maintainand upgrade.

·        You can configure Siebel in a way that allows you to reuse
the businesscomponent rather than creating a new business component. 
Consider an implementation where one group ofusers may create
opportunities, but another group can only edit existingopportunities. 
Rather than creating anew business component and setting the No Insert
property to TRUE, you caninstead define a new applet and set the No
Insert property to TRUE for theapplet.

·        When creating new business components, you should avoid
copyingspecialized business components, unless your intent is to create a
‘clone’ ofthe original business component.

·        In the event you have to copy an existing businesscomponent,
use your best judgment to set the upgrade ancestor property whencopying
the business components. This ensures that the copied businesscomponent
is upgraded in the same way as the original
business component.

·        Avoid assigning TRUE to the No Update, No Delete, No Insert,
and NoMerge attributes on a business component definition.  This
practice increases the reusability ofbusiness components for applet
definitions (the No Insert, etc. attributes canbe assigned
at an applet level).

·        When possible, avoid using long search specifications on
BusinessComponents.  This will help theapplication’s performance.

Sort Specifications

Allbusiness components should be assigned a logical sort
specification that sortsthe data for the user.   For performancereasons,
avoid sort specifications thatuse joined, multi-valued, or
calculated fields. If possible, always use an indexed column in the sort
specification.  This will improve the application’sperformance.

 

Joins

·        A join defines a logical join between the business component
base tableand another table.  A join should only beused when the
resulting database join will retrieve only one record.  For example, a
join is used to retrieve theprimary account for
an Opportunity.

·        Join fields are not editable unless they are joining to an
intersectiontable, or to a 1:1 (_X) extension table. Intersection table
join fields are only available and editable when theparent intersection
record is active

·        A business component may have more than one join with the
samedestination table if you specify an alias for each join using the
Aliasproperty.

There aretwo types of joins, Explicit and Implicit.

1.   Explicit Joins: The only column in
this type of join, which is updateable, is theforeign key field.   You
must Specify thetable to join to and whether it is an outer join.  The
join specification definition containingthe source
field in the parent business component and the destination column inthe
child table.

2.   Implicit Joins: You do not have to
define an implicit joinvia Siebel Tools.  These joins exist forall 1:1
(_X) extension tables and relevant intersection tables.  The tables are
displayed as options in theJoin property pick
list on the Field object. The columns from this type of join are
updateable.

·        Join Specification Names should be named with the same value used forthe join’s source field.

·        The Alias property within a Join should be named with the same valueused for the Join’s source field.

·        Since unnecessary joins hinder the application’s
performance, ensurethat all joins defined for a single business
component are needed to supportthe business functions.

·        Specify Outer Join false when possible. However, in most
cases this is not possible.  Only fields that are required should have
anouter join set to false.  Wheninformation is being joined in, verify
that records will be returned from thedatabase. 
Joins with outer joins set tofalse will cause the entire record to not
be displayed if the joinedinformation is not specified.

·        Siebel automatically has joins available for _X tables and intersectiontables.

Joinsand party business components

 

·        Use the implicit join for the extension tablewhen creating join for the party business components.

·        Create join specification based on PAR_ROW_IDwhen bringing party data into a non-party business component.

·        Use the appropriate explicit join whenbringing the party data into a party business component.

MultiValue Links

·        All multi value links names should be the same as the link’s
destinationbusiness component (i.e., the name of the MVL
Contact/Position should be‘Position’).

·        When possible, use a Primary IdField when defining a multi value link in the business component. This
practice will improve the application’s performance.  If a Primary Id
Field is specified, mark the“Use Primary Join” field as
True.

·        The “Popup Update Only” should be marked as True for all MVGs.

·        In the case where large amounts of data are converted, consider theeffect of the
Check No Match property. It will attempt to set a Primary wherethere is none, and can impact performance, depending on the state of the data.

Field Definitions

• No Fields should ever be deleted from a Vanilla Siebel
  Business Component.  In addition, no Vanilla Siebel Fields should be
  renamed.  Fields can only be inactivated, but caution should be
  exercised in this practice.  As a general rule,
  if a Business Component field is not causing any problems or conflicts,
  then leave it alone (e.g., do not inactivate the field).  However, do
  not inactivate any field that is required.

• New Business Component field names should closely match the agreed
  Display Names.  Alterations from this practice should only be made to
  remove special characters.  No new Business Component field name should
  contain special characters (e.g.,
  !@#$%^&*():”’<>?/><.,~`+_-=£). 
  These special characters may be confused as operators if the business
  component field is used in a Siebel script.  For example, “Company #.”
  as displayed visually should have a Business Component field name of
  “Company Number.”

• Do not explicity define system fields for a business component.

• If the field is a check mark, the end of the name should be ‘Flag’.

• Avoid assigning the ‘Force Active’ attribute to the business
  component and it’s corresponding fields to increase the application’s
  performance.  However, in some cases it is necessary to assign the
  ‘Force Active’ property for fields that are not exposed
  in an applet and are used in either a Siebel script or Correspondence
  mail merge.

3.5.3  LinkDefinition

When possible Specify the Primary Id fieldfor a Link.

Consider the business rules and implicationsof the following Link Properties.

 

·        Cascade delete – None, Delete, Clear

·        Search Spec – applied to child business component

·        Sort Spec  - only applied toassociation lists

·        Visibility Rule Applied – Never, Always Child, Drill Down

3.5.4  UsingStandard Extension Tables

_Xextension tables (1:1) - This type of extension table is basically
just anextension of the base table record.  Youdo not need to create a
new business component object when you use thesetables.  The _X tables
are implicitlydefined as joins.

If youhave to create an extension table to the party tables, create
the extensiontable against the S_PARTY table and not the table where the
core data isstored.

_XMextension tables (1:M) - This type of extension table allows you
to create aone to many relationship with the record in the Siebel base
table being theparent.  The following is a list ofguidelines to follow
when using the _XM tables:

·        Create a new business component based on the relevant _XM table.

·        Create a ‘Type’ field based on the TYPE column and use this
to filterthe records by Specifying it in the search spec for the
business component.

·        Add the correct Pre Default Value to the Type field.

·        Use the NAME column to track the main data field.
Alternatively, sinceNAME is a required column, a standard technique is
to predefault it with the Idfield (ROW_ID column) to ensure uniqueness,
in the case where you want to trackmultiple records
in the table with the same value with the same parent id.

·        Unique index is on PAR_ROW_ID, TYPE, NAME, CONFLICT_ID- you will need toconsider this in your design.

·        If displaying in MVGs, extend the base table to track primary values.

3.5.5   PickList Definition

• PickLists with Lists of Values should be based on the Business Component “PickList Generic.”

• PickLists based on the List of Values do not require a Pick Applet.

• A business component field that uses a PickList must have pick maps
  specified.  Failure to specify pick maps causes the drop down arrow to
  disappear.

• Only bounded PickLists can be configured to be multilingual.

3.6       Listof Values

All Listof Value Types and List of Value Values must be up to dated.
Siebel ApplicationAdministrator is responsible to upload these values to
development, test andproduction environments.

·        No Standard Siebel List of Value types should be removed
orinactivated.  List of Value values can beinactivated, but not removed.

·        List of values that use an existing LOV type should keep
that LOV typeunchanged.  All new LOV types should benamed as follows: 
HW_NEW_LOV_TYPE (e.g.,HW_ACCOUNT_REGION).  The type should bein all
capital letters with an underscore between each word.

3.7       Commentingin Siebel Tools

Alwayscomment new and modified development. This applies to both code
and configuration changes.  Any configuration you do might be
continued,or potentially debugged, by someone else, so ensure that
commenting exists andis easy to follow and understand.

When commenting,be sure to include exactly what you are doing, while
you are doing it.  Don’t be afraid to put in too muchinformation.  You
may be aware of whatyou are doing when you implement the change, you
will not remember what it wasseveral months later
when you go back to comment your work.

Keep yourcommenting professional.  Remember thatthis application will
eventually be handed over to client.  Treat commenting just like a
document youwould hand over to either of them.

In Siebel configuration, there are two areas for which comments
areessential: Tools and eScript.  As animplementation progresses,
tracking development changes is imperative.  If a modification is
applied to the repository and something breaks,the most efficient
way to troubleshoot is to work backwards, examining recentconfiguration
using comments.

Observethe following standards for tools and eScript commenting:

1.   Tools

Theproject standard for adding comments to the Comments field of all
items intools is as follows: the comment should always include “HW”, the
date developedin a DD/MM/YY format, the developer’s first initial and
last name, and acomment explaining why the
development was done.  Below is an example:

HW  KK 31/03/08 – New calculated field added todisplay total taxes

2.   eScript

 

a. The Header

Whenwriting a new script that will be referenced as a method or
function, alwaysinclude a standard header.  This headerneeds to include
three items: Name, Description, and a Log.  The name is the actual name
of the script.  The description will explain what
the scriptdoes.  The log will track all changesmade to the script, even
if the original developer is making the change.  Below is an example:

functionMI_HW_Get_Volume_Discount()

/********************************************************************

Name:         MI_HW_Get_Volume_Discount

Description: This method will retrieve the Volume Discount Id

from the product selected at the Service Instance

Level and then call anotherfunction to find the

appropriate volume rate.

Log:

RC 31/03/08 - Removed Message Box when the Discount Amount Changes

DC 01/04/08 - Message Box when the Discount Amount Changes

*******************************************************************/

{

b.Modifications

When making modifications to existing code, the comment should
alwaysinclude a beginning and end indication so other developers will
know the extentof the modification.  This should includethe developer’s
first initial and last name, begin or end, the date
developedin a DD/MM/YY format date and a comment explaining why the
development wasdone.  Below is an example:

// ***** ParkY BEGIN –05/04/08 *****

// Added date formattingmodification

{Code modification here}

// ***** ParkY END –15/04/08 *****

 

c.Fixes

If thescript modification is a fix to a defect and the defect has an
ID number (whichit should have been assigned a testing tool), be sure to
include the defectnumber and the environment when commenting. This can
assist both you and other developers in recollecting
why thechange was made.  Below is an example:

// ***** EInra BEGIN –05/08/07 *****

// HWAPP #233 – Commentedout message box

{Code modification here}

// ***** EInra END – 23/08/07 *****

4     DatabaseExtensibility

When using DatabaseExtensibility against a database you can choose to
either extend the basetable, or use a column on the extension table. If
your requirement is to store additional data that should always
bedisplayed when the base record is displayed, the
recommended approach is toextend the base table to store this data. By
doing this you avoid the extra join to the extension table.   The only
exception is for party tables. Theparty business components are based on
S_PARTY table. The core data is howeverstored
in extension tables like S_ORG_EXT and S_CONTACT.  The extension
columns should follow thestandard Siebel naming convention with
X_NEW_COLUMN (e.g., X_CASE_FLG).  When creating a DATE or NUMBER column,
thesize of the new column should never be altered unless
discussed with theteam.  All boolean extension columnsshould be defined
as type CHAR.

Extension columns should be created in groups and co-ordinated with
theremainder of the team.  This is due tothe time involved in performing
this process. Oracle Siebel Administrator will create the extension
columns for theteam. The Administrator will maintain
a log of all the extension columnscreated. The request for extension
column needs to be sent to the individualwith the details. The
administrator will create the necessary columns and applythe changes to
the server database. Once the column is created and
changes arepropagated to the server, the administrator will notify the
rest of theteam.

Oracle Siebel Administrator will use following guidelines while creatingextension columns:

·        When creating a new extension column, never copythe column
from existing vanilla column.  Undesired properties from the existing
column are often carried forwardfrom the copied from column.  It is
bestto just use the “New Record” functionality. In
creating a new column, you should only modify the Name, PhysicalType,
Length, and Comments attributes. Do NOT modify any other attributes from
their defaults.  All extension columns
must be checked as “Nullable” as defaulted.

·        When creating a new extension column, acorresponding EIM column should also be created and mapped to the newcolumn.

5     SiebelScripting Standards and Guidelines

The
following guidelines detail standardpractices for Siebel eScript code. 
Inall cases, a program logic specification should be written and
reviewed beforeany Siebel eScript
code is implemented.

5.1       GeneralGuidelines for accessing
Siebel objects via Siebel scripts

·        Always activate fields that will be accessed in abusiness component BEFORE performing a query on the business component

·        When instantiating business components, remainaware of what
context you are instantiating the component (i.e. what businessobject
does the business component belong to)

·        Visibility rules still apply to business componentsin Siebel
VB scripts or those accessed via OLE, but can be changed, by usingthe
.SetViewMode method passing one of the following values: 
SalesRepView(0), ManagerView(1),PersonalView(2), AllView(3),
NoneSetView (4)

·        If using the ‘this’ function to instantiate aSiebel object,
avoid declaring the variable that holds this object at themodular
(private) level, rather declare it at the local level and pass it
intoother subroutines as a parameter.

·        Always clear the memory of Business Objects andBusiness
Components when they are no longer needed (i.e. bcAccount = null)

·        Code should follow standard indentation procedures

·        Within Siebel eScript scripts, always declarevariables at the beginning of the script.

·        Pay attention to the case. Siebel eScript is casesensitive.

·        Use parentheses () with all functions.

·        Use four-digit year in dates.

·        Make effective use of SWITCH construct.

·        For each of the Siebel script edit boxes, a limitof 16k
characters exists. Each subroutine or function has its own edit box
andtherefore can be up to 16k. The same limit applies to the
(general)(declarations) section. If you are approaching this
limit, try the followinghints to reduce the size of your script:

1.    Removeextraneous comments.

2.    Indentcode using tabs instead of spaces.

3.    Useshort variable and method names.

4.    Createsubroutines and functions.

5.2       Rulesfor
Siebel eScript Variable and Object Names

• Spaces are not allowed in any object name

• Object names begin with a letter and should only include letters and digits

• Object names use mixed upper and lower case to add readability to the name

• The only non-abbreviated syntax element that can have multiple capital letters is the base name

• Object names are usually singular rather than plural

• An object’s base name should include the base names of any object it is built on, if practical

Data Type	Prefix	Example
String	s	sMyStringVariableName
Integer	i	iMyIntegerVariableName
Double	d	dMyDoubleVariableName
Long	l	lMyLongVariableName
Currency	c	cMyCurrencyVariableName
Date	dt	dtMyDateVariableName
BusObject	BO	BOMyBusinessObjectVariableName
BusComp	BC	BCMyBusinessComponentVariableName
Applet	AP	APMyAppletVariableName
Control	CT	CTMyControlVariableName
Time	Tm	TmMyTimeVariableName
DateTime	Ts	TsMyTimeStampVariableName
Business Service	BS	BSMyBusinessService
PropertySet	PS	PSInputs

5.3       Useof Try Catch Finally Blocks

Try/Catch/FinallyBlocks should be used in EVERY piece of custom code written in Siebel.

functionFUNCTIONNAME ()

{

try

{

CODE GOES HERE

}//end try

catch(e)
{
  if (defined(e.errText))//this case includes the RaiseErrorTextMessage (purposeful alert).
     {
           TheApplication().RaiseErrorText("Error:  " + e.errText +
            "\n\n\nAnexception occurred in the " + arguments.callee +
            " ofthe " + this.Name() + " object.\n\n" + "Stack:  "+ e.toString());
        }//end else if
     else
        {
           TheApplication().RaiseErrorText("An exception occurred in the
" +arguments.callee + " of the " + this.Name() + "object.\n\n" +
"Error:  "

                   + e.toString());
  }//end else
}//end catch

finally

{

NULL OUT OBJECTS IN CORRECT ORDER HERE(Business Components before Business Objects).

}

return XXX (if there should be a return in the Function)

}//endfunction

5.4       ScriptingTechniques

a.   User Properties: In many cases, Business
Component User Properties can be an excellentsubstitute for scripting. 
Oftentimes auser property, in conjunction with a calculated field, can
work just as well asscript and doesn’t carry as
much overhead and maintenance.  Just consider that Siebel does not
officiallysupport some of these features and there is no guarantee that
they will functionafter an upgrade.

b.   Alternatives to script: Other ways to avoid
scripting are field validation, read onlyproperties, and in some cases,
implementing additional modules such asAssignment Manager and Workflow.

c.   Modularize:If eScript is essential, be sure to
follow good coding practices and modularize.  These means as you write
code, seriouslyconsider whether it could be leveraged by existing or
future code.  If yes, it is worth the extra time
up frontto develop it with enough flexibility so it can be invoked from
any othermethod easily.   An example of this is afunction that performs
generic processing (e.g. one that retrieves the currentstatus of an
account).  However, there isone crucial step
that must be executed – inform team member that the codeexists!  Do not
assume they will find it(even though they should because they will be
checking before they write newcode).

d.   Business Services: If the code is so generic
that it could be leveraged application wide;consider developing it as a
Business Service. An excellent example of this is a Business Service
that contains all thescripted error messages for
the application. This way, all error messages are contained in one
service and developerssimply have to invoke a business service and pass
it the message flags.  In the repository, look for the BusinessService
called HW Error Handling Service.

e.   Daily Script Back-ups.  As the development
effortcontinues it is a good practice to perform daily backups of all
BusinessComponent and Business Service scripts. If a problem suddenly
occurs with a script, these backups can be veryuseful
in helping to isolate the problem. A good way to do this is to navigate
to the flat tab and perform exportsto a backup directory on the LAN. 
Use alogical naming convention including the date. Again, be sure to
inform colleagues that these backups exist.

f.    Always include error/exception handling to
avoid ugly error messages.  This can typically be implemented using
thetry, catch, throw methods.  CheckBookshelf for syntax examples and be
sure to use this logic in ALL of yourscripting!

6     VisibilityGuidelines

Alwaysconsider visibility rules when adding new foreign keys,
flatteningrelationships, or changing view or business component
visibility. Although itis possible to modify the visibility rules
defined by the UI, Siebel Remotevisibility rules will still determine
which records are downloaded to a remoteuser’s machine.  For example,
you canconfigure a view to give a user access to all opportunities in
the database.  When connected to the server database, theuser would
truly see all opportunities in the database.  However,
when running disconnected againsttheir local database, the user would
still only see the opportunities thatSiebel Remote determines should be
downloaded to their local database.  That is, they will only see the
opportunitieson which they are a team member,
and opportunities associated with an account,contact or activity to
which they have access.

Whencreating new a business component you should always ensure that
your visibilityrequirements are satisfied by the Siebel Remote
visibility rules applied to theparent business component, and base table
for the business component

7     Internationalization

SiebelApplication is intended to be deployed globally at a later
stage. Global Deploymentrequires the application needed to be configured
in a different fashion.  Modification after initial deployment
willrequire a system outage and “in place” data conversion.
It will requireadditional effort, but overall costs are reduced if done
prior todeployment.   Keeping that in mind,following activities should
be undertaken before initial HW deployment.

·        Determine if Global Time Zone support isdesired and, if so, which fields are eligible.

·        Determine if any Siebel “inside the box”unilingual List of
Values should be converted to multilingual List ofValues.  In addition,
all new LOV Typesintroduced in HW should be configured as multilingual
List of Values.

·        All new configurations should be done in a“language neutral” fashion.

7.1       ConfiguringFields for Universal Time Zone

Dateand time fields in Siebel vanilla fields are enabled for UTC.
This includesfields that users manually populate by entering date and
time data and fieldsthat the system populates by generating a date and
time stamp. However, if youcreate custom date and
time fields, it is important to enable them for UTC sothat data entered
in these fields is consistent with data entered in other dateand time
fields.

·        If you create new table extension column fordata and time
field, set the Physical Type property of the new column to UTCDate Time.

·        If you create new business component field,set the Type
property of the new business component Field to DTYPE_UTCDATETIME.

Afteryou compile your changes and if the UTC system preference is set to True, thefields will be enabled for UTC.

7.2       ConfiguringMultilingual List of Values

RCMApplication should be configured to display multilingual lists of
values (MLOV)in static PickList. This allows the system to display
values in the activelanguage of the user. It also allows the values
selected by a user in onelanguage to be retrieved
by users working in other languages.

TheLOV table contains a Display Value column and a Language
Independent Codecolumn. Both monolingual and multilingual lists of
values display values fromDisplay Value column to the user. However,
after the user selects a value in aPickList, the actual value
stored in the database is different for monolingualand multilingual
lists of values.

·        A monolingual PickList stores the DisplayValue.

·        A multilingual PickList stores the LanguageIndependent Code.

Storingthe value from LIC column rather than the Display Value column
allows the datato be stored in a form that users working in other
languages are able toretrieve and allows the roll up of data for
management reports, regardless ofthe language of the
users who enter the data.

EnablingMLOV should be performed by Oracle Siebel Configuration Team
Lead inco-ordination with Oracle Siebel Administrator. Team Lead will
use following steps as guidelines to enable MLOV forcustom created
columns and PickLists.  These activities should
be performed directly on the server only forcolumns and PickLists that
requires multilingual storage and display.  Siebel permits to work
directly on the serveronly for configuration of columns for multilingual
storage and display.  User should never work
directly on the serverunder any other circumstances.

·        Translation Table property should be set toS_LST_OF_VAL for database columns that store MLOVs.

·        LOV Bounded property should be set to TRUEfor database
columns that store MLOVs. All columns for a particular LOV typemust be
bounded. If any of the columns for the LOV type is not bounded, thennone
of the columns can be set to multilingual for
that LOV type.

·        Translate Property should be set to TRUE forall LOVs that
are multilingual in the List of Values Screen. (SiebelApplication à Site
Map à Administration –Data à List ofValues)

·        PickList must be bounded (Bounded Property isset to True).

·        PickList must use the same LOV Type asspecified in the LOV Type property of the column.

NOTE:Configuration of MLOVs can impact performance, especially when
the field onwhich the PickList is based is used as part of a search or
sort. Performanceshould be considered and verified in conjunction with
configuration of MLOVs.

7.3       ConfigurationConsiderations

RCMenvironments will be enabled for MLOVs; following guidelines should be followedto make the configuration “language neutral”.

LookUpName and LookUpValue functions: These
functionscan only be used in calculated fields or search specification
expressions. Theycannot be used with Siebel scripting.

Pre/Post default values for fields with LOV PickLists:
Alwaysuse the LookupValue function with “Expr:” in front of it. The
first argument isthe LOV Type and the second is the LIC (Language
Independent Code). Thefunction returns the language-specific
Display Value based upon the user’slanguage.

E.g. Expr:“LookupValue (““FS_PROD_ALLOC_RULES””, ““Default””)”

Dynamic drilldowns and toggle applets: These are
usuallybased on a field that has a LOV value. For example, a dynamic
drilldown mightnavigate the user to a Credit Card screen if the account
type is equal toCredit Card or to a Savings screen
if the account type is equal to Savings. Donot hard-code the drilldown
or toggle conditions. Rather, use the LookupValuefunction (as described
in the previous bullet).

Search specs for business components, links, applets, and PickLists: Alwaysuse the LookupValue function.

E.g. [InvoiceCode] = LookupValue ('FS_INVOICE_CODE', 'Auction')

VB functionality: VB does not offer a function to
retrievethe language-specific Display Value. However, the Display Value
must never behard-coded; you should use the language-independent code
instead. To write VBcode using the language-independent
code only, you must create calculatedfields that hold the
language-specific translation for a language-independentcode.

Language and ResourceLanguage parameters: Set theseparameters only in the configuration file, for example,
Language =<lang>, ResourceLanguage = ENU. If you do not setthese parameters in the configuration file, application users willintermittently receive error 2009.

8     RepositoryBackup

Makebackups of the development repositories on a regular basis,
preferable daily,to safeguard your configuration work. There are two
approaches to backups. Oneapproach would be to backup the database
backups using RDBMS utilities. Theother is to backup the
repository using a Siebel supplied utility called‘repimexp.exe’ to
export the contents of a specific repository to a flat file.The
following are some details of the backup strategy.

·     The administrator will perform a daily backupof the customized repository.

·     Use ‘repimexp.exe’ to make backups of thedevelopment
repositories on a regular basis to safeguard your configurationwork. 
The utility will be performeddaily (at the end of the day). All
developers will be required to ‘Check In’their projects prior
to this backup. Developers who wish to continue working ontheir
project(s) may ‘Check In’ whilst maintaining the lock.

·     All developers must store all other files,which require
backups, onto a common staging folder. These include client .cfgand .srf
files, batch scripts, Enterprise Integration Manager .ifb files,
Webtemplate files and so forth. The administrator will
use perform incrementaldaily backup of this folder.