siebel configuration best practice

8/6/2019 Siebel Configuration Best Practice

1/1

ebel Configuration Best Practices,Siebel Configuration Recommended Practices,Siebel Configuration Best Practices Interview Questions

is article discusses best practices for Siebel configuration.

u need to evaluate whether the business process can be changed as it is usually more cost efficient to change the business process rather than change the

plication. You should change the application when the cost of changing the business process is greater than changing the Siebel application.

s usually best to make minimal changes to the standard Siebel application; this will reduce the possibility of unexpected errors etc. You should use existing Siebel

ect definitions wherever possible. This will make the application easier to maintain and upgrade. General rule of thumb is to modify existing Siebel repository objects

copy existing repository objects rather than create new objects. Also do not delete/inactivate existing Siebel objects as they may be referenced by other objects.

u should plan the Siebel project from the top down (i.e. Determine UI and Siebel application, then determine the changes required to business objects and business

mponents, then determine what changes this results in the data level). You should implement the Siebel project from the bottom up (i.e. Edit the data level objectsd then edit the business object level, then edit the UI layer objects).

r business components you should take care when copying business components. You should not define system fields on the business components. You should

me all new business objects and business components with a prefix that identifies the project and the name you give an object should be descriptive and meaningful to

t object. Ensure if you do copy a business component that you specify the name of the original business component in the Upgrade Ancestor field so that the object

n be easily upgraded.

r applets you should take care when copying existing applets, only copy when you have to make major changes to the applet. It is usually best to modify existing

plets. Reuse with applets is the best methodology. This saves a lot of time and maintenance. As with business components/business objects, name your applets with a

aningful descriptive name and prefix with the project name acronym.

r views you should usually modify existing views just making changes to the Title and applet layout of the view. Create a new view if no other existing views present

imilar applet layout that you desire. As with applet/business components/business objects you should name new views with a meaningful descriptive name prefixed

the project acronym. When you use a view within the application you need to define the view in the master reference data and associate responsibilities to this view,

erwise the view cannot be viewed. To do this in Siebel 7.7, navigate to Administration - Application > Views and create a new record with Name = [the name of

view]. Then navigate to Administration - Application > Responsibilities and associate the desired responsibilities to the view. Keep the Title bar, View tab bar and

reen menu option consistent for each view.

e scripting only if you cannot implement the required functionality through Siebel configuration. The use of script will always cause a performance hit on the

plication. If possible avoid scripting on applets; it is usually better to script on business components. Avoid writing scripts on events that occur frequently. Re-use

ipt as much as possible using business services. Schedule regular technical peer reviews to ensure that the scripting is efficient as possible. See my article Siebel

ripting Best Practices for more best practices related to Siebel scripting.

u should always enter comments in the "Comments" field for any objects that are modified. You should use a project standard for comments. The following is a

od project standard:

roject acronym]-[initials]-[date]-[description2]; [project acronym]-[initials]-[date]-[description1]

om the above you can see that when multiple changes are made to an object these are separated by ";". [project acronym] = The project acronym for the

plementation, [initials] = developers initials, [date] = date of the change, [descriptionx] = description of the change.

u should perform a full get on local developer databases on a regular basis. On my project we have a scheduled full get on our local database which is automated

ery week so that when we get in on Monday morning everything is fresh. Always use local database to make changes, never make changes on the server. The

lowing strategy can be used to determine whether to make changes locally first or whether to check out a project to make changes:

If you are unsure what changes need to be made and wish to try something to see if it works, then perform a get on the projects you require and lock these projects

ally. Then when you are satisfied take a Siebel archive (sif) of these changes and go to step 2 and merge these changes to the project.

If you are sure of what changes need to be made, then check out the project and make the changes.

Siebel Configuration Best Practices : Part 6




http://it.toolbox.com/blogs/siebel-answers/siebel-scripting-best-practices-26486http://it.toolbox.com/blogs/siebel-answers/siebel-scripting-best-practices-26486http://www.aired.in/2011/01/siebel-configuration-best-practices_253.htmlhttp://www.aired.in/2011/01/siebel-configuration-best-practices_14.htmlhttp://www.aired.in/2011/01/siebel-configuration-best-practices_13.htmlhttp://www.aired.in/2011/01/siebel-configuration-best-practices_2802.htmlhttp://www.aired.in/2011/01/siebel-configuration-best-practices_5066.htmlhttp://www.aired.in/2011/01/siebel-configuration-best-practices_14.htmlhttp://www.aired.in/2011/01/siebel-configuration-best-practices_253.htmlhttp://it.toolbox.com/blogs/siebel-answers/siebel-scripting-best-practices-26486

siebel configuration best practice

Documents