Heures des Code Doctors

C'est surtout le contenu commercial mis à disposition qui a rendu et rend toujours le logiciel standard SAP si convoité par les clients SAP. Mais c'est aussi la possibilité de modifier le logiciel SAP.

Et ce, de la manière dont les besoins individuels de l'entreprise et des processus (propriété intellectuelle, en abrégé : PI) l'exigent pour la représentation dans le logiciel.

Il peut s'agir de modifications ou d'extensions mineures du programme, comme l'ajout d'un numéro de téléphone dans un rapport.

Mais il peut aussi s'agir de composants fonctionnels pratiquement entièrement nouveaux ou écrits par des développeurs pour soutenir ou exécuter des processus commerciaux spécifiques à l'entreprise, parfois très finement granulaires et différenciés par rapport à la concurrence, comme par exemple une solution complète de gestion des pièces de rechange ou une application sectorielle pour l'assurance qualité.

Code personnalisé

Ainsi, au cours des 20 dernières années, un immense volume de code dit personnalisé, basé sur des méthodes de logique de programmation, a été généré dans le monde entier par ou chez les clients SAP.

Ce code de programme, y compris les règles ou logiques qui y sont déposées, donne finalement vie aux très nombreuses transactions SAP qui sont responsables du fonctionnement d'un logiciel SAP dans une entreprise.

Ce code personnalisé a été créé principalement à l'aide de la programmation Abap (Abap-Coding). Abap est un langage de programmation (ou un environnement de développement dans le cas d'Abap-Workbench) qui permet une programmation non structurée, structurée et orientée objet.

De nouveaux codes personnalisés continuent d'être ajoutés pratiquement tous les jours. Il n'est pas rare de voir des dizaines de millions de lignes de code, mais aussi parfois le double pour une seule entreprise.

Les développeurs d'applications SAP sont nombreux. Les grands groupes emploient parfois des centaines de développeurs de programmes SAP. Et même dans une entreprise de taille moyenne, une division de développeurs d'applications peut compter une équipe de 15 ou 20 programmeurs SAP.

Même un regard un peu profond dans un système SAP ou dans le code source SAP d'une entreprise présente pratiquement immédiatement le code personnalisé généré.

Il peut s'agir de trois types de transactions différents. D'une part, les transactions dites "z" et, d'autre part, les transactions "y".

En outre, il existe des programmes et des transactions avec leur propre espace de noms (au lieu de z ou y), généralement avec une désignation d'entreprise, qui doivent d'ailleurs être déclarés ou enregistrés auprès de SAP.

Test sous Hana

Le besoin des clients de pouvoir utiliser à long terme tel ou tel code personnalisé est évident. Même dans le monde SAP On Hana ; lors de l'utilisation de S/4 Hana, Suite on Hana (SoH), BW on Hana ou du nouveau BW/4 Hana.

Pour ce faire, il est nécessaire d'analyser le code personnalisé en question, y compris les règles de programmation utilisées ou déposées, de le préparer pour le nouveau monde des bases de données (DB) Hana, de le transférer au moyen d'une conversion et de le tester.

Pour les aider, SAP met à leur disposition des règles de conformité au code Hana (informations à ce sujet dans les SAP-Notes 1912445, 2251947 par exemple) ainsi que des instructions avec des listes de contrôle.

Ce type de nécessité thérapeutique est dû au changement d'architecture de la base de données que SAP a réalisé avec Hana. Pour simplifier, le traitement du code Hana selon un traitement des tables de la BD orienté vers les colonnes, y compris les règles, fonctionne techniquement différemment d'une BD Any (DB2, Microsoft, Oracle) orientée vers les lignes/colonnes, y compris les index - à savoir qu'il n'y a pas de tri préalable lors de l'appel/du traitement.

Cette situation doit être prise en compte par le biais de compléments de programmation ou d'affectations à insérer. Il y a ici des "must-do", sinon un système ne fonctionnera tout simplement pas sur la nouvelle architecture.

Autre point important : pour profiter de l'étendue ou des avantages de Hana, il convient également de mettre en œuvre diverses améliorations du code source.

Comme ces optimisations ne sont guère ou très difficilement réalisables manuellement, il devient presque impossible de les effectuer manuellement.

Il s'agit par exemple d'optimiser des constructions de code source supplémentaires afin d'exploiter les avantages de la base de données Hana, d'optimiser les performances à l'aide de règles push-down, ou encore de faire en sorte que des parties de la fonctionnalité commerciale soient exécutées au niveau de la base de données (filtrage, tri, etc.) et non au niveau de l'application.

La question de savoir si et comment le code personnalisé existant (transactions z et y ainsi que transactions avec leur propre espace de noms) se comporte comme souhaité du côté de Hana après une conversion dépend toutefois toujours de plusieurs circonstances.

Il est parfois nécessaire de procéder à des analyses très approfondies du code source pour mettre en œuvre une thérapie par le code efficace.

En effet, seul le code source contient de fait la vérité.

De plus, si l'on démarre un déploiement On-Hana sans thérapie de code, on court le risque que les programmes présentent des erreurs après le passage à un système On-Hana comme S/4 par exemple.

Pour dire les choses simplement : Les parties de programme dans un système SAP On Hana basé sur un code personnalisé ne fonctionnent plus ici et là comme avant, avec des conséquences négatives parfois frappantes pour l'entreprise.

Selon l'expérience actuelle, la modification ou le changement nécessaire d'une ligne de code prend environ dix minutes à un expert en code/développeur SAP.

Le nombre de modifications de lignes de code à effectuer dans le cadre d'une conversion/migration dépend bien entendu de chaque cas particulier.

Il peut s'agir de 20, 200 ou même 20 000 modifications. En règle générale, il s'agit de travaux de modification en masse. Ce qui nécessite logiquement l'utilisation de ressources, de temps et de coûts correspondants.

Pour les travaux de modification plus importants, des usines à code ou des unités de programmation off-shore entrent en action.

Pour ce type de modifications, l'automatisation à l'aide d'un logiciel est naturellement judicieuse. Et ce, non seulement pour réduire le temps et les coûts, mais aussi pour garantir une qualité élevée et constante ainsi qu'une sécurité des processus.

Automatisation

En outre, l'automatisation permet de réaliser des optimisations.

Dans l'idéal, un tel outil de conversion met à disposition une fonctionnalité d'analyse correspondante qui permet d'estimer avec précision les efforts/les étapes.

Il doit également être en mesure de travailler avec les outils fournis par SAP, tels que Code Inspector ou SQL-Monitor, et de les compléter ou de les étendre.

Avec le Code Inspector, par exemple, il est possible de vérifier les objets du SAP Repository. Et ce, selon différents critères. Par exemple en ce qui concerne la performance, la syntaxe, la sécurité ou le respect des conventions de dénomination.

L'outil permet également de rechercher des mots Abap (appelés tokens). L'inspecteur de code fournit ensuite des messages d'erreur ou des avertissements ou en dresse la liste.

C'est un outil générique qui peut être adapté assez facilement aux circonstances spécifiques.

Un outil de conversion devrait également être basé sur une sorte de méta-modèle qui permette de trouver, de lire et d'analyser chaque ligne de code sans faille et de modifier automatiquement le code en fonction des besoins. De sorte qu'à la fin de la journée, il soit possible d'utiliser un code exempt d'erreurs pour l'utilisation On-Hana.

D'après l'expérience acquise auprès de groupes internationaux ainsi que d'entreprises de taille moyenne, il est possible, grâce à l'utilisation de l'outil sophistiqué et très performant pour le code personnalisé SAP, de réaliser même de grandes conversions On-Hana dans un délai d'une à deux semaines maximum - et ce, en incluant les tests techniques d'intégration et en étant prêt pour l'acceptation par les utilisateurs finaux.

En règle générale, les utilisateurs finaux ne testent pas entièrement la fonctionnalité après une conversion. La pratique montre que les clients se concentrent sur les processus commerciaux de base.

S'il y a des taux d'erreur, ils sont de l'ordre du pour mille. Si des erreurs systématiques apparaissent, elles sont prises en compte dans le métamodèle.

Les lignes de code concernées peuvent ensuite être rapidement générées à nouveau grâce à l'automatisation et l'erreur est corrigée.

En outre, l'outil met à disposition des fonctionnalités permettant d'optimiser un code. Et ce, jusqu'à l'analyse de la possibilité de transférer un code personnalisé vers le standard SAP ou, comme expliqué précédemment, de minimiser un code existant ou de le déplacer (de la couche application vers la couche DB) afin d'améliorer les performances d'un système Hana.

L'expérience montre que le code dormant dans les systèmes SAP n'est pas utilisé et qu'il peut être éliminé après examen. Ce code existant et inutilisé peut donc représenter jusqu'à 60% du code total existant dans un système.

Cette situation peut être qualifiée de "dette technique". Cette dette technique s'est généralement accumulée au fil du temps en raison d'un développement inefficace ou d'une génération de code personnalisé chez de nombreux clients SAP, et elle continue d'augmenter.

Dans le cadre d'une conversion on hana, il est bon de les supprimer systématiquement.