Introduction

Cela fait prés de 10 ans qu'il est possible de faire du développement web connecté avec SAP (par exemple en ASP 3.0 associé au connecteur DCOM), mais avec le SAP Web Application Server puis différentes technologies (BSP, MVC, WebDynPro, Netweaver Portal) et ECC les possibilités sont bien plus importantes. Avec sa version ECC 6.0 et son service SOAP/RFC, SAP s'ouvre à l'ensemble des systèmes de la manière la plus facile, puisque ne nécessitant plus de connecteur spécifique et s'inscrivant dans la démarche au combien performante et vertueuse, qu'est l'architecture orientée Service (S.O.A).

Le but du présent article est de vous proposer une introduction au développement web sur SAP ainsi que vous initier aux technologies de portails.

 

PARTIE N°1 : Le développement web sur SAP.

Pourquoi proposer des applications web

Quelque soit la nature d'une application web, les raisons qui font qu'on va vers un développement d'un client web sont souvent motivées par les mêmes raisons, qui doivent être mises en perspective avec les conséquences que cela a. Pour cela je vous propose de revenir sur quelques points clés :

• Une application web ne nécessite pas d'installation d'un client lourd, seul un browser internet est nécessaire, ce qui fait qu'une interface web est normalement indépendante du système d'exploitation. Ce cas est vérifié sur la trés grande majorité des projets, ou globalement un support HTML + Javascript standard W3Csuffit largement. Restent certaines restrictions de développement si on veut que l'application soit réellement compatible avec l'ensemble des navigateurs internet du marché.

MAIS

• Dans certains cas, par exemple pour des traitements importants, des animations, de la décompression de vidéos, ou la manipulation de quantités de données importantes  dans des datagrid ou des graphes vectoriels, il peut être intéressant d'utiliser des technologies de type RIA (Rich Internet Application) tels que Adobe Flex, Java JFX, Microsoft Silverlight. Techniquement ce genre d'outils nécessite une machine virtuelle installée sur la machine cliente. Pour le développeur WEB SAP ce type d'application sont ni plus ni moins des objets mimes qui peuvent être interfacés via un bridge Javascript voir juste avec un url et des paramètres.
• Une application web en fonction de ou elle se trouve et de sa destination (internet, extranet, intranet) doit être sécurisée, mais apporte aussi une couche d'isolation entre un système d'information et des utilisateurs, à condition que la sécurité soit bien pensée.

 

Infrastructure nécessaire

On distingue deux cas d'utilisation qui ont un vrai impacte sur l'organisation de son infrastructure. Mais qu'on utilise un serveur SAP WebAS ou un serveur IIS ou Apache, le problême reste le même.

Si un serveur web est exposé à l'extérieur pour de l'extranet ou de l'internet, il doit être isolé comme ci dessous (la machine entre les deux firewall), alors qu'un serveur intranet lui peut se trouver dans le système d'information sans précaution particulière autres qu'habituelles. Dans cette exemple j'ai mis un serveur NetWeaver Portal connecté à un (ou plusieurs) système(s) SAP via RFC.

Quand au choix de la machine, si le serveur WEB est amené à être fortement sollicité, il est essentiel qu'il soit dédié à cela à 100% surtout si vous allez vers la mise en place d'un portail avec aggrégation de contenus. 

Les aspects sécurités et performances doivent être pris en compte dés le début d'un projet, évalués sur des critères objectifs avec des programmes de tests, et suivis tout au long de la vie d'une solution web.

 

Développement web pour SAP

Dans un contexte SAP on distingue deux types de situation :

• Un développement sur le serveur SAP WebAS.
• Un développement sur un serveur web non SAP comme IIS ou APACHE.

Le choix du serveur web dépend en fait de nombreux facteurs, comme les compétences disponibles, la connection de la solution à d'autres systèmes que SAP, les aspects liés aux licences, le suivi et la maintenabilité de la réalisation, et les performances ainsi que l'architecture de la solution.

Sur le SAP Web Application serveur

le SAP Web application propose différentes possibilités de développement web qui toutes peuvent être utilisées de manière isolée ou pour développer des applications qui seront intégrées dans un portail Netweaver ou autres.

• BSP : BPS est trés similaire à l'ASP ou au JSP. Il s'agit de combiner de l'ABAP OO avec de l'html et du javascript. Cette approche est trés efficace, et permet à des développeurs WEB non SAP utilisateur d'EDI comme DreamWeaver de créer des applications web qui autorise toutes les libertés créatives sur SAP WebAS. (voir aussi : http://www.sap-integration.net/Default.aspx?tabid=433&articleType=ArticleView&articleId=319&language=fr-FR )
• BSP MVC : (MVC Modul View Control). MVC est une approche de modélisation et de développement de l'application web basée sur le développement de contrôle (.do) et de pages qui intégrent les contrôles. C'est similaire avec l'approche ASP.net.
• HTMLB : HTMLB est une série de fonction et de contrôle JAVASCRIPT qui via un DOM XML permet entre autre de mettre à jour des données sans rechargement de la page en entier (XML asynchrone). Dans les faits, il s'agit ni plus ni moins d'un framework AJAX.
• WebDynPro : Certainement le moyen le plus performant et le plus rapide pour développer des interfaces WEB, WEBDYNPRO  fournit à la fois un environnement "wysiswyg" (What you see is what you get), et à la fois une approche de développement par mappage d'objets, un peu compliqué à assimiler, mais au combien puissante. WebDynpro existe en ABAP OO ainsi qu'en Java avec NetWeaver Portal Studio (un Eclipse adapté par SAP).Pour ma part, j'ai une préférence pour la version ABAP. (voir aussi : http://www.sap-integration.net/Default.aspx?tabid=433&articleType=ArticleView&articleId=335&language=fr-FR)

 

Sur des serveurs comme IIS et Apache

Dans le cas de développement d'applications web sur des serveurs non SAP, le problème principal réside dans la manière de se connecter à SAP. On distingue deux cas.

• Si on dispose d'ECC 6.0, il suffit d'activer le service SOAP/RFC pour exposer des RFC et BAPI via des webservices à toute application externet. Dans ce cas il est possible, en utilisant un utiliseur SAP system, de connecter n'importe quel plateforme web à SAP ( J2EE, Tomcat, .net, Flex, JFX, Silverlight...).
• Sinon, ou si on ne souhaite pas utiliser la couche web service de SAP, il existe des connecteurs :
  • JCo : Java connector pour le développement sur J2EE, et PHP
  • .net connector ou ErpConnect pour Microsoft.net
  • ainsi que le connecteur DCOM.

A noter qu'on a aussi la possibiliter de créer des interfaces http post/get/put directement ou des flux XML directement sur le serveur Web Application serveur de SAP.

En résumé SAP, mais c'est en fait le cas depuis trés longtemps, peut etre connecté par différents types d'applications web à la fois de manière synchrone (RFC/BAPI) qu'asynchrone (iDoc, Xml, fichier plat)...

 

Méthologie commune

Quelque soit le type et l'outil de développement, je vous conseille de suivre la même méthode de développement.

• Réaliser une analyse métier des fonctions que devrat supporter votre application web (en UML une modélisation cas utilisateur me semble parfaite).
• Identifier les RFC et BAPI qui matchent avec les besoins.
• Développer des RFC Z qui assurent le mapping entre l'application web et la ou les BAPI et RFC afin de réduire au stricte minimum les données échangées entre l'application web et SAP et le nombre d'appels RFC (quelque soit la plateforme web que cela soit SAP WebAS, .net iis, ou APACHE).
• Et développer les interfaces utilisateurs qui ne doivent contenir uniquement de la logique d'interface et aucune logique métier. La logique metier doit être gérée à 100 % dans du code ABAP sur SAP.

La force d'une telle méthode est qu'elle permet d'optimiser la performance de la solution, d'assurer des tests individuels de qualité et donc d'améliorer la robustesse de son application, et surtout de pouvoir plus facilement paralléliser le développement en gagnant ainsi énormément de temps. Pour cela il suffit de modéliser les méthodes. Les abapeurs commencent par créer des RFC qui renvoient des données correctement formatées mais statiques. Ainsi les développeurs web peuvent commencer le développement des interfaces pendant que les ABAPEUR implémentantes, telles des interfaces, les RFC.

Conclusion

La force de SAP est que directement (sur le webas) ou indirectement (depuis apache ou IIS), tous les types de développement web sont supportés, depuis du HTML statique jusqu'aux technologies RIA. L'important est de laisser le développement métier sur SAP R/3 ou BW, le reste étant juste une affaire de choix et de gout. SAP permet tout...C'est aussi simple que cela. De plus SAP sous des apparences vieillotes est en fait totalement up-to-date...

 

PARTIE N°2 : Les portails

Introduction

Historiquement les portails étaient des pages web fournis par les fournisseurs d'accès à internet (voir par exemple http://www.aol.fr) ou des moteurs de recherche (voir aussi http://www.yahoo.fr) qui avaient pour but de proposer une liste de liens internes (autres contenus du portail) ou externes (liens vers des sites extérieurs comme des annonceurs ou des sites d'actualités) sous la forme d'une page de une.

Puis dans la lignée de http://www.google.com/ig il est devenu possible aux utilisateurs de définir eux-même le contenu de leurs portails.

Enfin les portails sont devenus des aggrégateurs d'applications web et de données.

En parallèle à cette évolution fonctionnelle et conceptuelle des outils de création de portails sont apparus sur le marché. Parmi les leaders, on a Microsoft SharePoint, DotNetNuke (pour lequel j'ai écris quelques articles), ou encore l'excellent Joomla.

 

Qu'est ce qu'un portail ?

Un portail est un concept

Un portail est un site web qui propose une agrégation de contenus comme des liens internet internes ou externes, des données via des datagrids et des formulaires, des messages comme des forums ou des chats, des documents via l'intégration d'une GED, des fichiers à télécharger, du savoir (KM), des médias (vidéos, sons) etc... Le tout étant soumis à l'applications de rôles et d'autorisations qui définissent qui à le droit d'accéder à quoi et comment.

Un portail est aussi un outil et un framework

De fait, un portail est aussi le nom qu'on donne à des outils web comme NetWeaver Portal, Microsoft Sharepoint, Dotnetnuke, qui permettent de mettre en place un portail web sans connaissance technique particulière autre que fonctionnel et rédactionnel.

Dans ce cadre la majorité des portails propose des composants tels que :

• Publication et gestion de contenus HTML.
• Gestion de documents
• Gestion de messages : forums, chats, supports et gestion de tickets.
• Gestion de connaissance (KM).
• Intégration de liens et de syndication par flux RSS.
• Intégration XML+XSL.
• Intégration de formulaire et de datagrid.
• Gestion d'abonnement et de newsletter.
• Support multi-langue.
• etc...

 

Impact sur la gestion de projet

Selon la définition PRINCE 2, un projet  est une activité qui a un début un milieu et une fin. Hors la mise en place d'un portail est à la fois un projet, mais définit aussi un environnement hôte dans lequel des projets (applications web) seront intégré, c.à.d une infrastructure logiciele.

C'est pour cela que la meilleure façon d'approcher la gestion de projet portail est de bien séparer chaque partie en projet au sein d'un programme. Un portail mise en oeuvre devenant une infrastructure, on perd la notion de milieu et de fin qui définisse ce qu'est un projet.

Typiquement, on définit un programme dans le sens MSP. Puis on initie un premier projet de mise en oeuvre du portail, sur la partie générique qui sera utilisé par tous. La partie programme devant reprendre les aspects communs à l'ensemble des applications présentes et futures qui seront reprises dans le portail. On a ainsi :

• Définition des différents éléments du programme au sens MSP pour que le portail soit géré comme une infrastructure logiciele.
• Mise en oeuvre du projet de mise en oeuvre du portail sur la partie commune. Elle peut inclure d'ailleurs une partie collaborative et documentaire permettant à l'ensemble des chefs de projet d'applications PORTAIL de disposer de ressources communes.
• Mise en oeuvre pour chaque application web d'un projet (DIP).

L'important est de bien individualiser les projets dans le portail, donc de définir le périmètre exact d'un projet. Parfois cela se limite au développement d'un unique portlet, parfois c'est une collection de portlets.

 

Quel portail choisir ?

D'une manière naturelle et logique dans le monde SAP on a tendance a aller vers SAP NetWeaver Portal. Mais comme expliqué au dessus, un portail est un agrégateur d'applications web et de contenu. Donc cette fonctionnalité si elle peut être couverte par Netweaver Portal, elle peut l'etre aussi par d'autres portails. En fait on doit se poser plusieurs questions :

• Les modules génériques couvrent ils les besoins génériques du portail à mettre en oeuvre (nécessité de faire un comparatif).
• Le portail est il connecté qu'à SAP, ou doit il être connecté à d'autres plateformes, et dans quelle proportion ?
• Qui doit maintenir le portail ?
• A quel public est destiné le portail et quel impacte au niveau des conditions de license.

Pour ma part j'ai tendance à favoriser NetWeaver Portal pour tout ce qui est Intranet fortement orienté application SAP (BW, KM, DMS, etc...). Dans un cadre plus hétérogène, j'ai tendance à aller vers un portail open source comme DotNetNuke trés facilement connectable à SAP. Pour ceux qui ne l'avait pas remarqué, le portail DotNetNuke est celui que j'utilise pour le site www.sap-integration.net...

 

Les atouts de NetWeaver Portal

NetWeaver Portal est une solution SAP, donc c'est du lourd et du robuste. La gestion des rôles et utilisateurs est simple. La création et l'administration du contenu est tout aussi simple, même si il n'y a pas d'éditeur HTML intégré par défaut.

Reste que NetWeaver Portal est finalement assez simple à mettre en oeuvre à condition d'avoir une réelle compréhension fonctionnelle des portails (non spécifique à SAP).

La grande force de NetWeaver portal est qu'il est possible de développer des applications dessus avec un choix trés large d'outils.

• BSP
• BSP MVC
• BSP HTMLB
• WebDynPro ABAP OO ou JAVA (avec Netweaver Portal Studio)
• ADOBE FLEX (utilisé par SAP CRM et SAP SRM).
• JSP JAVA
• C# ou VB.net avec le PDK.net

il est aussi possible de développer des applications hostées sur un serveur internet autre et intégrées via un iFrame. OK cela peut paraitre môche, pourtant les iFrames sont fortement utilisés sur NetWeaver portal et constitue un atout de robustesse.

L'autre force de Netweaver est qu'il est trés facile, avec iView spécifique de publier des versions Portail des interfaces clients de SAP : Rapport BW, transactions SAP, interface avec SAP DMS pour la gestion électronique de documents, KM, etc...

Au final les points faibles de SAP Netweaver qui peuvent nécessiter des améliorations sont souvent liés aux aspects de message (forums et chats) et à une couche KM peut être un peu trop lègère. Pour tout le reste SAP NetWeaver Portal est tout simplement le meilleur choix... dans un contexte principalement SAP...

 

Conclusion

Encore une fois, tout est possible sur SAP. Et encore une fois les aspects métiers et fonctionnels sont plus importants et plus complexes que les aspects techniques (et sur toute platerforme portail). Dans la mise en oeuvre d'un portail est il est essentiel d'avoir une vision à moyen terme claire, de cadrer un portail avec un programme et une gestion robuste de l'infrastructure logicielle qu'est un portail. L'approche SOA (Service Oriented Architecture) se prète particulièrement bien, et permet de bien séparer la partie métier qui doit rester dans SAP de la couche de présentation gérée par le portail.

Les dangers liés à la mise en oeuvre d'un portail sont avant tout :

• Confondre l'outil portail avec le concept portail et donc utiliser un portail pour créer un site web qui n'est pas un portail.
• Mal gérer les projets et le programme (voir ne pas gérer de programme).
• Mal évaluer le devenir du portail et la navigation/rôle dans le portail (qui évolue toujours énormément).
• Choisir la mauvaise plateforme. Une migration de portail est un véritable enfer...
• Négliger la sécurité et l'infrastructure hardware.

Avec ce premier article j'initie une série d'articles consacrés à NetWeaver Portail, à WebAS, ainsi qu'à DotNetNuke connecté à SAP. j'espère profiter de vos commentaires critiques et suggestions pour proposer du contenu à l'ensemble de la communauté www.sap-integration.net ...

Amicalement 

Jérôme Fortias