SAP et Android: ksoap2-android (partie 3)

Notre objectif est de réaliser une application simple pour rechercher et afficher des fiches clients :

Les étapes pour construire cette application sont les suivantes:
- interroger SAP via un webservice en utilisant la librairie ksoap2-android
- encapsuler la gestion des données clients dans un ContentProvider pour ajouter un niveau d'abstraction, et rendre accessibles nos fiches clients aux autres applications (par exemple si nous décidions de faire un lien entre une application de commande et la fiche client), via nos propres URI du type contents://com.kimveasna.customerprovider/customer/#
- exploiter les applications googles pour appeler, envoyer des messages, localiser et naviguer, via les intents
- on peut ajouter facilement des méthodes alternatives de recherche, par code barre par exemple en exploitant les intents

SAP et Android: ksoap2-android (partie 2)

Avant toute chose, commençons par exposer quelques BAPIs en webservices. Pour rappel, nous allons créer une application android qui va nous permettre de consulter nos fiches clients. Une fonction BAPI que nous allons exploiter est par exemple BAPI_CUSTOMER_FIND.

Pour simplifier, et en vue d'une utilisation plus étendue dans le futur, nous allons exposer le groupe de fonctions LC01 auquel appartient cette fonction.

La création d'un webservice se fait directement dans le navigator:

Je passe sur la suite de la création, assez triviale. Choisissez les fonctions à exposer selon votre goût, et sachez que vous pourrez revenir dessus plus tard. Une fois terminée, vous avez une définition de service prête à être exposée:

Ce n'est pas fini (ou presque), il faut maintenant le déployer, ce qui se fait par la transaction SOAMANAGER. Laquelle va lancer le navigateur sur un webdynpro de gestion. Le 2e onglet est celui qui nous intéresse:

Dans "Administration service Web", nous allons nous créer un point d'accès pour le webservice. Je passe encore une fois les détails, mais au final on a une entrée dans les points d'accès:

C'est à peu près tout, on peut maintenant aller chercher la WSDL qui nous sera utile pour consommer notre service.

Ce que je vous conseille, c'est d'utiliser un client SOAP pour observer et tester vos services, comme l'excellent soapUI, qui vous permettra d'analyser les messages SOAP ou HTTP et de résoudre vos problèmes rapidement.

Notre service est déployé ! Passons à la suite ...

SAP et Android: ksoap2-android (partie 1)

Il n'existe pas d'API en standard pour appeler un webservice sous android. Une solution est d'utiliser la librairie ksoap2 pour android.
Les choses ne sont pas aussi triviales qu'avec le Flex, et il faut construire à la main sa requête SOAP, et ensuite parser le résultat soi-même.

On commence par construire une requête:
SoapObject request = new SoapObject(NAMESPACE, METHOD_NAME);

Les paramètres de la requête sont transmis par la méthode addProperty :
request.addProperty("NomDeParametre", "ValeurDuParametre");

Puis une enveloppe SOAP est créée pour encapsuler la requête :
SoapSerializationEnvelope envelope 
   = new SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.setOutputSoapObject(request);

Notre SOAP est lui même encapsulé dans une enveloppe HTTP :
HttpTransportSE httpTransport = new HttpTransportSE(URL);


On appelle le service :
httpTransport.call(SOAP_ACTION, envelope);

La réponse, brute, est alors disponible dans l'enveloppe HTTP, sous forme de String:
responseDump = httpTransport.responseDump;


Vous pouvez utiliser la réponse, en appelant la méthode getResponse. Dans la pratique, l'étape de lecture et parsing du XML est très longue avec la librairie ksoap2, et le résultat pas exploitable en l'état.
Et il vaut mieux parser soi-même la réponse XML :
XmlPullParserFactory factory = XmlPullParserFactory.newInstance();
factory.setNamespaceAware(true);
XmlPullParser xpp = factory.newPullParser();
xpp.setInput( new StringReader ( responseDump ) );
...




Toutes ces explications, c'était la théorie. Dans la réalité, tout ne fonctionne pas "out-of-the-box", et il faudra retoucher/étendre la classe SoapSerializationEnvelope, ou retoucher/étendre la classe HttpTransportSE (notamment pour gérer l'authentification).
Passons à la pratique avec un cas simple: la visualisation d'une fiche client.

SAP: oubliez vos dynpros, place au Flash ou à des interfaces iPhone ou Android !

SAP Gui est austère, je pense qu'il n'y a pas vraiment de débat là dessus. C'est sûr, les interfaces sont fonctionnelles, carrées, etc., mais sérieusement, je comprends que SAP soit souvent utilisé en back office, mais tout de même, on a beau être en back office, on n'a pas le droit à des interfaces un peu plus simples, plus modernes, plus "web-isées" ?

Très honnêtement, il est rapide est facile de créer des écrans SAP en ABAP. Le problème que je remarque, c'est que bien souvent, les développements spécifiques ne respectent pas les standards SAP :

• utilisation incorrecte des évènements START-OF-SELECTION, AT-SELECTION-SCREEN, etc.
• utilisation incorrecte des interactions dans les PBO, PAI
• sélections abusives en table sans usage des BAPIs standards
• choix aléatoires dans la conception (module fonction à appeler ou programme à appeler via SUBMIT ?)
• inconsistance dans l'interface graphique (les boutons sont placés n'importe où, les grilles de données n'occupent pas toute la place à l'écran, les champs ne sont pas alignés, ...)

Et j'en passe ... le problème fondamental est en réalité tout autre, il s'agit de problèmes de conception, et dépasse le simple cadre de l'interface graphique. Et bien souvent, les normes de développement en place sur les gros projets ne font que palier superficiellement à un manque d'élaboration en amont. A quoi bon avoir dans son programme des variables nommées correctement selon des normes imposées, quand le fonctionnement du programme lui même pose problème parce qu'il est mal conçu ?

Avant de commencer à élaborer des programmes à effets de bords (en opposition aux simples reportings de données), il faut s'interroger sur les objets que nous allons manipuler.

Mais quels rapports avec les interfaces en flash, web, iphone ou android ? On met le doigt dessus. Vous voulez ouvrir votre système à des interfaces plus évoluées non écrites en ABAP/dynpro ? Eh bien, bonne nouvelle, SAP est un système ouvert ! Mauvaise nouvelle, la plupart des développements ABAP ont fait perdurer des paradigmes de programmation d'un autre âge, où la logique métier n'était pas désolidarisée de l'interface graphique. 

Pour la suite, suivez le guide:

1. BOR, BAPI, WS, SOA ... késako ?
2. Exposer un WebService
3. Hello SAP World !

BOR, BAPI, WS, SOA ... késako ?

SAP ECC est un ERP où cohabitent de nombreux "objets métiers" : les clients, les commandes d'achat, les commandes client, les fournisseurs, et bien, bien d'autres.

On pense à tort que les commandes clients se résument aux tables de documents commerciaux, VBAK et VBAP. Je cherche une commande, hop je sélectionne dans VBAK. Je veux créer une commande, j'ai quand même la présence d'esprit d'utiliser une BAPI. Ouf.

Ô grand dieu, SAP c'est quand même un peu plus que ça. Même s'il est à déplorer que beaucoup trop de développements ABAP sont constitués d'agglomérats de sélections diverses dans les tables SAP, le système offre bien d'autres possibilités.

Il parait évident qu'un programme n'ira jamais créer une commande client à l'aide d'insertion directe en table dans VBAK+VBAP. C'est évident ... mais pourquoi ? Parce qu'une commande est plus qu'une entrée dans une table, c'est un objet à part entière, et son entrée de table n'est qu'une forme de sérialisation dans SAP. 

Les objets dans SAP sont visibles dans le BOR (Business Object Repository).

Un objet du BOR propose des méthodes pour le manipuler. Comme par exemple, une méthode de création :

Derrière cette méthode se cache un module fonction (ce qui n'est pas toujours le cas), et précisément ici un module fonction BAPI. 

BAPI est l'acronyme de Business API. Les BAPIs offrent un panel de fonctions permettant de manipuler les objets en ABAP, mais pas seulement. L'avantage d'une BAPI sur une manipulation brute des données en table est qu'elle permet de respecter l'intégrité des données d'une part, mais aussi entre autres de respecter le flux de normal de création en déclenchant les évènements comme le fait SAP en standard. C'est d'ailleurs par le BOR que l'on passe pour faire du workflow.

Le BOR et les BAPIs sont donc liés: une BAPI est liée à un objet du BOR, mais l'inverse n'est pas toujours vrai.

Fort bien, mais à quoi ça me sert tout ça ?

Cela va servir à faire de meilleurs développements en ABAP tout d'abord. Vous devez utiliser au possible les BAPIs existantes et éviter les manipulations de tables. La règle est la même que pour n'importe quel autre langage de programmation: utiliser des APIs et ne jamais réinventer la roue. Si une BAPI manque, il faut réfléchir en terme d'objet, étendre le BOR s'il le faut, et créer des fonctions BAPIs complémentaires en favorisant la ré-utilisabilité.

Cela parait évident, et pourtant dans la pratique on est loin du compte. Bon nombre de développements mêlent sélections, interactions, sauvegardes sans réelle organisation, en s'affranchissant d'un modèle MVC ou 3-tiers. 

Mais surtout, une bonne conception va faciliter l'exposition de nos objets SAP, notamment à travers des webservices. Toute la logique métier résidera dans la partie ABAP, et les foncitons de manipulation seront rendues publiques au monde extérieurs via des services.

Notre système SAP devient alors un fournisseur de services, et s'inscrit dans une architecture SOA (Service Oriented Architecture).

Fort bien, fort bien. Ça me parait un peu vague tout ça. 

Bien, entrons dans le vif du sujet, créons notre webservice et un programme qui va utiliser ce service.

Pour aller plus loin

Trouver les bonnes informations sur les objets SAP n'est pas toujours évident. En premier lieu, il faut regarder dans le BOR ou les BAPIs ce que l'on a à disposition (transactions SWO1 et BAPI). Le forum SDN regorge aussi d'information, et on pourra citer notamment cet article intéressant : http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/22689 lequel renvoie vers http://esworkplace.sap.com/.

Android et Adobe AIR

Flex - 3D API