Le mobile et le cloud computing ouvrent la voie à l'open source

Souvent, un processus d'entreprise passe par plusieurs postes ou départements avant d'être achevé. Les collaborateurs impliqués ont alors des profils différents, de l'expert SAP à l'utilisateur occasionnel.

Pour faciliter au maximum l'intégration des utilisateurs occasionnels dans les processus commerciaux, il est recommandé d'utiliser les technologies d'interface utilisateur (IU) existantes. Cela réduit le temps d'apprentissage et augmente l'acceptation des utilisateurs.

On trouve souvent des technologies telles que Microsoft SharePoint. Si les informations stockées dans SAP peuvent être affichées et traitées directement dans SharePoint, sans redondance, le seuil d'accès à la saisie des données dans le système SAP est réduit de manière spectaculaire.

La qualité et l'actualité des données augmentent. Or, les collaborateurs utilisent de plus en plus souvent des solutions mobiles comme les tablettes ou les smartphones. Comment ces nouveaux groupes d'utilisateurs peuvent-ils accéder aux données disponibles dans le système SAP de la manière la plus simple et la plus sûre possible ?

En ce qui concerne l'utilisation des plateformes de médias sociaux, la question se pose également de savoir comment créer de nouvelles solutions innovantes en reliant plus étroitement les plateformes aux données critiques de l'entreprise dans le système SAP.

La configuration des produits à variantes intégrée dans SAP ERP offre une solution puissante pour lancer des processus de production ainsi que des processus dans le back-office, en fonction de la sélection de la configuration dans la commande client.

Pour simplifier encore plus la saisie de la configuration, cette étude a permis la saisie d'un modèle 3D intégré qui permet de visualiser immédiatement les attributs sélectionnés.

Les entrées peuvent ainsi être immédiatement vérifiées et corrigées visuellement, tout en augmentant l'acceptation par les utilisateurs finaux. La solution SAP Citizen Connect en est un autre exemple.

En se basant sur les fonctions du système SAP, une solution mobile a été créée ici, qui permet aux habitants d'une ville ou d'une commune d'envoyer des problèmes ou des dysfonctionnements directement dans le système SAP à partir de leur appareil mobile. Cela permet de supprimer les étapes intermédiaires auparavant nécessaires, comme l'appel à un central téléphonique avec des informations de localisation imprécises.

Grâce à ces informations supplémentaires, il est désormais possible de prendre une décision en temps réel sur la base de faits exacts. Et le retour d'information direct à l'auteur du signalement renforce la motivation à signaler à l'avenir des irrégularités qui, sinon, ne seraient pas détectées.

Solutions pour les non-ABAP

Le système SAP étant ouvert, les scénarios susmentionnés étaient déjà techniquement réalisables depuis longtemps. L'inconvénient était toutefois que l'on utilisait à chaque fois des solutions point à point.

De plus, le développeur de la solution non-SAP avait besoin d'une connaissance approfondie et détaillée du système SAP. Les développeurs qui ont un bon niveau de connaissances à la fois dans les langages de développement SAP et non-SAP ne sont malheureusement pas toujours disponibles.

Par conséquent, les projets sont plus longs ou plus chers et la maintenance est difficile à assurer, car le front-end évolue de manière dynamique. Les clients et partenaires SAP existants connaissent généralement très bien le langage de programmation ABAP.

Cependant, les connaissances ABAP sont peu répandues dans les autres communautés de développeurs, où prédominent surtout C, Java, Objective-C, PHP ou C#. C'est pourquoi on trouve aujourd'hui aussi typiquement dans les entreprises deux structures organisationnelles parallèles : un département chargé de la gestion des systèmes SAP et un autre qui s'occupe des questions non-SAP.

L'objectif pour NetWeaver Gateway était également de réduire les barrières de communication entre les deux équipes. Dans la recherche d'un outil qui puisse être compris par les experts SAP et non SAP, le protocole OData basé sur REST a été choisi. Ce protocole est en train d'être transformé en un standard Oasis afin d'accélérer une plus large diffusion.

Passerelle SAP NW

Via NetWeaver Gateway, un outil est mis à disposition pour accélérer et standardiser le développement des services REST nécessaires dans les systèmes SAP basés sur ABAP.

De nombreuses activités qui ne sont pas directement liées au développement du service sont prises en charge par le développeur, comme le support des dialectes (XML ou JSON), la préparation des messages, l'analyse des messages et le monitoring central. Un déroulement typique du développement d'une nouvelle interface utilisateur peut se présenter (de manière simplifiée) comme suit :

• Lors d'un atelier commun entre les utilisateurs - généralement représentés par un utilisateur clé, les experts de l'interface utilisateur et les experts du backend SAP - la nouvelle interface utilisateur souhaitée est définie et esquissée.
• Sur la base des résultats de l'atelier, des exigences sont ensuite déduites pour le backend et le frontend SAP. Ces exigences peuvent être documentées dans un modèle Entity-Relationship. Ce document constitue le point de départ des étapes suivantes. Il peut être importé aussi bien dans un système SAP que dans les outils de développement pour le développement du front-end.
• Les développements nécessaires sont en cours, tant au niveau du backend que du frontend.

OData arrive

Le protocole OData est basé sur des standards ouverts tels que HTTP, XML, JSON ou AtomPub. Les opérateurs déjà connus et définis par HTTP comme Get, Post, Put, Patch ou Delete ont toujours la même signification.

L'architecture basée sur REST permet aux développeurs qui n'ont pas de connaissances spécifiques de SAP de commencer à développer avec des outils standard sans avoir à suivre une formation poussée.

Définition d'un modèle OData : un modèle Entity-Relationship sert de base à la définition du service. Chaque service défini fournit un document de métadonnées. Ce document de métadonnées, dont la structure est à chaque fois identique, abstrait et harmonise les données des systèmes backend.

Si le modèle d'une interface utilisateur planifiée est par exemple constitué des objets produit, fabricant et catégorie de produit, le modèle souhaité est alors modélisé dans un document XML (EDM). Pour transférer le modèle dans OData, il est nécessaire de connaître les concepts sous-jacents d'OData :

• Entity Set : dans l'exemple ci-dessus, "Product" serait un Entity Set. Il est comparable aux listes ou aux entrées de tableau. Toutes les entrées (ou entités) d'un ensemble d'entités ont le même type d'entité.
• Entities : sont des instances du type Entity. Elles peuvent être structurées et possèdent un élément clé (Entity Key). La structure d'une Entities est définie par des Properties. Une entité peut être contactée individuellement via la clé. Plusieurs entrées peuvent être renvoyées via une recherche.
• Entity Key : se compose de Properties. Cette clé est importante pour pouvoir identifier clairement les différentes entrées. Elle est également nécessaire pour définir des associations entre les types d'entités.
• Association : Il s'agit de la connexion nommée entre deux types d'entités. Chaque association se compose de deux points d'extrémité qui définissent les types d'entités et la cardinalité (1:N, 1:1).
• Navigation Property : elle sert à la navigation entre les entités et est liée à l'association et au type d'entité.
• EntityContainer : tous les Entity Sets appartenant à un service sont regroupés ici.

L'exemple ci-dessus permet de mieux illustrer cette méthodologie : Les Properties du Supplier sont : ID (Entity Key), Name, Address, Concurrency et Prodcuts (Navigation Property).

L'EntityContainer nommé DemoService se compose des EntitySets suivants et des Associations entre les différents objets (qui ne sont toutefois pas mentionnés ici) : Products, Categories et Supplier. Un modèle est défini sur la base de ces principes.

Opérations basées sur le modèle : si ce modèle est défini, des opérations peuvent avoir lieu sur le modèle lors de l'exécution. Ces opérations peuvent par exemple être des recherches, des mises à jour, des suppressions.

Une liste de tous les produits peut être obtenue en cliquant sur l'URL http://services.odata.org/OData/OData.svc/Products/ afficher les résultats. Cette liste peut encore être limitée en ajoutant un paramètre de recherche tel que $top.

L'adresse http://services.odata.org/OData/OData.svc/Products/?$top=3 n'affiche plus que les trois premiers produits. La réponse consiste alors en un document XML ou JSON contenant le nom des propriétés et leurs valeurs.

De plus, les propriétés de navigation sont indiquées dans la réponse avec
ont été édités. Les objets liés (Category et Supplier) peuvent désormais être appelés directement par des URL propres.

Une navigation simple à l'aide des URL renvoyées est désormais possible pour les développeurs qui n'ont pas de connaissances détaillées du système backend utilisé. Les détails concernant la catégorie et le fournisseur sont désormais directement accessibles.

Opérations de requête : De nombreuses interfaces utilisateur sont basées sur des modèles simples et similaires. Très souvent, ces modèles commencent par la saisie d'une recherche. OData dispose de différentes possibilités pour formuler une recherche. Tous les opérateurs sont précédés d'un $.

Une requête portant sur tous les produits dont le prix est inférieur à 20 est alors formulée comme suit : http://services.odata.org/OData/OData.svc/Products/?$filter=Price le 20.

Si seules les valeurs Prix et Nom sont nécessaires à partir de ce résultat, il est possible de définir les colonnes de la réponse à l'aide de $select : http://services.odata.org/OData/OData.svc/Products?$select=Price,Name.

Il est également possible de trier les réponses avec $orderby. Bien entendu, cette commande n'a de sens que pour la sortie d'une liste. Dans cet exemple, les produits sont triés dans l'ordre :

Grâce à $top et $skip, il est possible de réduire certaines zones d'un résultat plus important en paquets individuels, qui sont ensuite transmis à la demande avec une faible consommation de ressources.

http://services.odata.org/OData/OData.svc/Products?$skip=2&$top=2&$orderby=Rating transmet la troisième et la quatrième série de produits, classés par évaluation.

De la définition à la mise en œuvre

Une fois le comportement souhaité défini, l'implémentation du service requis peut commencer dans le système SAP. Afin de soutenir au mieux le développeur du service requis, NetWeaver Gateway offre un soutien pour les différents cas d'application.

On distingue ici en détail la définition et l'implémentation d'un service. Les étapes suivantes ont toutes lieu dans le Service Builder. Celui-ci est l'interface centrale au sein de NetWeaver Gateway pour la définition et l'implémentation des services.

Pour définir un service, le modèle de données est défini conformément à la syntaxe OData décrite précédemment. Le modèle de données peut être défini de manière déclarative par saisie manuelle.

Le Service Builder soutient ici la définition par une structure de dossiers inspirée du modèle de données OData, dans laquelle les catégories telles que les relations ou les entités peuvent être saisies sous forme de tableau. Le modèle de données peut également être défini par l'importation d'un modèle de données externe au système SAP.

En outre, le modèle de données peut être défini sur la base des structures et des informations du système SAP sous-jacent (interfaces DDIC/RFC ou BOR) et en se référant aux modèles d'objets du système SAP. De nombreux objets sont développés en interne de manière orientée objet.

Il est donc relativement facile de convertir ces objets internes en services OData. PLM, EAM ou CRM en sont des exemples. Mais les requêtes de Business Warehouse ou les vues de Hana peuvent également être converties facilement en un service OData.

De plus, l'implémentation est ici automatiquement générée. S'il existe déjà un service qui a été développé via NetWeaver Gateway, un nouveau service peut être développé sur la base de l'ancien.

Cela peut être utile lorsque, par exemple, une extension ou une modification est nécessaire, mais que le service initial ne peut pas être modifié.

Pour les scénarios basés sur BW, les requêtes contenues peuvent être converties en services OData à l'aide des générateurs du Service Builder. Comme toutes les requêtes ne sont pas adaptées à l'utilisation en tant que service OData, les requêtes doivent être marquées dans le BW Query Designer avec un indicateur Easy-Query avant d'être utilisées dans le Service Builder.

Si la requête n'est pas convertible, ce code ne peut pas être activé. Une autre possibilité d'intégrer des informations provenant de SAP BW est le format MDX. Ce format peut également être converti en un service OData via le générateur.

L'implémentation des services définis dans le système SAP peut désormais se faire de deux manières : par un mapping du modèle OData sur des modules fonctionnels existants dans le système SAP, tels que RFC, BAPI, BOR.

Pour chaque méthode (suppression, lecture, ajout), il est possible d'utiliser un propre module fonctionnel pour le mappage. Le mappage s'effectue de manière conviviale par glisser-déposer dans le Service Builder. Ou par une implémentation manuelle via les outils standard SAP en ABAP.

Pour cela, le plug-in backend propose une super-classe qui doit ensuite être réimplémentée en conséquence. Chaque méthode (lecture, suppression, recherche) est développée séparément. Cette méthode contient ensuite la logique proprement dite, c'est-à-dire le code qui lit ou actualise les blocs fonctionnels et les tables correspondants.

Si une association entre les entités a été spécifiée lors de la définition du modèle - par exemple du produit à la catégorie -, cette association doit également être implémentée dans le Service Builder.

Toutes les implémentations et le code généré sont créés dans l'espace de noms du client. Cela présente d'une part l'avantage que des adaptations manuelles sont toujours possibles. Cela est également soutenu par un concept de points d'extension.

D'autre part, les instruments courants dans l'environnement ABAP sont utilisés pour la gestion du code source et le transport. Le résultat de la définition et de l'implémentation est maintenant un service OData fonctionnel.

Après la création du service, l'étape suivante consiste à l'activer. Cette étape est motivée par le fait que l'implémentation du service peut théoriquement se trouver sur un système SAP séparé du serveur central NetWeaver Gateway.

L'enregistrement permet de faire connaître le service dans le système central et de l'intégrer dans un catalogue de services central pour les services OData. L'interface utilisateur pour l'enregistrement et l'activation contient également des outils qui sont utiles pour le dépannage et les tests.

Ainsi, toutes les fonctions nécessaires à la définition et à l'implémentation se trouvent au même endroit dans le Service Builder, tandis que l'interface utilisateur d'enregistrement et d'activation contient tous les outils nécessaires à la gestion d'un service déjà existant.

Interfaces utilisateur

Visual Studio LightSwitch : Maintenant que le service correspondant a été implémenté ou généré dans le système SAP, le service peut être utilisé directement dans différentes interfaces, selon les besoins.

Grâce à l'utilisation d'un standard ouvert, il existe de nombreuses possibilités et de nombreux fournisseurs qui prennent en charge le format OData. Il convient de mentionner ici Visual Studio LightSwitch de Microsoft, car il fournit une solution ouverte pour la création d'applications plus complexes basées sur des modèles, qui peuvent être facilement étendues et adaptées après leur génération.

Dans l'assistant de création, ces modèles peuvent être reliés entre autres à des services OData. Et depuis la version 2010 de Microsoft Excel, il est également possible d'importer un service OData existant dans Excel et d'en afficher le contenu dans la vue tableau.

Lors de la conversion, il faut bien sûr procéder à quelques adaptations, ainsi les relations sont déposées dans des tableaux. Pour cela, il est nécessaire d'installer le Power Pivot Add-on gratuit dans Excel 2010.

Cette option ne permet pas à Excel de mettre à jour les données dans le système SAP, mais elle facilite l'affichage des valeurs et l'analyse basée sur Excel.

Outils de consommation externes : Des extensions sont mises à disposition via le SAP Community Network pour aider à la création d'applications basées sur HTML5 (jQuery mobile ou SAP UI5), Android, iOS, Java, PHP ou .Net.

Le développeur est assisté dans cette tâche par des extensions basées sur un assistant. Cet assistant analyse le service OData, par exemple pour identifier les relations et les attributs. En fonction de la technologie de l'interface utilisateur, le détail de la liste, parfois le workflow, sont disponibles en tant que modèles.

Dans l'étape suivante, le développeur doit définir les images, leur ordre et les champs visibles sur celles-ci. Ensuite, le code source est généré et peut être utilisé comme base pour des adaptations spécifiques au client.

De nombreux éléments comme les proxies peuvent alors être utilisés directement comme base pour la programmation individuelle de l'application. Pour les technologies mobiles comme iOS ou Android, la communication se fait au début directement de l'application vers NetWeaver Gateway via OData.

Si SAP Mobile Platform est utilisée, il est très facile de basculer la communication sur Mobile Platform dans les proxies centraux, le reste de l'application mobile et les services créés dans le système SAP peuvent rester identiques.

SAP UI5 : de nombreux fabricants de navigateurs et d'outils de création et de maintenance de sites web travaillent actuellement sur le thème du HTML5. SAP est également actif dans ce domaine.

Comme l'entreprise de Walldorf met l'accent sur le soutien des processus critiques pour l'entreprise, la prise en charge du HTML5 a également été optimisée.

L'utilisation du framework SAP UI5 facilite la création d'interfaces basées sur HTML5. Cela se fait par exemple par la mise à disposition de contrôles qui offrent une apparence uniforme et une création facilitée.

Composants utilisés

La solution NetWeaver Gateway se compose, pour simplifier, de deux éléments : un plug-in backend et le serveur Gateway proprement dit. Le plug-in backend contient les fonctionnalités nécessaires pour pouvoir s'intégrer directement dans le backend.

L'exemple le plus marquant est le Service Builder en tant qu'environnement central de développement et de modélisation. Le Gateway Server contient les fonctions du serveur. C'est ici que sont centralisés les éventuels plug-ins backend, que sont générés les fichiers XML, que sont reçues les réponses et bien plus encore.

Les autorisations et l'accès au système SAP jouent un rôle important. Le serveur d'application NetWeaver ABAP contient déjà le support pour de nombreux protocoles comme SAML 2.0, X.509, Basic Authentication ou SSO2 Token.

Ces protocoles peuvent donc être utilisés directement pour la communication avec le système NetWeaver Gateway. On peut maintenant distinguer plusieurs architectures :

• Installation directe sur le système backend : dans le cas de l'installation la plus simple, le serveur passerelle et le plug-in backend peuvent être installés directement sur le système SAP, qui doit utiliser au moins la version 7.0 de NetWeaver. L'avantage réside dans les coûts réduits. Aucun autre matériel n'est nécessaire. Comme le NetWeaver Gateway Server se contente de relativement peu de ressources, de nombreux scénarios peuvent déjà être pris en charge.
• Installation sur un système séparé : il est recommandé d'installer le Gateway Server sur un serveur séparé, surtout s'il existe plus d'un système de gestion. Les plug-ins de gestion sont ici toujours installés dans les systèmes SAP. Les différents systèmes SAP communiquent maintenant directement avec le Gateway Server. Dans ce scénario, les services nécessaires sont également développés dans les plug-ins backend.

  L'avantage est que la logique correspondante se trouve directement dans le système SAP. Cela permet un développement très performant. Seules les données nécessaires sont transmises au serveur central Gateway.

  Même des scénarios plus complexes, comme l'attribution de requêtes du Gateway Server au bon système SAP, sont possibles - si, par exemple, il existe un système SAP spécifique par région.

  Une telle architecture peut être choisie si, par exemple, une sécurité accrue doit être mise à disposition lors d'accès externes grâce à un concept de layerered defence. Le système NetWeaver Gateway peut alors être installé dans la zone démilitarisée (DMZ).

• Sans installation sur le système SAP : les deux esquisses ci-dessus

Les options ont l'inconvénient de nécessiter l'installation d'un logiciel supplémentaire sur le système SAP. Dans certaines constellations, il est difficile d'installer des logiciels supplémentaires, par exemple lorsqu'un système a été validé selon les normes de la FDA.

Dans ce cas, le plug-in de gestion et le serveur de passerelle peuvent être installés sur un système séparé. La communication avec le système SAP se fait via les interfaces déjà présentes dans le système, comme RFC ou BAPI.

La suite au prochain numéro ...