Último IRM: actualización de Siebel a IP17 +

Eso es todo, bromas aparte, hablemos de lo eterno. En esta publicación no encontrarás un chorro de alegría o un indicio de la facilidad de ser. Porque es para aquellos que lucharon y buscaron, pasando cada nueva ronda de actualización de Siebel. Desde 2013, Oracle lleva a cabo una campaña para modernizar fundamentalmente su sistema CRM. Hasta ahora, ya hemos experimentado siete paquetes de innovación (de IP13 a IP19). Hasta 2013, los lanzamientos se lanzaban cada 2–3 años, los últimos 5–6 años las actualizaciones de Siebel se publicaban con mucha más frecuencia, manteniendo un calendario claro: los lanzamientos menores (parches) se publicaban mensualmente, las versiones fundamentalmente nuevas (principales) se publicaban anualmente y, a menudo, esto significaba la necesidad del cliente procesamiento global o incluso "reintroducción" de su sistema. Para simplificar las actualizaciones de Siebel, el proveedor desarrolló IRM (Incremental Repository Merge), una función que facilita el proceso de instalación de nuevas versiones con paquetes de innovación. Será discutido

Principio de IRM

Para actualizar el sistema a una nueva versión con el Paquete de innovación, debe actualizar el repositorio del sistema. Para hacer esto, fusione con el repositorio de la nueva versión.
El repositorio son los metadatos del sistema, es decir. Esquemas de todo lo que es su funcionalidad. Durante el proyecto, los desarrolladores consultores (clientes de Siebel) realizan miles de cambios en el repositorio. Sin embargo, en la entrega de la versión de Oracle, estos cambios están ausentes, y el vendedor mismo, modificando el sistema, agrega nuevos metadatos y generalmente puede procesar completamente un esquema de objeto particular.

Obviamente, aquí se necesita un mecanismo que permita combinar a la perfección los cambios realizados por el consumidor del sistema con los nuevos desarrollos de Oracle. Para esto, se creó IRM.

Tareas resueltas durante la actualización de Siebel

1. Preparación de repositorios y entornos para consolidación.
   
2. Integración directa en un entorno de actualización (DEV) (IRM).
   
3. Análisis y resolución de conflictos.
   
4. Aplicar cambios al entorno de actualización.
   
5. Pruebas de regresión.
   
6. Corrección de todos los defectos que aparecieron durante la actualización.
   
7. Migración de un entorno de actualización a preproducción y posterior producción.
   

¿Cuáles son los beneficios de cambiar a IP17 +?

1. Nuevo motor: OpenUI: la capacidad de configurar más profundamente la interfaz, aumentando la usabilidad del sistema.
   
2. El análisis funcional del comportamiento del usuario en el sistema (Rastreo de patrones de uso) creará una experiencia de usuario única.
   
3. Compatibilidad entre navegadores: IE ya no es una limitación: ahora puede trabajar en Edge, Firefox, Chrome y Safari.
   
4. La herramienta WebTools (Composer) le permite realizar cambios en la interfaz y en la lógica empresarial del sistema desde un navegador sin necesidad de reiniciar el servidor, es decir. sin tiempo de inactividad. El desarrollo de prototipos es más rápido.
   
5. Tecnología CI / CD, automatización de transferencia de parches, desarrollo paralelo, pruebas automáticas.
   
6. Soporte para la tecnología de integración REST, que se aplica bien cuando se integra con portales de clientes.
   
7. Innovaciones de la industria: desde la construcción de hermosos paneles analíticos en la popular biblioteca JS hasta las tecnologías Big Data y Machine Learning.
   

La clave para una actualización exitosa

IRM define un conjunto de discrepancias en los objetos y propiedades que están presentes en el repositorio original, en la versión del cliente y en la nueva versión. La funcionalidad permite, según la decisión del desarrollador, elegir un método para combinar objetos y, en la última etapa, iniciar un proceso efectivo de migración del repositorio actualizado del entorno de actualización al productivo.

Durante la fusión, surgen conflictos , es decir, diferencias entre las propiedades del objeto del repositorio actual y el mismo objeto del repositorio de la nueva versión.

Los conflictos no críticos son discrepancias en los objetos que no han sido afectados por el cliente, es decir. discrepancias entre el repositorio original y el nuevo. El 99% de dichos conflictos se resuelven a favor de un nuevo repositorio.

Los conflictos críticos son diferencias de objeto entre el repositorio del cliente y el nuevo repositorio.

Si sigue la metodología de Oracle desde el comienzo del proyecto, las actualizaciones posteriores requerirán costos mínimos. Pero, desafortunadamente, muy a menudo las mejores prácticas de Oracle se sacrifican cuando se cumplen ciertos requisitos del cliente. Por ejemplo, las tablas del sistema a veces se cambian directamente a través de la base de datos, que no se repara en el repositorio de Siebel. O cambian las claves de usuario (Reino Unido), las dimensiones y el tipo de columnas estándar de tablas estándar, lo que Oracle recomienda no hacer. Esto hace que sea imposible reconstruir automáticamente la tabla durante la migración a la productividad y requerirá muchas manipulaciones manuales con las tablas y los datos. Además, cambiar las claves y columnas estándar puede afectar el rendimiento de los nuevos procesos desarrollados para la nueva versión de Siebel.
Por lo tanto, es importante que el sistema se implemente bajo la supervisión de profesionales certificados con amplia experiencia en implementación.

Sin embargo, lo más importante en el proyecto de actualización es la planificación competente del proceso, durante el cual es necesario resolver varios problemas a la vez.

Infraestructura de soluciones

• Quién configurará la infraestructura:
  
  • implementar servidores
  • configurar el sistema operativo
  • configurar RBS
• Descripción del entorno de actualización. ¿Dónde haremos IRM?
• Descripción del entorno de prueba. ¿Cómo lo probaremos (incluidos los sistemas externos y la integración)?
• Descripción del entorno de implementación. ¿Actualizaremos el producto actual o configuraremos un entorno de producción paralelo?

Plan detallado del proyecto (teniendo en cuenta la distribución de responsabilidad entre el cliente y el contratista)

• Debe tenerse en cuenta que será necesario "congelar" el trabajo para introducir nuevas funcionalidades en lo productivo.
• Incluyendo debe tener en cuenta que deberá reinstalar todos los paquetes funcionales que entraron en funcionamiento después del inicio del proyecto de actualización.

Plan de prueba

• Se necesitan scripts de prueba de regresión.
• Identifique a los responsables y determine el equipo de probadores de los sistemas CRM y externos.

Plan de implementación

• Haga una lista de verificación del trabajo para introducir la actualización en la productividad.
• Haga un plan de reversión (¡sí, sí!;), En caso de que ocurra un accidente durante la actualización.

Por separado, tiene sentido realizar una auditoría completa del sistema (o incluso pedirlo a un proveedor) para averiguar qué violaciones de la metodología y errores de implementación técnica fueron realizados por el desarrollador. La auditoría es realizada por especialistas certificados de Oracle, los resultados se registran en forma de protocolos "propietarios" de Oracle Siebel:

1. Informe de configuración (errores o infracciones en la configuración de lógica de negocios)
   
2. Informe de integración (errores o infracciones en los objetos de integración)
   
3. Informe de secuencia de comandos (errores o infracciones en módulos programables)
   
4. Errores en los procesos (errores en el flujo de trabajo y funciones automatizadas)
   

El hecho es que pueden ocurrir errores en la funcionalidad modificada. En la etapa de prueba de regresión de la solución combinada, será necesario comprender exactamente qué error apareció como resultado de la combinación y cuál fue originalmente.

Problemas de actualización más importantes de Siebel

Último IRM, o Cómo actualizar al último Siebel (IP19)

En los últimos 2 años, se han producido grandes cambios en el sistema Siebel, que también han llevado a un cambio en el enfoque para actualizar el sistema.

Los cambios clave están relacionados con el lanzamiento de IP17 en 2017 y sus actualizaciones posteriores.

• El modelo de datos del sistema se modificó, el proveedor rechazó los archivos de compilación SRF utilizados en el inicio del servidor. Ha aparecido un repositorio de tiempo de ejecución, que le permite realizar cambios en la configuración del sistema sin reiniciarlo.
  
• Siebel Web Server se ha convertido en un componente independiente de Siebel, a partir de ese momento ya no se requieren componentes como IIS y Apache de otros fabricantes. Siebel WebServer se llama Application Interface (AI), se ejecuta en base a Tomcat-container. Todas las conexiones a AI se realizan solo a través de HTTPS, es decir todo el tráfico está encriptado de manera predeterminada. AI tiene soporte REST completo para las solicitudes entrantes y salientes (la tecnología REST brinda una gran flexibilidad para instalar mejoras en el sistema y en el proceso de actualización de repositorios).
  
• El componente Gateway ha sido actualizado (ahora se llama Dynamic Gateway). De particular interés es el rediseño del equilibrio interno entre componentes. La puerta de enlace (Gateway Elastic Load Balancer) ahora es responsable de ello, lo que hace que el sistema de equilibrio de carga sea más flexible; anteriormente, esta función la realizaba el servidor de aplicaciones.
  
• El sistema admite oficialmente la base de datos Oracle 12 (el soporte para la base de datos Oracle 11g está completo).
  

En 2018, Oracle cambió la política de lanzamiento de Siebel CRM

• Todas las innovaciones y correcciones futuras se entregarán como actualizaciones, es decir, parches instalados desde el kit de distribución a la versión actual (comenzando con IP17). Contendrán innovaciones previamente indicadas por el vendedor en la estrategia de desarrollo del sistema.
  
• Los nombres del parche serán más claros porque las versiones se lanzan mensualmente: por ejemplo, el número 18.4 significará "abril de 2018".
  
• El nuevo modelo de entrega comenzará con la versión 18.4. La última versión del modelo anterior era 17.6. Para pasar de 17.6 a 18.4 solo necesita instalar el kit de distribución (como un parche, y no como una actualización de IRM). Las actualizaciones mensuales posteriores pueden contener funcionalidades para las cuales necesita descargar un pequeño paquete de cambios a través de una utilidad especial. Además, todas las actualizaciones serán acumulativas.
  
• Debido al cambio en el modelo, los clientes que cambiaron a IP17 ya no enfrentarán el problema de la falta de un parche para su versión del sistema. Al mismo tiempo, el proceso de actualización del sistema se simplifica enormemente, se reduce el costo del soporte y se acelera la introducción de funcionalidades innovadoras.
  
• Para actualizar, por ejemplo, a la versión 19 de versiones anteriores de Siebel (hasta 17), será necesario implementar una actualización estándar a la versión 17 y luego usar el nuevo modelo de actualización.
  

Cambios en el enfoque para actualizar a IP17 +

Al diseñar la infraestructura y realizar el dimensionamiento, debe considerar la nueva infraestructura de servidor IP17. Los requisitos para el hierro se incrementarán, porque El repositorio de tiempo de ejecución requiere más recursos. El equilibrio a prueba de fallas de los nuevos componentes de Interfaz de aplicación y Puerta de enlace recomienda 3 componentes en lugar de 2. Deberá revisar y migrar la configuración y los perfiles del servidor a la nueva arquitectura IP17.

También será necesario transferir todos los artefactos web, como plantillas HTML, JS, CSS, etc., al nuevo servidor web de la interfaz de la aplicación. Por cierto, todos los artefactos web eventualmente se moverán al repositorio del sistema.

Los siguientes pasos son actualizar el sistema operativo y la base de datos a las versiones compatibles (debe verificar la pestaña de certificación de software de Siebel para obtener soporte de Oracle) y emitir el certificado HTTPS correcto.

Finalmente, tendrá que iniciar IRM por última vez, y las actualizaciones de versiones posteriores se realizarán simplemente mediante la instalación de parches.

Si, en paralelo con la actualización a IP17 +, está desarrollando una nueva funcionalidad en su versión actual del sistema, entonces será necesario volver a probar y actualizar la documentación adjunta. Y los desarrolladores y administradores están capacitados para trabajar con la tecnología Workspace, la Herramienta de migración y la nueva Consola de administración de infraestructura Siebel.

Puede determinar el enfoque de la actualización, que depende de su versión actual, a partir de esta tabla:


*** Para obtener más información sobre las versiones de SEA y SIA Siebel CRM, consulte el artículo 1514115.1 de My Oracle Support.

Moraleja

Obviamente, tales proyectos requieren la participación de consultores experimentados (bueno, sin ellos) que sean capaces de prever y sortear las dificultades, planificar de manera competente un proceso de actualización en el que el cliente no se vea abrumado. Es decir minimice e incluso elimine los riesgos de tiempo de inactividad prolongado del sistema, pérdida de datos, errores críticos en los procesos comerciales después de una actualización. Por ejemplo, la elección incorrecta de una clave de tabla puede implicar un procesamiento a gran escala de procesos en el sistema, y ​​luego una simple actualización corre el riesgo de convertirse en un proyecto durante varios meses.

Maxim Chugunkin, jefe del grupo de arquitectura de sistemas, Jet Infosystems