Siebel Configuration and Development Guideline
1 Objectives. 3
2 Application Development and Customization Guidelines. 4
2.1 Points to Ponder4
2.2 Configurations of Siebel Objects. 5
2.3 Top Ten Configuration Tips. 6
11. Development Environment. 7
2.4 Configuration File and Siebel Repository File Standards. 7
2.5 Developer Configuration. 8
3 Configuration Standards. 8
3.1 Application Definition. 8
3.2 Projects. 9
3.2.1 Project Definition. 9
3.2.2 Checking in and out Projects. 10
3.3 Object Naming Conventions. 11
3.4 Presentation Object Configuration. 12
3.4.1 Screen Definition. 13
3.4.2 View Definition. 13
3.4.3 Applet Definition. 14
3.5 Data Object Configuration. 16
3.5.1 Business Object Definition. 16
3.5.2 Business Component Definition. 16
3.5.3 Link Definition. 19
3.5.4 Using Standard Extension Tables. 19
3.5.5 PickList Definition. 20
3.6 List of Values. 20
3.7 Commenting in Siebel Tools. 20
4 Database Extensibility. 23
5 Siebel Scripting Standards and Guidelines. 24
5.1 General Guidelines for accessing Siebel objects via Siebelscripts. 24
5.2 Rules for Siebel eScript Variable and Object Names. 24
5.3 Use of Try Catch Finally Blocks. 25
5.4 Scripting Techniques. 26
6 Visibility Guidelines. 27
7 Internationalization.. 27
7.1 Configuring Fields for Universal Time Zone. 28
7.2 Configuring Multilingual List of Values. 28
7.3 Configuration Considerations. 29
8 Repository Backup. 29
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.
