Siebel Configuration Best Practices,Siebel Configuration Recommended Practices,Siebel Configuration Best Practices Interview Questions This article discusses

best practices for Siebel configuration. You 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 application. You should change the application when the cost of changing the business process is greater than changing the Siebel application. It is 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 object definitions wherever possible. This will make the application easier to maintain and upgrade. General rule of thumb is to modify existing Siebel repository objects or 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. You 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 components, 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 objects and then edit the business object level, then edit the UI layer objects). For business components you should take care when copying business components. You should not define system fields on the business components. You should name 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 that 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 can be easily upgraded. For 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 applets. 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 meaningful descriptive name and prefix with the project name acronym. For 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 a similar applet layout that you desire. As with applet/business components/business objects you should name new views with a meaningful descriptive name prefixed by 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, otherwise 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 the view]. Then navigate to Administration - Application > Responsibilities and associate the desired responsibilities to the view. Keep the Title bar, View tab bar and Screen menu option consistent for each view. Use scripting only if you cannot implement the required functionality through Siebel configuration. The use of script will always cause a performance hit on the application. 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 script 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 Scripting Best Practices for more best practices related to Siebel scripting. You 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 good project standard: [project acronym]-[initials]-[date]-[description2]; [project acronym]-[initials]-[date]-[description1] From 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 implementation, [initials] = developers initials, [date] = date of the change, [descriptionx] = description of the change. You 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 every 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 following strategy can be used to determine whether to make changes locally first or whether to check out a project to make changes: 1. 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 locally. 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. 2. 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 Siebel Configuration Best Practices : Part 5 Siebel Configuration Best Practices : Part 4 Siebel Configuration Best Practices : Part 3 Siebel Configuration Best Practices : Part 2