Découvrez le Module Fonction Winshuttle (WFM) – 1/3

Par Jennifer Hwang , le 02 octobre 2020

Winshuttle Studio est une application desktop, mais pour l’utiliser avec SAP, il vous faut notamment installer le module fonction Winshuttle (WFM). De quoi s’agit-il ? Pourquoi en avons-nous besoin ? En quoi est-il important ? Dans cette courte série de blogs, je vous dévoile quelques secrets du WFM afin que vous puissiez mesurer tout ce qu’il peut faire.

Le WFM est un petit composant ABAP qui s’installe sur votre système SAP. Il faut moins d’une heure à votre équipe SAP pour l’installer. Le WFM vit dans son propre espace nominal WINSHUTTLE enregistré dans SAP. Il n’affectera donc pas le code SAP standard. Le WFM n’est invoqué que lorsqu’un utilisateur exécute un script Winshuttle quelconque contre SAP. Si votre équipe SAP est préoccupée par le fait que le WFM puisse affecter votre système SAP, assurez-vous que l’utilisation standard de SAP n’y accède pas du tout.


Plus important encore, le WFM permet à Studio de communiquer avec SAP en utilisant le Remote Function Call (RFC). Si vous utilisez ECC 6 EHP 4 ou plus récent – la situation la plus fréquente – sans le WFM, tout utilisateur Winshuttle devra se voir attribuer des droits de niveau développeur dans SAP pour pouvoir utiliser Studio. Ce type d’accès n’est pas facile à accorder. Il est beaucoup plus simple d’installer le WFM. En parlant de RFC, tout utilisateur Winshuttle doit également se voir attribuer une liste d’autorisations d’objets RFC dans SAP. Votre équipe SAP peut créer son propre rôle personnalisé, qui comprend ces autorisations d’objets RFC, puis attribuer ce rôle à l’utilisateur Winshuttle. Mais le WFM peut faire ce travail pour vous. Le WFM contient déjà des rôles personnalisés (/WINSHTLQ/CMN_AUTHOR_ROLE ou /CMN_RUNNER_ROLE) et le rôle approprié peut être simplement attribué.

Pour ceux qui connaissent l’histoire de Winshuttle, quel âge a le WFM ? Le module fonction Winshuttle original, le véritable O.G., a été présenté pour la première fois au marché en même temps que le module Query de Studio. Ce n’est qu’à cette époque, en mars 2009, qu’il est apparu sous le nom de querySHUTTLE. Qui parmi vous s’en souvient ? L’objectif initial du WFM – et qui reste l’une de ses fonctions les plus importantes – est de garantir les performances du système SAP tout en exécutant les requêtes Winshuttle. L’Adaptive Query Throttling (AQT) breveté de Winshuttle garantit que même si quelqu’un écrit ou exécute involontairement une requête mal conçue avec Winshuttle, vos utilisateurs SAP habituels ne seront pas affectés. A l’origine, c’était le principal objectif du WFM. Mais des améliorations ont commencé à être apportées pour ajouter des fonctionnalités à Studio qui auraient été impossibles sans avoir installé quelque chose du côté de SAP.


Mais il ne s’agit pas seulement de connexions, d’autorisations ou de performances. Le WFM, c’est bien plus que cela. Figurent parmi les principales améliorations, la facilité de joindre des documents, le traitement de textes longs, la simulation et les BAPI personnalisés.
Certains de ces sujets méritent d’être plus amplement développés. Rejoignez-moi sur ce blog pour le prochain article de cette série. J’y ferai un focus sur deux des fonctionnalités les plus populaires du WFM : les pièces jointes et le texte long.

A propos de l’auteur

Jennifer Hwang

Jennifer Hwang est une consultante en logiciels et une analyste des processus métier qui a plus de 20 ans d'expérience dans la mise en œuvre et l'optimisation de diverses solutions techniques. En tant qu'ingénieur de solutions pour Winshuttle, avec plus de 11 ans d'expertise en matière de conseil, elle assure la réussite des clients en étant leur conseiller technique de confiance.