La plateforme .net supporte naturellement les POCKET PC. L'approche que je vous propose se base à la fois sur .net côté Pocket PC et à la fois sur SAP pour la partie métier. Selon moi cette approche est de loin la moins risquée et la plus efficace si on souhaite disposer d'applications mobiles faibles et robustes connectées à SAP.
Scénario utilisé dans cet article
Une compagnie de distribution d'eaux souhaite équiper ses opérateurs terrains de Pocket PC raccordés à internet via GPRS afin de relever les compteurs, et que cela soit intégré avec SAP (et SAP IS-U).
Les bénéfices attendus par cette approche sont :
- Un développement de l'application Pocket PC 100% basé sur .net, donc rapide fiable et robuste. .net est la solution la plus naturelle sur Pocket PC.
- Un développement de la partie métier de l'application 100% basé sur SAP (en ABAP).
- Une couche d'abstration entre la couche métier (SAP) et la couche de présentation (le client Pocket PC) fournie par des webservices.
- La possibilité de développer des clients de différents types en utilisant les mêmes services.
- Une meilleure sécurité.
- Un cout licence beaucoup plus faible.
- Une gestion de projet simplifiée mais mixte (SAP et .net).
- Une approche S.O.A (Services Oriented Architecture).
Présentation de l'approche SOA utilisée...
Avec l'explosion des web services et des normes associées XML, SOAP, WSDL, (voir aussi le site http://www.w3schools.com) on a la possibilité d'ajouter aux couches habituelles (données/métier/présentation) une couche de service qui assure une abstraction entre le métier et la couche de présentation voir vers d'autres applications. La force de cette approche dite SOA est qu'elle permet d'exposer des services (métier) avec un standard supporté par toutes les plateformes techniques actuelles à des applications tiers de manière universelle sans devoir gérer des problêmes de compatibilité.
Dans le scénario que je vous présente, cette couche de service sera développée avec .net en C# et le SAP .net connector qui se connectera à SAP via le protocôle natif de SAP c'est à dire RFC pour invoquer des RFC ou des BAPI.
On aura ainsi du .net pour la création de web services et l'application mobile Pocket PC, et SAP pour l'ensemble des aspects métiers.
Cette séparation entre la partie service+présentation et la partie métier+données est vertueuse sur plusieurs aspects :
- Sécurité : La partie service n'expose uniquement que les services présents et offre donc une barrière métier entre SAP et l'extérieure, mais aussi une barrière technique en utilisant des protocôles de sécurité largement maitrisées (ssl, https, proxy, etc...)
- Disponibilité : il est possible d'implémenter dans la couche de service de la persistence de données ou encore des traitements asynchrones. On peut ainsi envisager que le service reste disponible même si les machines SAP ne le sont plus.
- Performance : la machine exposant les services n'étant dédiées à cela on a beaucoup moins de risque d'avoir des performances dégradées par des applications autres (comme je l'ai déja connu sur le SAP WEB AS...).
- La vitesse de développement : Développer des webservices et des applications mobiles est trés trés simple et rapide sur .net (cela nécessite que quelques jours de formations). En parallèle le métier reste à 100% sur SAP ce qui permet de profiter du meilleur des deux mondes.
En final on se retrouve avec une infrastructure de ce type.
Remarquez le serveur .net IIS. Cette infrastructure offre deux variations.
- Il est tout à fait possible de remplacer le serveur IIS .net par un SAP ECC 6 sans module métier mais avec le SAP WEBAS. Dans sa dernière version SAP permet d'exposer des RFC trés facilement sous forme de webservice. A vous d'évaluer les aspects de sécurités et de license.
- Il est aussi possible pour ne pas devoir utiliser le SAP.net connector en utilisant le service SOAP/RFC du serveur SAP WEB APPLICATION SERVEUR, pour mapper des RFC sur le serveur IIS.
Pour ma part, mais ce n'est qu'un choix, je ne préfére pas utiliser la couche web service de SAP parceque les RFC sont toujours plus surs et performants. J'ai tendance à limiter l'utilisation de webservices uniquement dans le cas de connexions System-to-System.
Les tâches à réaliser
- (SAP) L'analyse fonctionnelle. Quelles sont les actions métiers qui devront être supportées.
- (SAP) Identification des BAPI ou des RFC disponibles et nécessaire.
- (SAP) Si besoin développement Z de RFC le but étant de disposer d'une RFC par service afin d'optimiser les performances et de réduire au stricte nécessaire les données échangées entre le pocket PC et SAP.
- (.net / mobile) Analyse de l'interface utilisateur (saisie de données par code barre, clavier, stylet...), liste des écrans.
- (.net / mobile) Analyse du mode de connection. Connection synchrone, asynchrone, persistences des données, etc... Par exemple : l'opérateur pourrait charger l'ensemble des données nécessaires à ses visites de compteur le matin. Puis utiliser son application toute la journée. les données mises à jours étant transférées soit automatiquement, soit à la demande lors de la journée quand la connection est possible.
- (.net) la création des webservices.
- (.net / mobile) développement de l'application mobile.
Profils techniques nécessaires
Pour réaliser ce type d'approche il faut réunir plusieurs profils.
- Un bon abapeur maitrisant l'écriture de RFC et sachant créer des structures de données et de tables (SE11).
- Un développeur .net junior ayant des bases en webservice (le minimum), et en développement mobile (trés trés simple) et qui se forme à l'utilisation du SAP.net connector ou équivalent.
Les outils à avoir
- Visual Studio 2003 pour le développement des webservices avec le SAP .net connector (qui ne marche pas sur les autres versions de Visual Studio).
- Visual Studio 2003/2005/2008 pour le développement des applications mobiles.
- Le SAP .net connector (disponible sur http://service.sap.com/connectors)
- et SAP bien sur.
Alternative au SAP .net connector
Il est possible d'utiliser un outil comme ERP Connect, une librairie fantastique qui elle fonctionne avec les dernières versions de Visual Studio. (http://www.theobald-software.com/cms/en/erpconnect.net/erpconnect.net-sap-und-.net-nahtlos-verb.html )
Présentation de la démonstration
Afin de démontrer les avantages de cette approche j'ai réalisé en 8 heures une démonstration. Elle est constitué des éléments suivants.
La partie SAP est consituer d'une table Z, et de deux RFC Z
La partie webservice expose deux méthodes : getCounterInfo() et updateCounter()
Et l'application Pocket PC
Conclusion
En dissociant la partie métier qui reste sur SAP de la partie présentation, l'avantage principal est que le développement de l'application mobile comme des web services est d'une simplicité extrêmes (voir l'exemple de code en dessous). On utilise ainsi les meilleurs des deux mondes. .net pour développer sur le pocket PC l'interface utilisateur, et SAP pour la logique métier... cette approche permet aussi de designer quasiment en temps réels les écrans d'interfaces directement avec les utilisateurs. Son impact en terme de gestion de projet est réduite au minimum, et les compétences .net à voir sont minimes et peuvent etre acquises par un abapeur en quelques jours seulement. Quand aux couts de licences, c'est sans concurrence.
Intéressé ?
Je délivre des cours, et réalise des POC à la demande sur l'ensemble de l'europe. Ma démonstration est visible sur Louvain la Neuve. Pour en savoir plus merci de m'écrire à jerome.fortias@gmail.com. (références : ATHOS Bordeaux, Metalor (Suisse), TOT (Thailand)....
ANNEXE : Morceaux de code.
Le webservice avec utilisation du SAP .net connector.(sur miniwas 6.20).
[WebMethod]
public int updateCounter(string strNumCounter, string strMesure)
{
counterResult myResult = new counterResult();
string strSAPConnParameters="";
string SAPIP = "localhost"; // IP of the SAP server
string SAPUser = "BCUSER"; // SAP user, currently a RFC user
string SAPPassword = "MINISAP"; // SAP user password
string SAPSystem = "00"; // SAP system
string SAPClient = "000"; // SAP client
strSAPConnParameters = "ASHOST="+SAPIP+" USER="+SAPUser + " PASSWD="+ SAPPassword +" CLIENT="+SAPClient+" SYSNR="+SAPSystem;
try
{
SAPProxy1 mySAPConnection = new SAPProxy1();
SAP.Connector.SAPConnection conn = new SAP.Connector.SAPConnection(strSAPConnParameters);
mySAPConnection.Connection = conn;
byte iResult;
mySAPConnection.Zupdatecompteur(strMesure, strNumCounter, out iResult);
mySAPConnection.Dispose();
return 1;
}
catch(Exception ex)
{
return -1;
}
}
L'appel du webservice dans l'application mobile
vmminiwas.counterResult myResult = new DeviceApplication2.vmminiwas.counterResult();
vmminiwas.Service1 cc = new vmminiwas.Service1();
try
{
//cc.AllowAutoRedirect = true;
myResult = cc.getCounterInfo(txtCounterNum.Text.ToString());
txtClient.Text = myResult.strnom;
txtZip.Text = myResult.strzip;
txtVille.Text = myResult.strville;
txtAdresse.Text = myResult.stradresse;
txtLastDate.Text = myResult.strdate;
txtLastMesure.Text = myResult.strmesure;
}
catch (Exception ex)
{
//lblClient.Text = "error";
}