Blog de Gabriel Bravo: Buenas prácticas de configuración en Oracle Siebel CRM

Tomado y traducido de: Weir Josué | 08 de agosto 2008 | http://it.toolbox.com/blogs/siebel-answers/siebel-configuration-best-practices-26488
Siebel Scripting Best Practices Resource Document – Oracle Support Doc ID 477766.1

Este artículo discute algunas buenas prácticas para la configuración Siebel.
Es necesario evaluar si el proceso de negocio se puede cambiar, ya que es más económico por lo general cambiar el proceso de negocio en lugar de cambiar la aplicación. Se debería cambiar la aplicación cuando el costo de cambiar el proceso de negocio es mayor que el cambio de la aplicación Siebel.
Normalmente es mejor hacer cambios mínimos a la aplicación Siebel estándar, lo que reducirá la posibilidad de errores inesperados, etc. Se debería utilizar las definiciones de objetos Siebel existentes siempre que sea posible. Esto hará que la aplicación sea más fácil de mantener y actualizar. La regla general es modificar los objetos del repositorio Siebel o copiar objetos existentes en el repositorio en lugar de crear nuevos objetos. Además, no eliminar o desactivar objetos existentes de Siebel, ya que pueden ser referenciados por otros objetos.
Se debe planificar el proyecto de Siebel de arriba hacia abajo (es decir, determinar la interfaz de usuario y la aplicación Siebel, a continuación, determinar los cambios necesarios en los objetos de negocio y los Business Components, a continuación, determinar los cambios que resultan en el nivel de datos). Usted debe implementar (configurar) el proyecto de Siebel de abajo hacia arriba (es decir, editar los objetos a nivel de datos, editar a continuación el nivel de objetos de negocio, y finalmente modifique los objetos de la capa de interfaz de usuario).

BUSINESS COMPONENTS

Para Business Components se debe tener cuidado cuando se copian.
No se deberían definir los campos de sistema en los Business Components.
Se debería nombrar a todos los objetos de negocio y los Business Components con un prefijo que identifica el proyecto y el nombre que le asigne al objeto debe ser descriptivo y significativo a ese objeto.
Asegúrese, cuando se copia un Business Component, de especificar el nombre del Business Component original en el campo Upgrade Ancestor para que el objeto pueda ser fácilmente actualizado

APPLETS

Para Applets existentes se debe tener cuidado al copiarlos, sólo se deberían copiar cuando los cambios que se tienen que hacer sean importantes.
Por lo general, lo mejor es modificar los applets existentes.
Reutilizar los applets existentes es la mejor metodología. Esto ahorra mucho tiempo y mantenimiento.
Al igual que con Business Components / Business Objects, nombre los applets con un nombre descriptivo, significativo y un prefijo con el acrónimo del proyecto.

VISTAS

Para Vistas existentes, por lo general, se deberían modificar solo los títulos y el diseño de applets.
Se deberían crear nuevas vistas, si ninguna otra vista presenta un diseño de Applets similar al que se desea.
Al igual que con Applets, Business Components y Business Objects, se debería nombrar las nuevas Vistas con un nombre descriptivo, significativo y precedido de la sigla del proyecto.
Cuando se use una vista dentro de la aplicación es necesario definir la vista en la referencia de los datos maestros y asociar responsabilidades a esta Vista, de lo contrario la vista no se podrá ver.
Para hacer esto en Siebel 7.7, vaya a Administración -> Vistas de aplicación y crear un nuevo registro con nombre = [el nombre de la vista]. A continuación, vaya a Administración -> Responsabilidades de aplicación y asociar las responsabilidades que desee a la vista. Mantenga la barra de título (Title Bar), barra de pestañas (View Tab Bar) y la opción Screen Menú consistentes para cada vista.

SCRIPTING

Joshua Weir | Aug 8, 2008| http://it.toolbox.com/blogs/siebel-answers/siebel-scripting-best-practices-26486

El objetivo es minimizar los scripts — escribiéndolo solo cuando sea necesario, y escribiéndolo una sola vez !!
Implemente scripts SOLO si no se puede implementar la funcionalidad requerida a través de la configuración estándar de Siebel.
El uso de scripts siempre causará un impacto en el rendimiento de la aplicación.
Unificar el lenguaje de programación (eScript o VB), no tener la programación revuelta.
Saber cuando usar Browser o Server Scripts
- Browser script es recomendado para:
  - Comunicación con el usuario
  - Interacción con aplicaciones del escritorio del PC
  - Validación de Datos y manipulación limitada al registro actual
- Server scripts son recomendados para:
  - Operaciones de Consulta, inserción, actualización y borrado
  - Acceder a los datos mas allá del registro actual
Si es posible evite scripts en Applets, por lo general es mejor programar scripts en los Business Components.
Evite escribir scripts en eventos que se producen con frecuencia.
Reutilice scripts tanto como sea posible utilizando los Business Services.
Programe revisiones técnicas periódicas con el equipo de trabajo para garantizar que los scripts se programen de la manera más eficiente posible.
Utilice siempre TheApplication para llamar la aplicación, como declaración de una variable global para representar a la aplicación (p.e., var theApp = TheApplication()) no es recomendado por Siebel. El uso de esta variable puede causar pérdidas de memoria, reducir el rendimiento o un comportamiento impredecible.
Las funciones definidas por el usuario deben ser Forward Declared en las declaraciones generales de cada script. Esto evita errores de compilación que pueden surgir si las funciones de llamada no están en orden alfabético. El compilador compila todas las funciones alfabéticamente, entonces, si una función llama a otra que está más adelante alfabéticamente, el compilador no reconoce esta segunda función y por lo tanto, falla.
Tenga cuidado al agregar scripts para los Business Components ya que este código aplica a lo largo de la aplicación, a través de Applets y Vistas. Si una determinada pieza de código se necesita a nivel de Business Components, pero es restrictivo a ciertas situaciones, y como se expone en varias Vistas, entonces, asegúrese de limitar el tratamiento a través de una condición apropiada.
El uso de ‘With’ se recomienda por Siebel, ya que permite el código se pueda cambiar más rápido y es una manera más legible de agrupar operaciones dentro del mismo Business Component. El uso de ‘With’ también presenta una ligera mejora del rendimiento.
El uso de variables puede hacer el mantenimiento del código más fácil debido a la facilidad de lectura. Sin embargo el uso excesivo de variables aumenta la cantidad de operaciones que se tienen que realizar y pueden reducir el rendimiento un poco.
Siebel no recomienda el uso de ‘Empty’. ‘Empty’ es una variable no definida que es asignada como de tipo Variant. Un Variant se establece inicialmente como una cadena vacía (‘’), lo que significa que cualquier scripts que esté utilizando este término no se verá afectados. Sin embargo, es mejor la práctica asignar (‘’) en lugar de ‘Empty’ a cualquier cadena que usted necesite hacer NULL. El uso de ‘Empty’ impide a Option Explicit de comprobar todas las demás variables que están declaradas correctamente.
El uso de ‘ActivateField’ antes de una consulta es equivalente a ‘SELECT’ en una sentencia SQL. El uso de ‘ActivateField’ en scripts Siebel puede ser confuso y se debe minimizar tanto como sea posible ya que esto tiene un impacto en el rendimiento. Sin embargo no hay nada peor que recibir una excepción: ‘…was not active…’. Cuando Active campos tenga en cuenta que:
- Los campos de sistema (Id, Created, Created By, Last Updated, Last Updated By) siempre están “Force Active”.
- Los campos que tienen Force Active=Y en el Business Component siempre están “Force Active”.
- Los campos que tienen Link Especificación=Y en el Business Component siempre están o deben estar “Force Active”.
- Los campos que se incluyen en la definición de un Applet en una Vista Activa, si está enlazado a una Web Template Item y el tienen la propiedad ‘Show In List’ o la propiedad ‘Visible’ de un control está TRUE. Si el usuario elimina la columna de lista de ‘columnas mostradas’ en el List Applet, el campo ya no se activa después de la siguiente consulta.
- Los campos que hacen parte de la expresión de un campo calculado, se activan cuando el campo calculado se recupera para su uso en un Applet activo.
‘ActivateField’ sólo debe utilizarse antes de la instrucción ‘ExecuteQuery’ para asegurarse de que un campo en particular se activará y se incluirá en la consulta ‘SELECT’ equivalente. Por lo tanto ‘ActivateField’ no debería ser utilizado con ‘this’/‘Me’ (p.e., this.ActivateField (‘Campo1’)). Esto se debe a que no se suele realizar una consulta en el contexto actual, ya que esto cambiaría la consulta en que está mostrando al usuario. Siebel actualmente especifica que el uso de ActivateField con ‘this’ posiblemente puede causar daños en los datos.
Al realizar una consulta, utilice siempre ‘ForwardOnly’ después de ‘ExecuteQuery’ para fijar la posición del cursor a menos retroceder en los registros devueltos. Esta es una consulta mucho más rápida porque no crea un caché para almacenar los registros anteriores.
Si usted tiene un conjunto de tres o más ‘If Else If’, mejor utilice sentencias ‘Switch Case’ en su lugar. Esto simplifica el código y mejora el rendimiento.
Es una de las mejores prácticas en Siebel usar en los scripts la sentencia ‘Try / Catch / Finally’. Esto asegurará que las excepciones son capturados y manipulados de manera adecuada y las instancias de variables de objeto siempre son destruidos en el bloque Finally (que reduce las posibilidades de pérdida de memoria) dado que el código del bloque finally siempre se ejecuta. Tenga en cuenta que las variables de objeto deben ser destruido en el orden inverso al que se crea una instancia.
Reducir el número de consultas realizadas tanto como sea posible. Siebel mantiene relaciones padre-hijo definidas en los links automáticamente por lo que no hay necesidad de consultar al Business Components hijo para obtener los registros de un padre dado. Hacer uso de comandos como, ‘GetParentBusComp’ para acceder al registro principal, en lugar de volver a realizar consultas para recuperar registros.
No crear objetos (BCs y BOs) si usted necesita una referencia al BC y BO del contexto actual. Hacer uso de las variables de aplicación por defecto ‘BusComp’ y ‘BusObject’ en esta situación.
El uso de ‘ActiveBusObject’, ‘ActiveBusComp’ y ‘ActiveApplet’ debe ser limitado, porque el objeto representado por esas declaraciones pueden cambiar en función del Applet activo. Siebel recomienda el uso del objeto ‘this’ para eScript (‘Me’ para Siebel VB) siempre que sea posible. ‘Me’/ ‘this’ representa el objeto en el que está escrito el código, ‘Active???’ representa el objeto detrás del applet activo actual. El uso del ‘Me’ / ‘this’ es el método más seguro, especialmente durante el desarrollo cuando, no todo está claro cual applet estará activo en un momento dado. También permite una más fácil interpretación de los scripts, dado que el objeto ‘base’, representado por el ‘Me’ / ‘this’ no cambiará nunca. El uso de ‘Me’ / ‘this’ también elimina la necesidad de almacenar el BusObject activo y BusComp activo en variables, de manera que no necesitan ser declaradas explícitamente y destruidos al final de la función.
Todo el código debe indentarse lógicamente, incluidos los comentarios que describen de manera eficiente lo que el sccript está haciendo. Cada nuevo script debe incluir un encabezado de comentario que describa: Autor, Fecha, Descripción e Historial de las versiones del script.
Eliminar todos los scripts vacíos que alguna vez contuvieron texto. Eliminar todo, incluyendo el encabezado de la función y el pie. De lo contrario la aplicación irá a ese script cuando se dispare el evento y el rendimiento se verá afectada ligeramente. Si se desea guardar registro del código obsolete antes de borrarlo, puede hacer un export desde Siebel Tools para guardar una copia del script. Para exportaar un script a un archivo de texto, abra la ventana de edición de codigo para el objeto en cuestion, y seleccione File > Export.
Mantenga el uso de scripts en los Applets al mínimo que sea posible. Tratar de cumplir con los requerimientos del negocio configurando en Siebel Tools siempre que sea posible y, por lo general implemente scripts para funcionalidad de poca importancia, cuando una funcionalidad determinada no pueda ser satisfechas mediante la configuración declarativa.
Para scripts de inserciones de nuevos registros o actualización de datos, se debe tener en cuenta de hacer un commit explícito de lo contrario los datos podrían perderse.
Ubique el código en el controlador de eventos correcto:

BusComp_PreSetFieldValue	Validación a nivel de campos
BusComp_PreWriteRecord	Validación a nivel de registros
BusComp_SetFieldValue	Acciones disparadas por campos
BusComp_WriteRecord	Acciones diparadas por registros Ejemplo: Sincronizar dos BCs or
BusComp_PreQuery	Control de código sobre SearchSpecs

Cuando se va a eliminar registros en un script basado en una consulta particular, asegúrese de usar un bucle while en lugar de una sentencia ‘if’ dado que la condición ‘if’ eliminará un solo registro cuando se necesita eliminar varios registros.

Manera Incorrecta:

bcPositionMVG.ClearToQuery();
bcPositionMVG.InvokeMethod("SetAdminMode","TRUE");
bcPositionMVG.SetSearchExpr("[Id] <> '0-5220'");
bcPositionMVG.ExecuteQuery();

// The first record is identified and deleted. However,
// subsequent child records are not deleted.
if ( bcPositionMVG.FirstRecord()){
  bcPositionMVG.DeleteRecord();
}

Manera Correcta:

bcPositionMVG.ClearToQuery();
bcPositionMVG.InvokeMethod("SetAdminMode","TRUE");
bcPositionMVG.SetSearchExpr("[Id] <> '0-5220'");
bcPositionMVG.ExecuteQuery();

while ( bcPositionMVG.FirstRecord()){
    bcPositionMVG.DeleteRecord();
}

Utilice el método DeleteRecord correctamente
- DeleteRecord implícitamente mueve el puntero de registro al siguiente registro en el conjunto de registros. Una llamada a NextRecord después DeleteRecord hace que el puntero de registro se mueva dos veces. Esto significa que la aplicación Siebel salta un registro en el conjunto de resultados. Si se trata de la eliminación de registros dentro de un bucle, la aplicación Siebel saltaría “un registro de por medio”. El siguiente ejemplo ilustra el enfoque recomendado para la eliminación de registros dentro de un bucle.
```
while(BC.FirstRecord()){
  BC.DeleteRecord();
}
```
Implementar Técnicas Apropiadas de Depuración
- Es esencial que se entienda como depurar aplicaciones Siebel. Hay cuatro técnicas básicas:
  - Use alertas o RaiseErrorText para mostrar mensaje en cajas de texto
  - Crear un archivo usando Trace o mediante scripts
  - Usar el Siebel Debugger
  - Usar niveles de log en los object manager
Saber cuándo utilizar el contexto actual o un nuevo contexto en un script de servidor
- Actual (o la interfaz de usuario) trata con los objetos que la Aplicación Siebel creó para soportar los datos que están disponibles actualmente en pantalla para el usuario.
- Un Nuevo contexto (o no-UI) es un conjunto de objetos instanciados en un script que no tienen ningún vínculo con los objetos o datos que el usuario está viendo actualmente.
- Mantener estos dos conceptos claros es importante porque el usuario puede ver programáticamente la manipulación de los datos si se utiliza el contexto equivocado.
  - Utilice el contexto actual para:
    - Acceso a los datos con los que el usuario está trabajando actualmente
    - Realizar un proceso que debe ser visible para el usuario
  - Use un nuevo contexto para:
    - Consultar “invisiblemente” un Business Component visible.
    - Usar un Business Component en un contexto (Business Object) diferente
  - Use el Ámbito mas pequeño posible para las variables:
    - Los desarrolladores crean con frecuencia variables a nivel de instancia que se puede acceder por muchos métodos dentro de un objeto. Esto se hace a nivel de aplicación para que cualquier script pueda tener acceso a los objetos. Si bien esto es bueno para propósitos de crear instancias de un objeto sólo una vez, es una mala práctica por cuatro razones:
      - Las Reglas de encapsulación se violan usualmente.
      - Los scripts se “pisan” unos a otros.
      - No hay ningún evento que garantice que los objetos son destruidos.
      - Es difícil “comprender” el alcance o estado de las variables, ya son instanciadas en un método y accedidas en otros.
    - Es mucho mejor declarar y usar objetos donde se necesitan y pasarlos como parámetros a otros métodos
  - Instanciar Objetos solo cuando sea necesario:
    - Crear instancias del objeto en función de las necesidades. Crear instancias del objeto que se necesitan en función del resultado de una evaluación. De lo contrario, el código puede crear instancias de objetos no utilizados que pueden afectar negativamente el rendimiento.
    - Orden correcto
      - Evaluar la condición
      - Crear objetos
      - Usar los objetos
    - Orden incorrecto
      - Crear objetos
      - Evaluar la condición
      - Usar los objetos
  - Destruir variables de objetos cuando ya no sea necesario
    - Las pérdidas de memoria son un problema común, por lo que cuando un script crea una referencia de objeto, que el script mismo deberá destruir antes de abandonar el método.
    - Las referencias a objetos son los siguientes:
      - Objetos COM
      - Property Sets
      - Business Services
      - Business Components
      - Business Objects
      - Applets
  - Compruebe que los campos están activos antes de utilizarlos
    - Llamar GetFieldValue o SetFieldValue en un campo inactivo puede conducir a pérdida de datos o que lógica vaya por mal camino
  - Utilice el Modo de Vista (View Mode) adecuada para consultas
    - La configuración del modo de vista controla formulación de la cláusula WHERE de SQL que la aplicación Siebel envía a la base de datos mediante el uso de la visibilidad de equipo o posición para limitar los registros disponibles en el Business Component consultados en el script.
    - Configurar una consulta a modo de visibilidad AllView da al usuario acceso a todos los registros, lo que puede ser diferente de el View Mode de la vista actual en la interfaz de usuario. Por ejemplo, un usuario puede tener visibilidad SalesRep en la interfaz de usuario, mientras que el script va a dar al usuario visibilidad a todo. Esto daría al usuario acceso a los registros que el usuario no necesite tener acceso o no debería poder acceder.
    - Para evitar este problema, utilice el método GetViewMode para determinar la visibilidad del usuario, para que pueda aplicar el mismo modo de vista en la consulta ejecutada por el script.
    - Ejemplo eScript:
```
with (bcAcct){
   SetViewMode(this.GetViewMode());
   ...
```
  - Consulte sólo columnas indexadas:
    - Para ayudar al motor de base de datos en forma eficiente la consulta y ordenamiento de datos, asegúrese de que la Search y Sort Specification hagan referencia a columnas indexadas siempre que sea posible. El ordenamiento o búsqueda en campos no indexados pueden tener efectos perjudiciales sobre el rendimiento de base de datos, especialmente en las tablas de gran tamaño, ya que produce exploraciones de tablas y tablas temporales en el plan de ejecución de SQL.
    - Para un mejor rendimiento, asegúrese de que tales especificaciones cubran las columnas clave del índice deseable, así como a cubrirlas en el orden exacto de la secuencia del índice. Esto fuerza al motor de base de datos para utilizar el índice y puede evitar ordenamientos físicos innecesarios en las tablas temporales.
  - Utilizar el método Associate para crear registros en las Tablas Intersección
    - Utilice el método Associate para crear registros en una tabla de cruce. Este método de forma automática y correctamente crea nuevos registros. Los desarrolladores, sin darse cuenta de este método, con frecuencia tratan de implementar la funcionalidad con muchas líneas de secuencia de comandos cuando una sola llamada al método Associate va a funcionar. Ejemplo:
```
var lBC_mvg = this.GetMVGBusComp(“Sales Rep”);
var lBC_associate = lBC_mvg.GetAssocBusComp();
with(lBC_associate){
  ClearToQuery();
  SetSearchSpec(“Id”,SomeRowId);
  ExecuteQuery(ForwardOnly);
  if(FirstRecord()) Associate(NewAfter);
}
```
  - Utilice valores dinámicos
    - Utilice valores dinámicos, en vez de valores “Quemados”, siempre que sea posible. Esto es particularmente importante para los valores que pueden cambiar a menudo, porque debe volver a compilar y volver a implementar los cambios a los valores “Quemados”. Alternativamente, usted puede almacenar los valores en la tabla de Listas de Valores (LOV) o de otras tablas de bases de datos y consulta para ellos en tiempo de ejecución. Esto es el lo más adecuado cuando hay un sólo valor dinámico o una lista de valores pequeña que usted necesita para consultar en el script. Si usted tiene un valor o una lista corta que quepa en una lista de valores, utilice la función LookupValue para recuperar el valor. Usando LookupValue es especialmente importante si ha implementado una lista multilingüe de Valores (MLOV). Ejemplo:
```
var statusList;var moreRecords;
var boLOV;
var bcLOV;
boLOV =TheApplication().GetBusObject("List Of Values");
bcLOV = boLOV.GetBusComp("List Of Values");
bcLOV.ClearToQuery();
bcLOV.SetSearchSpec("Type","SR_STATUS");
bcLOV.SetSearchSpec("Active","Y");
bcLOV.ExecuteQuery(ForwardOnly);
if (bcLOV.FirstRecord()){
   statusList = bcLOV.GetFieldValue("Name");
   moreRecords = bcLOV.NextRecord();
   while (moreRecords != 0){
     statusList = statusList + " OR ";
     statusList = statusList + bcLOV.GetFieldValue("Name");
     moreRecords = bcLOV.NextRecord();
   }
}else{
   statusList = "";
}
```

COMENTARIOS

Siempre se debería registrar comentarios en el campo Comments de los objetos que se modifican.
Se debe utilizar un estándar de proyecto para comentarios.

El siguiente es una recomendación:

[Acrónimo del proyecto] - [Iniciales] - [Fecha yyyy-mm-dd] - [No Requerimiento] - [Descripción 1];[Acrónimo del proyecto] - [iniciales] - [fecha yyyy-mm-dd] – [No Requerimiento] - [Descripción 2]

ZZZ-GBRAVO-2010/11/24-GAP399: Se recomienda este estándar de comentario para los objetos modificados.

De lo anterior se puede ver que cuando los cambios se realizan varias vecs a un objeto de estas están separadas por “;”
Dado que se dispone de dos maneras de iplementar los comentarios (// y /**/), se puede implementar la práctica de usar uno para describir en lenguaje natural los datos del script, y el otro modo para inutilizar código.

BASES DE DATOS LOCALES

Se debería realizar con frecuencia un Full Get de las bases de datos de locales.
Es usual programar un Full Get de las bases de datos locales automáticamente todas las semanas para que el lunes por la mañana esté “fresca”.
Utilice siempre la base de datos local para hacer cambios, nunca hacer cambios directamente en el servidor.
La siguiente estrategia se puede utilizarse para determinar si debe hacer cambios a nivel local primero o hacer un Check Out a un proyecto para realizar cambios:

Si no está seguro de qué cambios deben hacerse y que desean probar algo para ver si funciona, a continuación, realizar un check out de los proyectos que necesita y bloquear estos proyectos a nivel local. Entonces, cuando se asegure la configuración deseada, hacer un archivo Siebel (SIF) de estos cambios y vaya al paso 2 y fusionar estos cambios en el proyecto.
Si está seguro de qué cambios deben hacerse, a continuación, hacer check out del proyecto e importar los cambios.

CAMPOS CALCULADOS

Joshua Weir | 27 de octubre 2009 | http://it.toolbox.com/blogs/siebel-answers/siebel-configuration-best-practices-part-2-calculated-fields-35006
Las siguientes son algunas mejores prácticas de Siebel de configuración a tener en cuenta al crear o modificar campos calculados en Business Components.

Evite asignar Force Active = TRUE o Link Specification = TRUE ya que esto se traducirá en que el campo calculado siempre se estará evaluando cada vez que el BC sea instanciado. Esto, a su vez se traduce en todos los campos dependientes se evalúen, por tanto causando consultas adicionales base de datos.
Evite el uso de InvokeServiceMethod en los campos calculados. Sobre todo evitar asignar Force Active = TRUE o Link Specification = TRUE para campos calculados que incluyen InvokeServiceMethod. Cada vez que el campo calculado esté activo, hará una llamada al Business Service, el Business Service será llamado en repetidas ocasiones para cada registro en el contexto actual. Obviamente, esto se vuelve exponencialmente peor si hay una o más consultas dentro del Business Service dado que habrá llamadas adicionales a la Base de Datos que se hacen cada vez que se invoca el Business Service.
Si InvokeServiceMethod debe ser utilizado en campos calculados entonces, evalúe si el Business Service se puede almacenar en caché (en Tools > Object Explorer > Busines Service, Cache = Y), de esta manera el Busines Service no tendrá que ser instanciado repetidamente.
Evite el uso de campos calculados con SUM y COUNT. Uso de las funciones SUM y COUNT en campos calculados se traducirá en una consulta adicional generada para cada registro de la instancia actual. Una vez más sobre todo evitar la configuración de Force Active = TRUE o Link Specification = TRUE para estas funciones de campos calculados agregados, dado que una consulta adicional se generará para cada registro cada vez que el BC sea instanciado y consultado. Si está utilizando el la función SUM o COUNT para determinar si existen registros en el BC hijo para un registro padre en particular, entonces en su lugar utilizar la función EXISTS, esta función tiene un rendimiento mucho mejor.
Evite el uso de campos calculados en Search Specifications o Search Expressions. Esto puede resultar en que Siebel primero, consulte las Search Specifications o Search Expressions antes que el campo calculado y, de nuevo filtre este conjunto de resultados en la memoria contra el campo calculado. Esto tiene el potencial para problemas graves de rendimiento.

IMMEDIATE POST CHANGES

Weir Josué | 27 de octubre 2009 | http://it.toolbox.com/blogs/siebel-answers/siebel-configuration-best-practices-part-3-immediate-post-changes-35007
Este artículo describe algunas mejores prácticas de configuración de Siebel asociadas con la asignación de la propiedad Immediate Post Changes
Sabemos que la propiedad Immediate Post Changes se debe establecer en TRUE para un campo cuando los datos se envían al servidor inmediatamente cuando un usuario actualiza un campo y sale del campo. Aquí está una lista de todas las situaciones cuando Immediate Post Changes = TRUE se requiere para un campo. Si cualquiera de las siguientes situaciones no es el caso para el campo entonces la propiedad Immediate Post Changes se debe establecer en FALSE.

Si el campo es el campo restrictivo padre de un picklist restringido entonces Immediate Post Changes = TRUE para el campo primario. Esto asegurará que los valores de lista de selección hijo se actualizan tan pronto como el valor del campo padre haya cambiado.
Para las BusComp User Prop On Field Update Set n o On Field Update Invoked n, configurar Immediate Post Changes = TRUE para los campos utilizados en los cálculos, esto asegurará que la propiedad sea invocada tan pronto como se hagan cambios en el campo que causa la propiedad.
El controlador del evento de servidor BusComp_PreSetFieldValue no se invocará a menos que Immediate Post Changes = TRUE para ese campo.
El controlador del evento de servidor BusComp_SetFieldValue no se invocará tan pronto el campo se actualize a menos que Immediate Post Changes = TRUE para el campo. Si Immediate Post Changes = FALSE entonces cuando se actualice el campo no va a publicar los datos al servidor de forma inmediata, por lo que el script de eventos BusComp_SetFieldValue será puesto en cola hasta que los datos sean enviados al servidor. Si muchos campos se actualizan antes de su publicación en el servidor entonces, el controlador de eventos BusComp_SetFieldValue para cada uno de estos campos será puesto en la cola. Luego, cuando los datos finalmente se envían al servidor toda la cola de scripts del controlador de eventos BusComp_SetFieldValue se ejecutarán. Por lo tanto si usted necesita que el controlador de eventos BusComp_SetFieldValue sea invocado inmediatamente cuando el campo se actualiza, es necesario configurar Immediate Post Changes = TRUE para el campo.
Si se tiene una Field Read Only Field User Property que utiliza otro campo(s) en los cálculos, estos otros campos necesitan Immediate Post Changes = TRUE, si desea asegurarse que la regla de sólo lectura se aplicará tan pronto como los campos dependientes se actualicen. La regla de sólo lectura seguirá funcionando sin establecer Immediate Post Changes = TRUE sin embargo, la regla de solo lectura sólo aplicará después que los datos se hayan publicado en el servidor.
Si un Applet Toogle depende de otro campo(s) entonces estos campo(s) debe tener Immediate Post Changes = TRUE si desea asegurarse de que el Toogle se producirá tan pronto como el campo dependiente(s) se actualicen
Si todos los campos que son referenciados en un campo calculado no tienen Immediate Post Changes = TRUE entonces el valor calculado del campo no se puede actualizar inmediatamente los campos asociados se actualicen. El valor del campo calculado aparecerá actualizado cuando los datos de los campos asociados se publican en el servidor.
Si los campos vainilla Siebel tienen Immediate Post Changes = TRUE configurado, entonces, no cambie esta propiedad ya que esta propiedad se establecío para habilitar funcionalidad vainilla para ese campo del Business Component.

MODIFICACIÓN DE SIEBEL VAINILLA

Weir Josué | 27 de octubre 2009 | http://it.toolbox.com/blogs/siebel-answers/siebel-configuration-best-practices-part-4-modifying-siebel-vanilla-35025
Este artículo describe algunas buenas prácticas de configuración Siebel asociadas con la modificación de objetos Siebel vainilla.

Si un campo de Siebel Vainilla tiene configurado Immediate Post Changes, Force Active o Link Specification en TRUE, NO CAMBIE ESTA PROPIEDAD, ya que se utilizarían en el código C++ subyacente para el Business Component
Si clona (copia) un Business Component, considere si el BC realmente tiene que ser clonado, por lo general hay una gran cantidad de campos, MVL, User Properties; es posible creación el Business Component a partir de cero utilizando únicamente los campos, MVLs, User Properties que se requieren?. Esto puede tener un mejor rendimiento que la clonación de todo el Business Component. Si el Business Component clonado tiene una clase distinta a CSSBCBase entonces debe preguntarse por qué está clonando el Business Component, si no se requiere ninguna funcionalidad de la clase especializada entonces, cambie la clase del Business Component clonado a CSSBCBase. CSSBCBase permite User Properties (tal como Named Method N) para invocar que otras clases no pueden.
No inactivar o eliminar los campos vainilla estándar - el código C++ especializado para la clase del Business Component pueden requerir estos campos y podría provocar error de tiempo de ejecución.
No cambiar columnas o joins en los campos vainilla estándar. Los campos vainilla se han mapeado a estos joins / columnas por Siebel y puede ser utilizados en el código C++ asociado a la clase de ese Business Component. También considere que Siebel ha sido estabilizado su producto y probado en su desempeño con los campos vainilla. Cambiar las columnas subyacentes en los campos vainilla podría afectar negativamente el rendimiento y entonces los índices adecuados no podrán volver a ser utilizados
Se ha visto que si se necesita crear una nueva columna extensión personalizada, suele ser mejor la creación de esta en la tabla base (p.e., S_CONTACT) en lugar de usar la tabla extensión 1:1 (p.e., S_CONTACT_X). Al actualizar y guardar los registros que tienen campos en la tabla extensión se traducirá en INSERT o UPDATE adicionales necesarios para la extensión de la tabla. También en actualizaciones de Siebel se han encontrado complicaciones en algunas de las columnas de extensión (ATTRIB_XX) que ahora se mapean a campos de Siebel en la nueva versión. Por lo tanto, se tuvo que volver a mapear los campos existentes en estas columnas.
Para extender una tabla se debe tener en cuenta que:
- Se extiende de la tabla base si el campo será requerido y/o si el campo está presente en el 60% de los registros.
- Se usa la tabla _X cuando el campo no es requerido y no está presente en la mayoría de registros.