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

the business service will be repeatedly called for each record in the current instance context. See my article Siebel Scripting Best Practices for more best practices related to Siebel scripting.". then perform a get on the projects you require and lock these projects locally. [initials] = developers initials. Schedule regular technical peer reviews to ensure that the scripting is efficient as possible. Always use local database to make changes. .Avoid using InvokeServiceMethod in calculated fields. You should use a project standard for comments. You should perform a full get on local developer databases on a regular basis. Especially avoid setting Force Active = TRUE or Link Specification = TRUE for InvokeServiceMethod calculated fields. Avoid writing scripts on events that occur frequently. never make changes on the server.configuration. [descriptionx] = description of the change. 2. The following are Siebel configuration best practices to keep in mind when creating or modifying calculated fields on Business Components. . This obviously becomes exponentially worse if there are one or more queries within the business service as additional db calls are made each time the business service is invoked. 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. The use of script will always cause a performance hit on the application. . If you are sure of what changes need to be made.Avoid setting Force Active = TRUE or Link Specification = TRUE as this will result in the calculated field always being evaluated whenever the BC is instantiated. [project acronym] = The project acronym for the implementation. [project acronym]-[initials]-[date][description1] From the above you can see that when multiple changes are made to an object these are separated by ". Re-use script as much as possible using business services. then check out the project and make the changes. 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 possible avoid scripting on applets. it is usually better to script on business components. 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. This in turn results in any dependant fields being evaluated hence causing additional database calls. Whenever the calculated field is active it will make a business service call. The following is a good project standard: [project acronym]-[initials]-[date]-[description2]. If you are unsure what changes need to be made and wish to try something to see if it works. You should always enter comments in the "Comments" field for any objects that are modified. [date] = date of the change.

If many fields are updated prior to posting to the server then the BusComp_SetFieldValue event handler for each of these fields is queued. . This may result in Siebel firstly querying on the search specification/expression without the calculated field first and then again filter against this result set in memory against the calculated field. If you are using the COUNT or SUM function to determine if child BC records exist for a particular parent record then use the EXISTS function instead. Using the SUM and COUNT functions in calculated fields will result in an additional query generated for each record in the current instance. . this way the business service will not have to be repeatedly instantiated.Avoid using calculated fields with SUM and COUNT. If the field is the parent constraining field in a constrained picklist then Immediate Post Changes = TRUE for the parent field..Avoid using calculated fields in search specifications or search expressions. 1. This has potential for severe performance problems. We know that Immediate Post Changes should be set to TRUE for a field when the data is to be posted to the server immediately when a user updates a field and steps out of the field. If any of the below is not the case for the field then Immediate Post Changes should be set to FALSE. For the On Field Update Set n or On Field Update Invoked n property. The BC event handler server script BusComp_SetFieldValue will not be invoked as soon as the field is updated unless Immediate Post Changes = TRUE for the field. . set Cache = Y). This article discusses Siebel configuration best practices associated with setting the Immediate Post Changes field property. If Immediate Post Changes = FALSE then when the field is updated it will not post the data to the server immediately so the BusComp_SetFieldValue event script will be "queued" until the data is posted to the server. Here is a list of all the situations that I know of when Immediate Post Changes = TRUE would be required for a field. Again especially avoid setting Force Active = TRUE or Link Specification = TRUE for these aggregate function calculated fields as the additional query will be generated for every record whenever the BC is instantiated and queried. 4. The BC event handler server script BusComp_PreSetFieldValue will not be invoked unless Immediate Post Changes = TRUE for that field.If InvokeServiceMethod must be used in calculated fields then assess whether the business service can be cached (In Tools > Busines Service. 2. This will ensure that the child picklist values are updated as soon as the value of the parent field is changed. EXISTS has much better performance. setting Immediate Post Changes = TRUE for the fields used in the calculations will ensure that the property is invoked as soon as the field changes that cause the property to be invoked are made. 3.

7. MVL.Then when data is finally posted to the server all the queued field BusComp_SetFieldValue event handler script is executed. then these other fields need Immediate Post Changes = TRUE if you want to ensure that the read only rule will apply as soon as the dependant fields are updated. Also consider that Siebel have baselined and performance tested . user properties on an existing BC. 3. 6. If you have a Field Read Only Field user property that uses other field(s) in the calculations. If a Siebel Vanilla field has Immediate Post Changes. 8. The vanilla fields have been mapped to those joins/columns by siebel and may be used in the C++ code associated to the class of that BC. If a Toggle Applet is dependant on other field(s) then these field(s) should have Immediate Post Changes = TRUE if you want to ensure that the Toggle will occur as soon as the dependant field(s) are updated. user properties that are required? This may be better performance that cloning the entire BC. Dont change the column or join on standard vanilla fields. 5. 1. The Calculated Field will display updated value when the associated field data is posted to the server. Dont inactivate or delete any standard vanilla fields . If any Siebel vanilla fields have Immediate Post Changes = TRUE configured out of the box then do not change this property as this property would be set to enable vanilla functionality for that BC field.the specialized C++ code for the BC class may require these fields and could cause runtime error. The read only rule will still work without setting Immediate Post Changes = TRUE however the read only rule will only apply after the data has been posted to the server. if you are not requiring any specialized class functionality then change the class of the cloned BC to CSSBCBase. If you clone (copy) a BC consider if the BC really does need to be cloned. is it possible to create the BC from scratch only using the Fields. 2. Therefore if you need BusComp_SetFieldValue event handler to be invoked as soon as the field is updated then you need to set Immediate Post Changes = TRUE for the field. If any fields that are referenced in a Calculated Field do not have Immediate Post Changes = TRUE then the Calculated Field value may not be updated as soon as the associated fields are updated. This article discusses Siebel configuration best practices associated with modifying Siebel vanilla objects. MVLs. Force Active or Link Specification set to TRUE DO NOT change this property as it would be used in the underlying C++ code for that BC. CSSBCBase class allows user properties (such as Named Method N) to be invoked which other BC classes can not. 4. If the cloned BC has a class other then CSSBCBase ask yourself why you are cloning the BC. there is usually a lot of fields.

S_CONTACT) rather than using the 1:1 extension table (eg. Therefore we had to re-map our existing fields on these columns . Also we just finished a Siebel upgrade and found complications where some of the extension columns (ATTRIB_XX) were now mapped to Siebel fields in the new Siebel version. Changing the underlying columns on vanilla fields could adversely affect performance as appropriate indexes may not be used any longer. I have found that if you need to create a new custom extension column you are usually better off creating this on the base table (eg. When updating and saving records having fields on the extension table will result in additional INSERT or UPDATE statements required for the extension table. 5.their product with the vanilla out of the box BC fields/columns. S_CONTACT_X).