Introduction à SharePoint et SAP :
Voila des années que je travaille dans le domaine de l'intégration .net et SAP jusqu'ici pour de toutes petites applications ou des connecteurs. Mais depuis quelques temps, un produit Microsoft est en train de bouleverser la donne .... Microsoft SharePoint 2010 (voir aussi le site officiel).
Fan d'un autre portail .net DotNetNuke (celui même que j'utilise pour b-integration.net) j'avoue avoir été surpris par SharePoint et surtout sa pénétration dans les grands comptes. Même si je reste critique sur certains points je dois bien avouer que l'intégration de ce portail avec Microsoft Office et les autres produits de Microsoft est excellente.
Mais là ou cela devient des plus intéressants, c'est que si SAP NetWeaver Portal n'a pas été le succès escompté (trop SAP), il est très facile de développer des applications SharePoint connectées à SAP.
Le but de cet article est donc de vous initier à cela mais aussi de vous proposer un modèle de développement avec les formations qui vont avec.
Je me dois d'ajouter que tout ce que j'écris dans cette article s'applique aussi bien à Microsoft SharePoint qu'à DotNetNuke.
Mais qu'est ce qu'un portail ?
Pour résumer un portail est un accès unique à différentes fonctions de l'entreprise pour une audience précise avec une charte graphique commune, une authentification commune, et la possibilité de personnaliser les contenus et les comportements des applications en fonction d'autorisations.
C'est donc à la fois un outil d'intégration d'applications et aussi un outil d'aggrégation de contenu (c.à.d un contenu unique qui "mélange" de manière pertinentes différentes contenus depuis différentes sources).
Techniquement un portail est à la fois un framework et à la fois une infrastructure ou déployer ses applications.
Fonctionnellement un portail est un support de connaissances de documents et d'application MAIS AUSSI la possibilité de créer de l'intelligence c.à.d créer dynamiquement des liens entre des informations et concepts qui paraissaient dissociés.
L'objectif réel de la mise en place d'un portail Microsoft SharePoint, ou DotNetNuke.
L'objectif premier d'un portail est de fournir sur une interface unique (web) l'ensemble des applications pour une audience précise.
Pour cela on doit définir des choix d'architecture basés sur plusieurs critères (OK je me répète mais bon) :
- La performance et l'ergonomie
- La sécurité
- La maintenabilité
- L'internationalisation
- et l'impact sur les licenses.
Puis on doit distinguer ce qui est du domaine de l'intégration (une application tiers qui est intégrée dans Microsoft SharePoint) à de l'aggrégation (plusieurs backends connecté ensemble dans un webpart unique selon le principe que l'intelligence est la capacité de créer des liens entre des concepts appararements distincts) nécessitant du développement spécifique.
Les modèles de développement pour SharePoint 2010
Typiquement nous avons 3 modèles de développement sur SharePoint.
- Développement SharePoint pur Càd du développement de webpart pour enrichir SharePoint en se basant sur le framework et les objects SharePoints (Documents, Workflow, taches, etc...).
Pour cela je propose le modèle suivant : Ecran écrit avec les contrôles SharePoint, l'utilisation d'un IOC comme Castle.
- Développement de Webpart connectés à des backends (sauf SAP).
Pour cela je propose le modèle suivant ; Ecran écrit avec les contrôles SharePoint, l'utilisation d'un IOC comme Castle, utilisation d'un ORM comme nHibernate.
- Développement de WebPart connectés à SAP.
Pour cela je propose le modèle suivant : Ecran écrit avec les contrôles SharePoint, utilisation d'un IOC comme Castle, utilisation de la bibliothèque ERPCOnnect de Theobald Software.
Que peut-on intégrer dans Microsoft SharePoint ?
Tout ! On peut tout intégrer dans Microsoft SharePoint (comme dans DotNetNuke). Aprés cela dépend des cinq critères ci dessus qui vont déterminer la faisabilité....
Mais il faut distinguer plusieurs types d'intégration :
- De SharePoint vers d'autres applications :
- De manière synchrone.
- De manière asynchrone.
- De manière presque temps réel.
- Des autres applications vers SharePoint
- De manière synchone.
- De manière asynchrone
- De manière presque temps réel.
les exemples d'intégration Microsoft SharePoint
Microsoft office
Certainement la force principale de SharePoint, son intégration avec Microsoft Office. Ainsi depuis MS Word, Excel etc on peut publier ses documents, et créer de nouvelles versions dans le DMS de SharePoint. Il est possible aussi par exemple de créer un blog sur SharePoint et l'alimenter via MS Word. Idem pour les tâches, l'intégration outlook, ou avec d'autres produits comme MS Project. Si il y'a une raison pour avoir SharePoint c'est bien celle ci. Sans cela je préfèrerais DotNetNuke (http://www.dotnetnuke) qui est mieux fait pour le collaboratif.
SAP
C'est le core-business du site b-integration.net. Il existe plusieurs intégrations possibles :
- Ecran SharePoint connecté à SAP en temps réel (comme on ferait dans SAP NetWeaverPortal). --> ProxyClient ou consommation de webservices et/ou d'XML Feeder.
- Intégration d'un Workflow SharePoint à SAP (appel de RFC/BAPI, envoi d'iDoc). --> ProxyClient ou consommation de webservices.
- Interaction en ABAP des fonctions et avec le framework de Microsoft SharePoint, .net et MS Office --> ProxyServer.
La couverture fonctionnelle est exactement la même qu'avec SAP NetWeaverPortal.
| Client |
Serveur |
Message |
Transport |
Commentaires |
| Webpart SharePoint |
SAP |
RFC, iDoc, BW, BAPI |
Connexion native |
Accès synchrone aussi performant qu'un SAP GUI mais nécessite une license SAP par utilisateur. |
| Webpart SharePoint |
SAP |
RFC, iDoc, BW, BAPI |
Web Service |
idem, mais nécessite d'activer le service SOAPRFC dans le SAP WAS, et est un peu moins safe et performant qu'un accès natif. |
| Infopath ou XML/XSLT |
SAP WebAS |
http post + réception d'XML |
http |
des XML sont créés sur le SAP WEB AS et SharePoint les consomme.Avantage est qu'on peut utiliser des XSLT facilement maintenable. Par contre il faut une license SAP par utilisateur SharePoint de l'application. |
| SAP |
Proxy serveur .net |
ZRFC, iDoc |
connexion native. |
Dans ce cas SAP se connecte via SM59 à un proxy serveur développé en .net. SAP est le client (consommateur du service). L'avantage est qu'il n'y a aucune licence à gérer, la license étant à gérer dans le proxy server. Cela permet de développer les fonctionnalités qu'on veut dans le proxy serveur et de les rendres accessibles aux développeurs SAP (en ABAP avec un call function) et aux équipes systèmes via des mappings sur des flux ALE. |
| Service .net |
SAP |
RFC, iDoc, BAPI |
connexion native |
Si vous avez un process qui ne nécessite pas une connexion temps réel à SAP, vous développez des services qui vont extraire les masters datas nécessaires périodiquement (vous pouvez gérer un cache de 2nd niveau). Dans le cas d'une intégration avec SharePoint on peut imaginer un service qui va récupérer les résultats finaux d'un workflow SharePoint pour transférer des données dans SAP comme pour les master datas ou encore des processus de validation de commandes fournisseur. |
| |
|
|
|
A suivre.... |
|
DMS (Gestion Electronique de Document)
La très grande majorité des éditeurs de DMS et d'outils d'archivage propose des solutions intégrés avec SharePoint. Pour celui que je connais le plus LiveLink (je suis certifié sur LiveLink comme consultant), l'offre est complète :
Cela fait d'autant plus de sens que même si SharePoint intègre une gestion de document, je vois deux raisons de préferer un DMS extérieur.
- En cas d'une très grande quantité de documents il est préférable de séparer le frontend (le portail) du backend (le DMS) surtout quand on exploite pleinement les capacités d'un DMS comme LiveLink. C'est d'autant plus vrai si on utilise derrière une politique d'archivage avec des signatures électronique ou des chaines de dématérialisation de documents.
- Les DMS comme ceux d'OpenText, IBM, emc2, etc... sont autrement plus puissants.
Au passage pour des besoins simple il est possible de développer son propre webpart connecté à LiveLink en utilisant les DLL de LAPI pour la version 9.7 de LiveLink et les webservices de la version 10.
Logiciels d'Atlassian
Atlassian est l'éditeur du wiki et de l'outil de ticketing les plus répandus : Confluence, et JIRA. Confluence est par exemple le wiki du site http://sdn.sap.com de SAP. Quand à JIRA on le retrouve dans de nombreuses entreprises des plus petites aux plus grandes (10 $us pour 10 users, parfait pour les startup).
Pour JIRA, il existe un connector pour http://wiki.customware.net/repository/display/AtlassianPlugins/Connector+for+SharePoint+and+JIRA.
Pour confluence aussi http://www.atlassian.com/software/sharepoint-connector/overview permettant ainsi d'avoir un véritable WIKI dans Microsoft SharePoint.
Autres logiciels
SharePoint est suffisamment facile pour que de nombreux éditeurs proposent leurs solutions adaptées pour SharePoint... Mais je reviendrais la dessus plus tard.
La gestion de projet Portail sur SharePoint
Il faut voir un portail comme étant une infrastructure. Il est donc préférable de splitter un projet unique de mise en place d'un portail en plusieurs projets séparés.
Projet n° 1: Mise en place du portail en tant qu'infrastructure.
L'objectif de cette phase est de mettre en place techniquement le serveur SharePoint, fixer les pré-requis de sécurité y compris pour les documents, produire les documents de gouvernance de projet SharePoint et de gestion des tests et déploiements.
Projet n° 2 : L'environnement collaboratif pour le suivi du portail des utilisateurs et des développements.
La force d'un portail est d'etre d'une certaine manière auto-supportée. Pour chaque application que vous déploier dessus vous pouvez fournir un lien vers la documentation, vers le support, vers un forum de discussion associé à l'application. Dans cette phase il est donc nécessaire de mettre en place la partie collaborative avec les parties suivantes :
- Publication des documents de gouvernance.
- Création d'un espace pour les utilisateurs avec un forum de discussions pour l'assistance
- Création d'un espace de génération de ticket de support.
- Création d'un espace pour interface l'équipe système et les développeurs de projets SharePoint.
- Création d'un template de spécification pour les développements d'applications SharePoint reprenant les 5 points clés.
Projet n°3 : Organisation fonctionnelle du portail.
- Analyse des besoins : Définitions des audiences visées, définitions de la taxonomie des documents, définitions des roles de sécurité, etc.
- Mise en place de la charte graphique.
- Mise en place de la navigation sur le site
Projet n°4 : Collaboration, KM et formation.
Un portail est un changement de culture totale si vous abordez cela dans le sens de la collaboration et du knowledge management (la gestion de la connaissance). Cette partie est si complexe que je ne vais pas l'aborder ici. Mais pour vous donnez une idée cela repose sur deux questions clés : Quel est le bénéfice de chacun à collaborer et comment faire pour valoriser plus le faire savoir que le savoir.
Cette étape doit aussi inclure la mise en place d'action d'initiation d'une communauté ce qui nécessite à ses fondateurs de montrer l'exemple.
Projet n°X : Développement d'application sur le portail
A partir de là un portail n'est jusqu'une infrastructure. Toute application développée dessus doit répondre aux 5 points clés....Cette partie là nécessite aussi un article en soi.
Le projet SharePoint pour SAP de b-integration.net
Dans le cadre de développement de projets open source sur le site, je lance une section consacrée à SharePoint. Mon objectif est de vous proposer des modules SharePoint pour SAP, et d'animer une communauté Microsoft SharePoint SAP.
Exemple d'un premier module pour vérifier les utilisateurs SAP directement depuis SharePointnt
Les bons pré-requis techniques pour développer sur SharePoint
Bien sur il faut connaitre C#, Webform et/ou MVC et un minimum le framework .net 3.5. Mais je vous conseille surtout de maitriser les outils suivants :
Conclusion
SharePoint est une possibilité fantastique d'associer le meilleur de SAP (le Backend) avec le meilleur de Microsoft et de quoi occuper mes vieux jours pendant quelques années. Mais un portail c'est aussi l'animation d'une communauté, un travail d'adhésion, la possibilité de structure la connaissance de l'entreprise d'améliorer la collaboration mais aussi les liens humains... Et surtout le portail est le frontend idéal pour créer de l'intelligence.... Cela fait 8 ans que je fais du portail. Et c'est pour moi une passion même si j'ai la conviction que nous pouvons aller beaucoup plus loin....
Pour information, la société APPLIUM sponsor de ce site sans laquelle nous n'existerions plus, investi beaucoup sur SharePoint avec mon aide. Alors si vous êtes intéressé, contactez les (et/ou moi à contact@jfortias.com).
Remerciement
Je remercie au passage Pascal Van Vlanderen pour m'avoir mis le pied à l'étrier et m'avoir appris tant de chose sur SharePoint. Dank U (c'est un flamand).
Liens sur b-integration.net à propos de SharePoint et SAP.
Sur le blog :
Dans la section articles :
Dans la section forum :
Liens internets :