vendredi 19 octobre 2007

Upgrade SAP : Présentation à l'USF

http://rene-de-beauregard.blogspirit.com/archive/2007/10/12/upgrade-sap-presentation-a-l-usf.html

"

La convention USF 2007 ( Utilisateurs SAP francophones ) s'est tenue du 9 au 11 octobre à Reims. A cette occasion, j'ai présenté avec un de nos clients un bilan d'upgrade SAP. Nous étions en plein coeur d'une des préoccupations majeures de cette convention:

  • Préoccupation de SAP : Comment convaincre ses clients de passer à la dernière version ?
  • Préoccupation des clients : Comment convaincre ma direction de l'intérêt de ce type d'opération ?

Présentés lors de cette convention, les résultats d'une enquête sur le terrain ont montré que le principal facteur déclenchant de l'upgrade était l'arrêt de support standard. Les versions antérieures ( 4.6C principalement ) continuent d'être supportées, mais un tarif supérieur et sans apport de nouveau correctif. Tout ça est vécu comme une contrainte plus que comme un désir d'exploiter de nouvelles fonctionnalités : Intégration du moteur BW, J2EE, Architecture SOA. D'ailleurs si celles-ci sont jugées intéressantes, elles ne seront mises en oeuvre que plus tard.

En tous cas le projet d'upgrade qui a été mené chez notre client montre que les charges ne sont pas si énormes.

Quelques chiffres clé :

  • 5 mois de projet ( de janvier à juin 2007)
  • Une charge globale de 250 ETP (120 client, 70 pour la revue des développements , 60 pour nous Sun )
  • 56 heures d'arrêt ( business downtime ) lors de l'upgrade final de l'instance de production
  • L'opération technique d'upgrade a duré 17 heures. Le reste du temps a été occupé par les validations fonctionnelles et la reconnexion de l'instance à ses diverses interfaces

Inclus dans ces 5 mois de projet, le changement de serveur + un upgrade Oracle 9.2 vers Oracle 10. C'est d'ailleurs cet upgrade qui nous a causé le plus de soucis.

Les techniques de copie incrémentales sont d'une aide précieuse dans ce type de projet. Il faut en effet copier de multiples fois les différentes instances SAP. Les modifications effectuées sont enregistrées dans une petite base de données spécifique ( bitmap ) qui pointent les blocs modifiés. A la prochaine synchronisation, seuls les blocs modifiés seront recopiés.

Un upgrade SAP se décompose en plusieurs phases. Avec cette technique de copie incrémentale, on peut sauvegarder un état stable de l'instance qui pourra servir de point de retour en cas d'échec de la phase suivante. Le déclenchement de ces copies se fait par script shell et est donc très facilement utilisable.

Pour plus de détails, voici donc la présentation Présa Sun-USF2007.pdf qui a été faite. J'ai juste retiré les slides relatifs à l'activité du client. "


Je télécharge la présentation et la mettrai sur notre lieu de partage des informations (l'upgrade est en environnement Sun).

Aucun commentaire:

Enregistrer un commentaire