Abap à l'ère de S/4 Hana
![[shutterstock:236460769, Imagentle]](https://e3mag.com/wp-content/uploads/2017/02/shutterstock_236460769.jpg)

L'engouement pour les langages de programmation de quatrième génération, appelés 4GL (Generation Language), s'est étendu du milieu des années 80 jusqu'à la seconde moitié des années 90.
L'objectif était avant tout d'aider durablement les développeurs à créer rapidement des applications complètes.
Développées avec de nombreux 4GL ouverts et propriétaires, de nombreuses applications ont vu le jour - et ont servi de base ou de plate-forme de développement pour des systèmes logiciels standard, comme par exemple le succès de SAP R/3 à Walldorf.
Vers le milieu des années 90, SAP a tenté d'établir Abap (Advanced Business Application Programming) comme base générale de développement et 4GL sur le marché. Le Workbench Abap a été promu à l'époque.
De nombreux clients R/3 et partenaires SAP avaient déjà commencé à développer des applications de différents types avec le SAP Workbench. En partie sous forme de systèmes quasi autonomes, en partie sous forme de composants R/3 intégrables.
Parallèlement, Abap a servi de plus en plus, notamment chez les clients SAP, à créer ou à développer des extensions de R/3 en fonction des exigences les plus diverses de l'entreprise (mot-clé : propriété intellectuelle), ce qui est encore le cas aujourd'hui de manière très active.
Abap, initialement appelé "processeur général de préparation des rapports", a changé et évolué au fil des ans. SAP a toujours veillé à la compatibilité, même lorsque des éléments (et des modèles) de programmation orientés objet ont été introduits.
Une étape importante a par exemple été franchie au début des années 90, lorsque le groupe de logiciels de Walldorf a proposé, depuis l'introduction de NetWeaver, un environnement d'exécution et de programmation Java en plus d'Abap.
Une autre : Depuis un peu plus de quatre ans, SAP propose un environnement de développement Abap basé sur Eclipse, une plateforme open source.
Il y a eu plusieurs étapes de développement d'Abap au fil du temps. Il serait toutefois trop long de les énumérer toutes ici.
Il faut encore mentionner qu'Abap est basé sur des éléments de syntaxe du langage de programmation Cobol.
SAP va certainement orienter Abap vers l'utilisation de Hana ou l'adapter de manière plus stricte d'une manière ou d'une autre.
Standard ici, code personnalisé durable là
On ne peut que supposer le nombre de lignes de code ou d'applications/additions d'applications, petites ou grandes, qui ont été développées avec le langage de programmation propriétaire Abap dans le monde entier.
En tout cas, ils se chiffrent en milliards. Et le code Abap-Custom a une longue durée de vie, très longue.
De nombreux utilisateurs SAP avec des développements Abap ainsi que de nombreux partenaires SAP qui ont développé des solutions complémentaires ou sectorielles sur la base d'Abap se posent actuellement des questions :
- Le code Abap peut-il être utilisé à l'ère S/4-Hana ?
- Que faut-il faire pour utiliser au mieux les programmes Abap dans S/4 ?
Comme chacun sait, S/4 représente une nouvelle génération de Business Suite basée sur une nouvelle technologie. D'une part, l'étendue des fonctions change constamment, comme c'est le cas dans la version majeure actuelle 1610 (par rapport à la version 1511).
D'autre part, SAP transfère de nombreuses fonctions dans la norme. En outre, différentes transactions seront regroupées.
Cela dit, le code Abap ou le code personnalisé peut généralement être utilisé dans S/4. Toutefois, le code Abap doit être analysé afin de déterminer s'il est compatible avec les parties de programme existantes et futures de S/4 et l'utilisation de Hana.
La création d'une sorte de "heat map" est ici recommandée, qui permet par exemple de savoir quels objets accèdent à quelles tables, ou de vérifier quels processus et quelles données ont été quasiment simplifiés et lesquels peuvent, le cas échéant, ou doivent impérativement l'être.
Ou encore : quels programmes agissent dans quelles transactions, et ce pour des raisons d'identification/de traçabilité.
Les outils de Smartshift sont également en mesure d'effectuer ce type d'analyse - comme base pour des optimisations de code pertinentes et durables.