Dernière mise à niveau IRM - Siebel vers IP17 +

C'est ça, blagues à part - parlons de l'éternel. Dans ce post, vous ne trouverez pas un jet de joie ou un soupçon de facilité d'être. Parce que c'est pour ceux qui se sont battus et ont fouillé, en passant chaque nouveau round de mise à niveau de Siebel. Depuis 2013, Oracle mène une campagne de modernisation fondamentale de son système CRM. Jusqu'à présent, nous avons déjà expérimenté sept packs d'innovation (de IP13 à IP19). Jusqu'en 2013, les versions étaient publiées tous les 2 à 3 ans, les 5 à 6 dernières années, les mises à jour Siebel étaient publiées beaucoup plus souvent, en respectant un calendrier clair: des versions mineures (patchset) étaient publiées mensuellement, des versions fondamentalement nouvelles (majeures) étaient publiées chaque année et cela signifiait souvent le besoin d'un client traitement global voire «réintroduction» de votre système. Pour simplifier les mises à niveau Siebel, le fournisseur a développé IRM (Incremental Repository Merge) - une fonctionnalité qui facilite le processus d'installation de nouvelles versions avec des packages d'innovation. Il en sera question.

Principe IRM

Pour mettre à jour le système vers une nouvelle version avec Innovation Pack, vous devez mettre à jour le référentiel système. Pour ce faire, fusionnez avec le référentiel de la nouvelle version.
Le référentiel est les métadonnées du système, c'est-à-dire Schémas de tout ce qui est sa fonctionnalité. Au cours du projet, les développeurs consultants (clients de Siebel) apportent des milliers de modifications au référentiel. Cependant, dans la livraison de la version d'Oracle, ces modifications sont absentes et le fournisseur lui-même, modifiant le système, ajoute de nouvelles métadonnées et peut généralement traiter complètement un schéma d'objet particulier.

De toute évidence, un mécanisme est nécessaire ici qui permettrait de combiner de manière transparente les modifications apportées par le consommateur du système avec les nouveaux développements d'Oracle. Pour cela, IRM a été créé.

Tâches résolues lors de la mise à niveau de Siebel

1. Préparation des référentiels et des environnements pour la consolidation.
   
2. Intégration directe sur un environnement de mise à jour (DEV) (IRM).
   
3. Analyse et résolution des conflits.
   
4. Appliquez les modifications à l'environnement de mise à jour.
   
5. Test de régression.
   
6. Correction de tous les défauts apparus lors de la mise à jour.
   
7. Migration d'un environnement de mise à niveau vers la pré-production et ensuite vers la production.
   

Quels sont les avantages du passage à IP17 +

1. Nouveau moteur: OpenUI - la possibilité de configurer plus profondément l'interface, augmentant l'utilisabilité du système.
   
2. L'analyse des fonctionnalités du comportement des utilisateurs dans le système (suivi des profils d'utilisation) créera un UX unique.
   
3. Prise en charge de plusieurs navigateurs: IE n'est plus une limitation - vous pouvez désormais travailler dans Edge, Firefox, Chrome et Safari.
   
4. L'outil WebTools (Composer) vous permet de modifier l'interface et la logique métier du système à partir d'un navigateur sans nécessiter de redémarrage du serveur, c'est-à-dire sans temps d'arrêt. Le prototypage de développement est plus rapide.
   
5. Technologie CI / CD, automatisation du transfert de patch, développement parallèle, auto-test.
   
6. Prise en charge de la technologie d'intégration REST, qui est bien applicable lors de l'intégration avec les portails clients.
   
7. Innovations de l'industrie: de la création de magnifiques tableaux de bord analytiques sur la bibliothèque JS populaire aux technologies Big Data et Machine Learning.
   

La clé d'une mise à niveau réussie

IRM définit un ensemble de divergences dans les objets et les propriétés qui sont présentes dans le référentiel d'origine, dans la version client et dans la nouvelle version. La fonctionnalité permet, en fonction de la décision du développeur, de choisir une méthode de combinaison des objets et, à la dernière étape, de démarrer un processus efficace de migration du référentiel mis à jour de l'environnement de mise à jour vers le productif.

Lors de la fusion, des conflits surviennent, c'est-à-dire des différences entre les propriétés de l'objet du référentiel actuel et le même objet du référentiel de la nouvelle version.

Les conflits non critiques sont des écarts dans des objets qui n'ont pas été affectés par le client, c'est-à-dire les écarts entre le référentiel d'origine et le nouveau. 99% de ces conflits sont résolus en faveur d'un nouveau référentiel.

Les conflits critiques sont des différences d'objet entre le référentiel client et le nouveau référentiel.

Si vous suivez la méthodologie Oracle dès le début du projet, les mises à niveau ultérieures nécessiteront des coûts minimes. Mais, malheureusement, très souvent, les meilleures pratiques Oracle sont sacrifiées pour répondre à certaines exigences des clients. Par exemple, les tables système sont parfois modifiées directement via la base de données, qui n'est pas corrigée dans le référentiel Siebel. Ou ils modifient les clés utilisateur (UK), les dimensions et le type de colonnes standard des tables standard, ce que Oracle recommande fortement de ne pas faire. Cela rend impossible la reconstruction automatique de la table lors de la migration vers le productif et nécessitera de nombreuses manipulations manuelles avec les tables et les données. De plus, la modification des clés et colonnes standard peut affecter les performances des nouveaux processus développés pour la nouvelle version de Siebel.
Par conséquent, il est important que le système soit mis en œuvre sous la supervision de professionnels certifiés ayant une vaste expérience de mise en œuvre.

Cependant, la chose la plus importante dans le projet de mise à niveau est la planification compétente du processus, au cours de laquelle il est nécessaire de résoudre plusieurs problèmes à la fois.

Infrastructure de la solution

• Qui configurera l'infrastructure:
  
  • déployer des serveurs
  • définir le système d'exploitation
  • configurer RBS
• Description de l'environnement de mise à jour. Où ferons-nous l'IRM?
• Description de l'environnement de test. Comment allons-nous tester (y compris les systèmes externes et l'intégration)?
• Description de l'environnement de déploiement. Allons-nous mettre à jour le produit actuel ou mettre en place un environnement de production parallèle?

Plan de projet détaillé (en tenant compte de la répartition des responsabilités entre le client et l'entrepreneur)

• Il faut tenir compte du fait qu'il sera nécessaire de «geler» le travail d'introduction de nouvelles fonctionnalités au productif.
• Y compris vous devez considérer que vous devrez réinstaller tous les packages fonctionnels qui sont entrés dans le productif après le début du projet de mise à niveau.

Plan de test

• Des scripts de test de régression sont nécessaires.
• Identifier les responsables et déterminer l'équipe de testeurs du CRM et des systèmes externes.

Plan de mise en oeuvre

• Faites une liste de contrôle du travail sur l'introduction de la mise à niveau dans le productif.
• Faites un plan de restauration (oui, oui!;), En cas d'accident lors de la mise à niveau.

Séparément, il est logique de procéder à un audit complet du système (ou même de le commander auprès d'un fournisseur) afin de savoir quelles violations de méthodologie et erreurs d'implémentation technique ont été commises par le développeur. L'audit est réalisé par des spécialistes certifiés Oracle, les résultats sont enregistrés sous forme de protocoles Oracle Siebel "propriétaires":

1. Rapport de configuration (erreurs ou violations dans la configuration de la logique métier)
   
2. Rapport d'intégration (erreurs ou violations dans les objets d'intégration)
   
3. Rapport de script (erreurs ou violations dans les modules programmables)
   
4. Erreurs dans les processus (erreurs dans le flux de travail et les fonctions automatisées)
   

Le fait est que des erreurs peuvent survenir dans la fonctionnalité modifiée. Au stade des tests de régression de la solution combinée, il sera nécessaire de comprendre exactement quelle erreur est apparue à la suite de la combinaison, et laquelle était à l'origine.

Problèmes de mise à niveau Siebel les plus importants

Dernière IRM, ou Comment mettre à niveau vers la dernière Siebel (IP19)

Au cours des 2 dernières années, de grands changements ont eu lieu dans le système Siebel, ce qui a également entraîné un changement dans l'approche de mise à jour du système.

Les principaux changements sont liés à la sortie d'IP17 en 2017 et à ses mises à jour ultérieures.

• Le modèle de données système a été retravaillé, le fournisseur a refusé les fichiers de compilation SRF utilisés au démarrage du serveur. Un référentiel d'exécution est apparu, ce qui vous permet d'apporter des modifications à la configuration du système sans le redémarrer.
  
• Siebel Web Server est devenu un composant Siebel autonome, à partir de ce moment, les composants comme IIS et Apache de fabricants tiers ne sont plus nécessaires. Siebel WebServer est appelé Application Interface (AI), il fonctionne sur la base du conteneur Tomcat. Toutes les connexions à l'IA se font uniquement via HTTPS, c'est-à-dire tout le trafic est crypté par défaut. AI prend entièrement en charge REST pour les demandes entrantes et sortantes (la technologie REST offre une grande flexibilité dans l'installation des améliorations du système et dans le processus de mise à niveau des référentiels).
  
• Le composant Gateway a été mis à niveau (il s'appelle désormais Dynamic Gateway). Il convient de noter en particulier l’équilibrage inter-composants interne repensé. La passerelle (Gateway Elastic Load Balancer) en est désormais responsable, ce qui rend le système d'équilibrage de charge plus flexible - auparavant, cette fonction était exécutée par le serveur d'applications.
  
• Le système prend officiellement en charge la base de données Oracle 12 (la prise en charge de la base de données Oracle 11g est terminée).
  

En 2018, Oracle a modifié la politique de publication de Siebel CRM

• Toutes les innovations et corrections futures seront livrées sous forme de mises à jour, c'est-à-dire des jeux de patchs installés du kit de distribution vers la version actuelle (à partir d'IP17). Ils contiendront les innovations précédemment indiquées par le vendeur dans la stratégie de développement du système.
  
• Les noms du jeu de patchs deviendront plus clairs, car les versions sont publiées tous les mois: par exemple, le nombre 18,4 signifie «avril 2018».
  
• Le nouveau modèle de livraison commencera avec la version 18.4. La dernière version de l'ancien modèle était 17,6. Pour passer de 17.6 à 18.4 il vous suffit d'installer le kit de distribution (en tant que patch, et non en tant que mise à niveau IRM). Les mises à jour mensuelles ultérieures peuvent contenir des fonctionnalités pour lesquelles vous devez télécharger un petit ensemble de modifications via un utilitaire spécial. De plus, toutes les mises à jour seront cumulatives.
  
• En raison du changement de modèle, les clients qui sont passés à IP17 ne seront plus confrontés au problème de l'absence de correctif pour leur version du système. Dans le même temps, le processus de mise à niveau du système est considérablement simplifié, le coût de l'assistance est réduit et l'introduction de fonctionnalités innovantes est accélérée.
  
• Pour mettre à niveau, par exemple, vers la version 19 à partir des versions antérieures de Siebel (jusqu'à 17), il sera nécessaire d'implémenter une mise à niveau standard vers la version 17, puis d'utiliser le nouveau modèle de mise à jour.
  

Changements dans l'approche de mise à niveau vers IP17 +

Lors de la conception de l'infrastructure et du dimensionnement, vous devez prendre en compte la nouvelle infrastructure de serveur IP17. Les besoins en fer seront augmentés, car Le référentiel d'exécution nécessite plus de ressources. L'équilibrage tolérant aux pannes des nouveaux composants de l'interface d'application et de la passerelle recommande 3 composants au lieu de 2. Vous devrez revoir et migrer la configuration de votre serveur et les profils de serveur d'entreprise vers la nouvelle architecture IP17.

Il sera également nécessaire de transférer tous les artefacts Web, tels que les modèles HTML, JS, CSS, etc., vers le nouveau serveur Web Interface d'application. Soit dit en passant, tous les artefacts Web finiront par se déplacer vers le référentiel système.

Les étapes suivantes consistent à mettre à jour le système d'exploitation et la base de données vers les versions prises en charge (vous devez vérifier l'onglet de certification du logiciel Siebel pour Oracle Support) et à émettre le certificat HTTPS correct.

Enfin, vous devrez démarrer IRM pour la dernière fois, et les mises à jour de version ultérieures passeront simplement par l'installation de correctifs.

Si, parallèlement à la mise à niveau vers IP17 +, vous développez de nouvelles fonctionnalités sur votre version actuelle du système, il sera nécessaire de tester à nouveau et de mettre à jour la documentation d'accompagnement. Et les développeurs et les administrateurs sont formés pour utiliser la technologie Workspace, l'outil de migration et la nouvelle console Siebel Infrastructure Management Console.

Vous pouvez déterminer l'approche de la mise à niveau, qui dépend de votre version actuelle, à partir de ce tableau:


*** Pour plus d'informations sur les versions de SEA et SIA Siebel CRM, reportez-vous à l'article 1514115.1 de My Oracle Support.

Moral

De toute évidence, de tels projets nécessitent la participation de consultants expérimentés (enfin, sans eux) capables de prévoir et de contourner les écueils, de planifier avec compétence un tel processus de mise à niveau dans lequel le client ne sera pas laissé sans rien. C'est-à-dire minimiser et même éliminer les risques d'arrêt prolongé du système, de perte de données, d'erreurs critiques dans les processus métier après une mise à niveau. Par exemple, le mauvais choix d'une clé de table peut entraîner un traitement à grande échelle des processus dans le système - puis une simple mise à jour risque de se transformer en projet pendant plusieurs mois.

Maxim Chugunkin, responsable du groupe d'architecture de systèmes, Jet Infosystems