[翻译]Siebel Configuration Best Practices - Part 1

MicrosoftInternetExplorer402DocumentNotSpecified7.8Normal0

原文：http://it.toolbox.com/blogs/siebel-answers/siebel-configuration-best-practices-26488

This article discusses Siebel Configuration Best Practices. 
本文讨论Siebel配置最佳实践

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. 
一般情况下，对标准siebel的改动尽量做到最少； 则可以减少可能的意外错误。只要可能，你应该使用siebel定义好的对象。这样可以使siebel更容易维护和升级。 经验法则：修改或复制siebel仓库已有的对象比新建一个对象好。也不要删除或失效现有的siebel对象，因为它们可能被其他对象引用。

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). 

计划的时候需要从上到下考虑siebel项目（也就是说：先确定UI和Siebel应用，然后确定BO，BO的修改需求，然后确定这会导致在数据层发生的变化）。 在实施的时候应该从下到上(也就是说，先编辑数据层对象，然后编辑BO层，然后编辑UI层对象)

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. 

复制bc时要注意，不要在上面定义system fields；你应该给所有新的bo和bc名字添加前缀来区分项目，名字应该有意义的描述。如果你复制bc，应该在Upgrade Ancestor field属性中指定原始bc的名称，这样比较容易升级。

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. 
复制applet时要注意，只有在需要对applet进行较大改动的时候才复制。一般情况下最好修改现有的applet。重用applet是最好的操作模式，则可以节约很多时间和操作。和bc/bo一样，用有意义的名字为applet命名并添加项目缩写前缀

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. 

对于View，通常修改现有views的标题和applet层。如果没有现存的显示类似applet层的view而你希望创建一个新的。和前面一样，也应该为新view建一个有意义的用项目缩写为前缀的名字。当你准备在应用中使用这个view时，你必须为view在管理中定义和指定关联职责，否则是看不到的。在Siebel7.7中导航到管理--应用--视图，创建一条记录Name=视图名字。然后导航到管理--应用--职责并为view指定需要的职责。在每个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. 
只有在你无法通过配置来实现功能需求的情况下才使用脚本，脚本会影响应用性能。避免在频繁被使用的事件上写脚本。尽可能使用bs重用脚本，定期安排技术互审来确保代码尽可能地高效。参见我的文章《siebel脚本最佳实践》了解更多和siebel脚本相关的最佳实践。

You should always enter comments in the "Comments" field for any objects that are modified. 

你应该总是为被修改的对象的“Comments”字段添加注释

You should use a project standard for comments. The following is a good project standard: 

你应该使用项目的注释规范.下面是一个好的项目规范： 
[project acronym]-[initials]-[date]-[description2];

[project cronym]-[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. 
从上面的注释你可以看到用分号隔开的对象的多次改动的记录。 [project acronym] = 项目的缩写，[initials] = 开发者缩写， [date] = 修改日期, [descriptionx] =修改描述

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: 
你应该按照确定好的规则定期同步本地的开发数据库。在我的项目中，我们有一个每周自动完整同步一次本地数据库的计划任务，这样每周一早上所有的数据都是最新的。始终只更改本地数据库，从不更改服务器。 下面的策略可以确定是否在本地先更改还是先check out项目来更改：

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. 
如果你不确定需要修改什么并希望尝试看看是否正确，那么应该get你需要的项目并在本地lock。然后，当你在更改后获得一个满意的siebel档案文件并进行第2步来合并项目的修改。

2. If you are sure of what changes need to be made, then check out the project and make the changes. 
如果你确信需要做的改动，那么就check out项目并应用更改。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/158493/viewspace-690195/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/158493/viewspace-690195/