Modifier votre S/4

Avec Hana et surtout S/4, certaines choses changent aussi dans le développement classique d'Abap. Dans un premier temps, il faut notamment tenir compte de la forme d'exploitation dont on parle. Il faut ici faire la distinction entre la solution classique sur site et la solution en nuage.

Les deux formes d'exploitation peuvent être combinées. Alors que dans la solution sur site, l'utilisateur SAP a encore accès à l'univers classique d'Abap, il existe bel et bien quelques restrictions dans l'environnement en nuage.

Presque tous les utilisateurs SAP ont apporté diverses modifications à leur système SAP afin de personnaliser leurs processus et de se démarquer de la concurrence. Reste à savoir si toutes ces modifications étaient vraiment nécessaires. Néanmoins, certaines d'entre elles sont certainement valables, et ce n'est pas pour rien que l'on y a investi du temps et de l'argent.

Dans l'environnement cloud, les conditions changent. Avec S/4, les modifications classiques et les changements de code ne sont plus possibles que dans la solution sur site. On peut supposer qu'avec les futures versions, la forme et la manière dont nous modifions aujourd'hui seront également restreintes.

Aucune modification n'est possible dans l'environnement cloud. Cela signifie donc que les fonctionnalités existantes aujourd'hui doivent soit être ramenées au standard, soit être réalisées différemment, avant qu'un utilisateur puisse exploiter ses systèmes SAP dans le cloud.

SAP fait ici la distinction entre une extension Key-User et une extension Managed. L'extension Key-User permet des adaptations mineures au processus de gestion sous forme de champs spécifiques au client et de petites adaptations de code.

Ces extensions ne sont pas comparables à l'actuel Abap Workbench, mais plutôt à un outil très limité.

On peut comparer cela aux interfaces CRM ou Solution Manager, dans lesquelles il est possible de créer de nouveaux contenus de champs via la configuration. Ce n'est évidemment pas la grande liberté que connaît l'utilisateur SAP.

Pour les adaptations qui ne peuvent pas être implémentées techniquement, il existe la "Managed extensibility". Pour cela, SAP met à disposition des utilisateurs un système de développement hébergé dans le cloud.

Des extensions peuvent ensuite être implémentées sur ce système. Toutefois, cette prétendue liberté est, elle aussi, limitée. Il faut ici s'assurer que l'implémentation ne viole pas le mode de fonctionnement en nuage.

SAP s'en assure en interdisant toute modification. Les accès aux objets SAP ne peuvent pas non plus être effectués via une interface définie. Ceci est à comparer avec les BAPI actuelles. Une combinaison d'une solution sur site et d'une solution en nuage, sur laquelle certaines extensions sont exécutées, est envisageable, mais nécessite un certain savoir-faire.

Ainsi, il est certainement envisageable que les applications Fiori soient exploitées dans le cloud et soient donc évolutives et hautement disponibles. Mais en même temps, ces applications nécessitent des services de passerelle dans le système dorsal ERP.

SAP recommande pour cela le développement de Gateway Services. Cette architecture ne peut bien sûr être mise en œuvre que dans un scénario hybride. Dans la liste des objets spécifiques au client, les formulaires sont toujours en tête de liste, comme chacun sait.

SAP résout ce problème dans le Cloud en s'engageant clairement en faveur d'Adobe Lifecycle Designer. Tous les formulaires ou modèles d'e-mails sont donc implémentés sur la base d'Adobe Forms. Contrairement au monde classique, aucun programme d'impression n'est utilisé pour la préparation des données, mais NetWeaver Gateway.

La base des préparations de formulaires est donc constituée par les services OData, à l'aide desquels les informations pertinentes sont récupérées et préparées. Il apparaît donc que certaines choses vont changer fondamentalement avec S/4.

La migration d'un système ERP ou CRM d'une base de données Any vers Hana ne change pas encore le modèle de programmation. Néanmoins - pour profiter de la vitesse - il faut vérifier les programmes spécifiques au client et les adapter si nécessaire.

Avec le passage à S/4, le modèle de programmation changera beaucoup plus. Les services OData (NetWeaver Gateway), Fiori et SAPUI5 ainsi que les développements orientés objet sont les techniques pertinentes.

Le système de formulaires, souvent encore basé sur SAPScript ou Smartforms, est donc définitivement dépassé. Pour une transition vers Hana, les responsables informatiques devraient commencer très tôt à analyser les modifications, à provoquer une standardisation et à utiliser les nouvelles technologies de manière judicieuse.