Política de modificación

ccppmop158
Política de CA PPM de BlueOfficial
Esta carta de la política de modificación describe la diferencia entre las
configuraciones
y las
personalizaciones
del producto
Clarity PPM
y el alcance del soporte técnico en relación con ambas.
Esta política se aplica a todas las versiones locales y SaaS activas de CA PPM incluidas las versiones 15.x, 14.x y 13.x, así como versiones anteriores.
Configuraciones
Las
configuraciones
constituyen el uso de las funciones documentadas para modificar el comportamiento del producto tal y como se envía. Algunos ejemplos de funciones documentadas que se pueden usar para crear configuraciones son los flujos de procesos, los portlets de Studio y las integraciones en XOG. Las funciones documentadas son compatibles con CA, pero no las configuraciones relacionadas. Por ejemplo, la función de Studio que se utiliza para crear un portlet de gráfica es compatible, pero no las características concretas del código subyacente de NSQL que sirven para suministrar datos al portlet. En estos casos, CA verificará que el comportamiento de las funciones documentadas sea el previsto dado el cambio de configuración específico, pero no solucionará los problemas de la configuración. Además de NSQL, otros ejemplos de cambios de configuración no compatibles son los scripts de GEL, los cambios realizados en los universos, dominios o atributos de generación de informes de Business Objects y las integraciones personalizadas de XOG que pueden o no causar problemas de rendimiento. CA colaborará con el cliente para aislar los problemas experimentados al utilizar funciones documentadas con el fin de confirmar que se han producido como consecuencia de funciones del producto con problemas de rendimiento (y las configuraciones diseñadas o implementadas incorrectamente).
Personalizaciones
Las
personalizaciones
constituyen el uso de medios no documentados para modificar el comportamiento del producto. Algunos ejemplos de personalizaciones son las adiciones de esquema de base de datos, disparadores y modificaciones de código. Todas las personalizaciones del código deben tener el prefijo Z_ para ayudar al cliente y a CA a identificar en qué partes del sistema hay personalizaciones.
El cliente debe entender que, mientras que las configuraciones cambiarán entre versiones sin que se alteren las modificaciones (siempre y cuando sigan siendo válidas en las nuevas versiones), no ocurrirá lo mismo con las personalizaciones. Las personalizaciones deben, al menos, aplicarse previamente a los sistemas actualizados y, en muchos casos, es posible que tengan que volver a diseñarse e implementarse para que funcionen tras modificarse la funcionalidad del producto. CA prestará soporte a sistemas personalizados, pero se excluirán únicamente las partes que se vean afectadas directamente por las personalizaciones. Normalmente, el equipo de soporte pedirá al cliente que elimine una personalización por motivos de diagnósticos cuando pueda contribuir a complicar el proceso de diagnóstico de la incidencia en el producto, o bien cuando complique dicho proceso. El cliente debe cumplir esta solicitud para recibir soporte del producto.
CA puede, a su discreción, revisar las personalizaciones y recomendar alternativas; en algunos casos, el equipo de soporte puede informar al cliente que no prestarán asistencia del sistema al completo si se utilizan personalizaciones. No se aceptan personalizaciones en entornos de
Clarity PPM
SaaS (anteriormente conocido como "a petición") bajo ninguna circunstancia.
Directrices de modificación
Para reducir el riesgo de que CA deniegue el soporte por un determinado problema causado por las modificaciones, se aplican las siguientes directrices:
  • No agregue campos a tablas de bases de datos de stock. En su lugar, cree nuevas tablas para conservar los datos personalizados que se pueden combinar con la tabla de stock.
  • El acceso directo a las tablas de stock debe ser de solo lectura; para actualizar las tablas de stock, utilice las capacidades XOG.
  • Los disparadores deben iniciarse solo en algunos casos, que serán poco frecuentes. Los disparadores solo deben leer los datos de stock. Deben ser simples y crearse con el fin de evitar interbloqueos. Los disparadores deben desactivarse durante las actualizaciones.
  • Todos los objetos de base de datos personalizados deben eliminarse antes de las actualizaciones del producto y, a continuación, deben volver a agregarse.
  • No se debe modificar el código fuente, incluidos Java, XML, XSL, XBL, PMD y todos los demás archivos del sistema proporcionados con el producto.