ALPAGA Guide Technique 04/07/2014 gipson_c - moros_a - larose_a - keller_t - lagouc_f - muller_c
Titre du document : Guide Technique Date : 16/03/2014 - Rassemblement des documents o Version : 1 o Date : 10/03/14 o Auteur : larose_a - Ajout du lien vers le javadoc o Version : 1.1 o Date : 11/03/14 o Auteur : lagouc_f Révision : - Ajout du lien vers le phpdoc o Version : 1.2 o Date : 11/03/14 o Auteur : muller_c - Relecture du document o Version : 1.3 o Date : 16/03/14 o Auteur : keller_t - Adaptation du document pour le TAF4 o Version : 2 o Date : 04/07/2014 o Auteur : keller_t - MAJ du document - Appli ios o Version : 2.1 o Date : 04/07/2014 o Auteur : muller_c Résumé du document Ce document est destiné à présenter l architecture technique de notre projet. Il permet également aux développeurs d avoir une meilleure connaissance du système Alpaga ainsi que des différentes parties qui le composent. Vous trouverez également dans ce guide des liens vers les documentations techniques détaillées de chacune des parties de notre projet, telle qu une javadoc pour l application android ou un phpdoc pour le web service. Ce document et les visuels le composant concernent l existant sur notre projet, il est donc amené à évoluer avec le développement des autres fonctions de notre projet. 1
Sommaire 1. Présentation de l architecture globale... 3 2. Communication et Protocole... 4 3. Web service... 5 3.1. Structure... 5 3.2. Validation des choix techniques :... 5 4. Applications Vendeur... 6 5. Application Acheteur... 0 5.1. Application mobile ios... 0 5.2. Application Android... 1 5.3. Application Windows Phone... 1 5.4. Validation des choix techniques... 1 6. Backend Organisateur... 2 2
1. Présentation de l architecture globale Le schéma ci-dessus présente l architecture largement simplifiée du projet Alpaga. On peut découper ce schéma en deux grosses parties : d un côté nous avons les vendeurs qui disposeront du matériel nécessaire (un smartphone, une tablette, un ordinateur, etc ) afin d interroger un serveur Alpaga. De l autre, nous avons toute l infrastructure que nous pourrons mettre en place lors d un événement, invisible tant pour l acheteur que pour le vendeur. L idée est de garder un service à la fois extrêmement simple tout en conservant une sécurité optimale. 3
2. Communication et Protocole 1. Requête de l organisateur au serveur principal pour consulter les reportings ou paramétrer l application pour l évènement. (Protocole http) 2. Requête de l acheteur au serveur principal pour consulter ses dépenses. Des requêtes sont également effectuées vers l api de paiement pour créditer le compte Alpaga. (Protocole http) 3. Scan du QR Code via un mobile et envoie des informations à l application mobile. 4. Requête de paiement suite au scan du code barre, et stockage des transactions en base de données. (Protocole http) 4
3. Web service 3.1. Structure Un phpdoc présentant les différentes méthodes de notre web service est disponible à l adresse suivante : http://eip.epitech.eu/2015/alpaga/docs/webservice/ Voici un schéma expliquant le traitement des requêtes par notre web service : Requête Middleware d'entrée Verification du header json Verification des valeurs du checksum, du timestamp et de l'id du client Traitement de la requête par le controleur Formatage Json de la sortie Ajout du checksum Middleware de sortie Réponse Les routes sont gérées par le micro Framework silex. Les liens se composent du contrôleur puis de la méthode. Par exemple : /user/finduserbyid/ appellera la méthode finduserbyid du contrôleur user. 3.2. Validation des choix techniques : Choix technique initial : Le web service est implémenté en PHP 5 avec comme architecture REST. REST va nous apporter une grande flexibilité dans la conception grâce à l indépendance du client par rapport au serveur. La base 5
de données retenues est MySQL. Ces services seront installés sur le serveur de paiement. Ce serveur tournera sous Debian. Afin de nous connecter au BDD nous allons utiliser la PDO de PHP. PDO constitue une couche d'abstraction. Elle intervient entre le serveur d'application et le serveur de base de données. La couche d'abstraction permet de séparer le traitement de la base de données. Ainsi on peut migrer vers un autre SGBD sans pour autant changer le code déjà développé. Validation : Le Web Service est bien implémenté en PHP 5. Nous nous aidons du micro framework Silex (http://silex.sensiolabs.org/) afin de gérer plus facilement les routes. Le Web Service est compatible avec de multiples bases de données telles que MySQL et PostgreSQL. Afin de faciliter cette compatibilité, nous utilisons une surcouche à PDO nommée Doctrine DBAL (http://www.doctrine-project.org/projects/dbal.html). 4. Applications Vendeur 4.2 Application mobile ios À l'heure où sont écrites ces lignes, l'application Alpaga dédiée aux vendeurs est encore en cours de développement. La figure ci-dessous décrit les différentes vues de l'application. Vous trouverez une documentation technique du code à l'url suivante : http://eip.epitech.eu/2015/alpaga/docs/ios/sellers/. 6
5. Application Acheteur 5.1. Application mobile ios Le développement de l'application Alpaga dédiée aux vendeurs est actuellement fini. Il est toutefois possible que cette application subisse quelques changements voire d'ajout de fonctionnalités. La figure ci-dessous décrit les différentes vues de l'application. Vous trouverez une documentation technique du code à l'adresse suivante : http://eip.epitech.eu/2015/alpaga/docs/ios/buyers/.
5.2. Application Android L'application Alpaga dédiée aux acheteurs sur Android reprend les éléments graphiques de l application ios. L appareil scan les QRcode grâce à la lib ZBAR et utilise la librairie loopj pour les requêtes http (http://loopj.com/). Une documentation technique du code est disponible sous forme de javadoc à l adresse suivante : http://eip.epitech.eu/2015/alpaga/docs/android. 5.3. Application Windows Phone Cette application est en cours de conception / développement. Nous intègrerons les informations d utilisations associées à des visuels afin d en expliquer son fonctionnement. 5.4. Validation des choix techniques Pour le développement de nos applications sur les trois systèmes d exploitation les plus utilisés, Nous développons ces applications en natifs et utilisons donc pour chacun les langages spécifiques à leurs développement : Java pour android, C# pour Windows Phone et Objective-C pour ios. Pour la lecture et génération de QR code nous utilisons une librairie existante : ZBAR (http://zbar.sourceforge.net/). Zbar est une suite de logiciel libre permettant facilement de lire toutes les sortes de code-barres dont les QR Code. Réputé facilement intégrable dans des projets variés, nous allons l'utiliser pour lire nos QR Code scannés sur smartphones. Les points forts sont sa puissance, sa facilité d'utilisation et surtout sa stabilité. ZBAR lit une image en balayage linéaire. L'image est scannée, décodée et assemblée à la volée. Cette technique permet d'avoir à la fois une grande vitesse de lecture mais aussi une bonne stabilité. De plus ZBAR est souvent mis à jour, ce qui permet de prévenir d éventuels problèmes. ZBAR n étant pas compatible avec WindowsPhone, et l application étant encore en cours de développement, nous sommes en cours de recherche pour trouver un équivalent correspondant à nos attentes. 1
6. Backend Organisateur 6.1. Technologies utilisés Le backend se présente sous la forme d un site web. Nous utilisons comme pour le web service le micro-framework php silex. Comme pour le webservice, nous rajoutons le composant DBAL pour gérer la connexion avec la base de données. Nous utilisons également le moteur de template TWIG (http://twig.sensiolabs.org/), et le composant de sécurité inclus dans silex (http://silex.sensiolabs.org/doc/providers/security.html) pour gérer l authentification du staff. Les dépendances concernant silex et les modules cités ci-dessus sont gérées grâces à composer (https://getcomposer.org/). Nous utilisons Bootstrap 3 comme framework CSS. Afin d effectuer des opérations de tri et de filtre sur les différentes tables présentes sur le site, nous utilisons le plugin datatables (https://datatables.net/) Pour effectuer la validation cote client, nous utilisons le plugin jquery Validation (http://jqueryvalidation.org/). 6.2. Classes utilitaires Deux classes simples ont été développées afin de faciliter certaines actions sur le site, une classe de pagination qui comprend une méthode paginate : public static function paginate($page, $array, $elem_per_page) Cette fonction prend en argument la page que l on souhaite charger, le tableau d éléments à paginer et le nombre d élément que l on souhaite afficher. Elle retourne un tableau avec les éléments à l index data et le nombre de page à l index nb_page. Pour utiliser cette classe, il suffit d ajouter use Alpaga\Lib\Pagination; au début d un fichier. Il y a également une classe pour générer un csv avec une simple méthode : public static function arraytocsvfile($filepath, $array) Elle utilise la function fputcsv fournis par PHP pour remplir le fichier (http://www.php.net/manual/fr/function.fputcsv.php) 2