Winshuttle : Migration clients vers S4HANA et Fiori

Par David Coerchon , le 01 June 2016

Un nombre croissant de clients Winshuttle entament des migrations vers S4/HANA, pensent à utiliser FIORI, et s’interrogent sur la place des outils Winshuttle dans ce nouveau paysage applicatif. Voici quelques éléments de réponse.

 

SAP HANA : une évolution de SAP ECC

SAP S/4 HANA est une évolution majeure de SAP ECC qui s’appuie sur la base de données HANA, de nouvelles transactions, de nouvelles couches techniques, mais la majorité des plus de 15000 transactions reste disponible pour les utilisateurs à travers le SAPGui.

La stratégie de SAP est de supporter la compatibilité ascendante, tout en proposant de nouveaux modes d’interaction innovants pour accéder aux informations et les maintenir.

SAP FIORI, est cette nouvelle interface graphique qui permet de gérer des transactions unitaires en s’appuyant sur les services ODATA à travers SAP Netweaver Gateway. Elle est proposée aux clients sous forme d’applications pré paramétrées, ou d’une plateforme de développement.

Odata est un protocole de communication ouvert qui permet l’échange de données entre applications. C’est le support de communication entre Fiori et SAP, et le support de communication entre SAP (S4-HANA) et les nouvelles solutions acquises par SAP (HCM, Hybris…)

Blog post - Migration vers S4HANA

WINSHUTTLE supportera les nouvelles architectures SAP

Winshuttle Studio continue de fonctionner avec cette nouvelle architecture technique, à travers les couches actuelles : Transaction, tables, infosets ou bases de données logiques. La version actuelle de nos outils (10.7) permet déjà d’utiliser des transactions ou des BAPIs avec S4 HANA. Nos tests de certification et les retours de nos clients montrent que la plupart des transactions existantes fonctionnent de manière identique avec les scripts existants sans modification.

Nous avons lancé un processus de certification avec SAP pour S4 HANA et ODATA, et les retours des laboratoires SAP sont très positifs. Nous devrions être les premiers à proposer des produits certifiés pour ces interfaces.

Afin de tenir compte de l’évolution de la plate-forme SAP, et notamment la généralisation de SAP Netweaver Gateway et de HANA, nos outils Studio permettront prochainement d’utiliser les interfaces ODATA, tout en permettant à nos utilisateurs de gérer une transition en douceur vers ces nouvelles formes d’interaction avec SAP.

  • Les transactions impliquant de gros volumes de données seront toujours gérées via des BAPIs ou des transactions, comme cela est déjà le cas aujourd’hui,
  • Les transactions unitaires, ou pour lesquelles il n’existera ni BAPI, ni code transaction utiliseront ODATA. Cela nous permettra notamment d’accéder aux offres SAP qui ne sont pas basées sur des Kernels SAP.
  • Fiori est un outil graphique basé sur un contenu fonctionnel, basé sur des éléments pré paramétrés. Au-delà de sa capacité à gérer des informations multiples, la question de la charge de travail réelle pour dépasser le contenu pré paramétré se pose aux clients qui investiguent actuellement sa mise en œuvre. L’exemple des prés configurés SAP (BW…) est à ce titre porteur d’interrogations légitimes.
  • L’utilisation de Winshuttle permet au contraire d’envisager une transition sereine vers les nouvelles plateformes SAP, notamment en permettant de centraliser la fonction d’écriture vers SAP grâce au module serveur. Dans ce cas, les utilisateurs n’ont plus besoin de disposer du SAPGui sur leur poste, il leur suffit uniquement de poster leurs fichiers Excel dans SharePoint pour mettre à jour leurs données dans SAP. Les auteurs de scripts doivent en revanche toujours disposer d’un poste de travail complet, mais cela réduit leur nombre à quelques personnes.

En pratique, voici les étapes pour migrer les scripts Winshuttle d’une plateforme SAP ECC vers une plateforme SAP HANA :

  • Recenser les différents scripts
  • Les tester systématiquement dans un environnement de developpement ou de test.
  • Dans le cas ou des erreurs apparaissent, les traiter selon les cas suivants :
    • La transaction n’existe pas : rechercher la nouvelle transaction ou la BAPI correspondante,
    • Un ou plusieurs champs n’existent pas : rechercher ces champs dans la transaction et les remplacer avec la fonction d’édition des scripts Transaction, ou réenregistrer la transaction.

La Roadmap

 

Le programme de mise à disposition de ces nouvelles fonctionnalités est lié à la livraison des différentes versions de Studio 11 :

Fin 2016 : utilisation de OData pour des formulaires (version 11.1)

Courant 2017 : utilisation de OData pour Excel (Studio Workgroups).

Conclusion

Winshuttle s’engage au côté de ses clients pour leur permettre de mieux utiliser SAP, dans toutes les versions de l’ERP. L’arrivée de nouveaux accès aux données et l’évolution des architectures de l’ERP est pour nous l’opportunité de permettre à nos clients de tirer le meilleur parti des évolutions de SAP en limitant les perturbations pour les utilisateurs, qui peuvent continuer à utiliser les interfaces qu’ils connaissent.

 

Tableau récapitulatif

Question Réponse
Winshuttle Studio continue-t’il de fonctionner avec S4/Hana Oui, à travers les transactions, les BAPIs et les tables (pour Query)
Winshuttle supporte t’il OData ? Oui, à partir de la version 11.1
Faut-il réécrire tous les scripts en passant à S4/Hana ? Non, il faut en revanche les tester
Quelles sont les solutions alternatives si un script ne fonctionne plus après migration A analyser en fonction du message d’erreur : réenregistrer le script, passer à un script BAPI…

 

A propos de l’auteur

David Coerchon

Les billets de blog Winshuttle sont écrits par des experts qui s’engagent à vous fournir des articles sur une sélection de sujets parmi lesquels les bonnes pratiques, les nouvelles sur la gestion des données applicatives, des informations techniques et bien plus.