<\/p>\n\n\n\n
Sch\u00e9ma g\u00e9n\u00e9ral d’architecture:<\/h2>\n\n\n\n
<\/p>\n\n\n\n Je suis parti d’une application standard qui \u00e9tait fournie avec les pr\u00e9c\u00e9dentes versions d’Oracle APEX et qui s’appelait Incident Tracking<\/a><\/em>. Puisque cette application n’est plus disponible dans les version r\u00e9centes d’APEX, je l’ai r\u00e9cup\u00e9r\u00e9e depuis une version 18.x. Cela m’a permis de r\u00e9utiliser le mod\u00e8le de donn\u00e9es qui \u00e9tait de qualit\u00e9 et de proposer un d\u00e9marrage rapide. Mais au fur et \u00e0 mesure, il s’est av\u00e9r\u00e9 que l’\u00e9cart fonctionnel \u00e9tait plus grand que pr\u00e9vu. R\u00e9trospectivement, je serais plut\u00f4t parti d’une feuille blanche, tout en conservant le mod\u00e8le de donn\u00e9es.<\/p>\n\n\n\n L’allure g\u00e9n\u00e9rale est tr\u00e8s proche de celle d’origine, mais il y a eu beaucoup de r\u00e8gles m\u00e9tiers sp\u00e9cifiques qui ont \u00e9t\u00e9 rajout\u00e9es et qui ont fait bouger \u00e9galement le mod\u00e8le de donn\u00e9es. Toutes les informations du clients sont r\u00e9cup\u00e9r\u00e9s, en particulier, depuis un ERP par appel d’un service Web. Pour le reste, il s’agit d’une application classique de gestion.<\/p>\n\n\n\n Les \u00e9l\u00e9ments de conversation entre le(s) technicien(s) et le client sont rassembl\u00e9s dans un onglet Conversations<\/em> et sont issus du sous-syst\u00e8me d’interactions, tel que d\u00e9crit plus loin.<\/p>\n\n\n\n L’onglet Documents <\/em>contient la liste des liens vers Google Drive<\/em> dans le cas o\u00f9 le client aurait envoy\u00e9 des fichiers descriptif du probl\u00e8me sous forme de photos et vid\u00e9os.<\/p>\n\n\n\n J’ai profit\u00e9 des nouveaut\u00e9s des version r\u00e9centes d’APEX, en particulier la recherche par facettes, pour am\u00e9liorer l’ergonomie et j’ai rajout\u00e9 la possibilit\u00e9 de se connecter avec son compte Google Workspace puisque chaque technicien en disposait.<\/p>\n\n\n\n Tr\u00e8s peu de modifications ont \u00e9t\u00e9 n\u00e9cessaires pour obtenir un fonctionnement correct sur mobile. J’ai simplement utilis\u00e9 des classes (hidden-xxs-down et hidden-xs-up) pour switcher sur une pr\u00e9sentation plut\u00f4t qu’une autre au sein d’une m\u00eame page. C’est typiquement le cas pour les listes de type \u00ab\u00a0Interactive Grid\u00a0\u00bb qui auraient impos\u00e9 du scrolling sur un petit \u00e9cran et auxquelles j’ai substitu\u00e9 des list View<\/em>s. <\/p>\n\n\n\n Ce deuxi\u00e8me bloc est destin\u00e9 aux interactions avec les clients finaux. Il repose sur l’emploi de plusieurs modules de la suite Google Workspace<\/a><\/em>. La compagnie disposait d\u00e9j\u00e0 d’un abonnement \u00e0 ce service pour la messagerie et il n’a pas \u00e9t\u00e9 n\u00e9cessaire de souscrire \u00e0 des options compl\u00e9mentaires.<\/p>\n\n\n\n Concevoir et mettre \u00e0 disposition des formulaires d’ouverture de ticket ou de demande de statut directement sous Oracle APEX aurait entrain\u00e9 la communication de l’url du backoffice <\/em>aupr\u00e8s de chaque client. Un contournement \u00e9ventuel aurait consist\u00e9 \u00e0 utiliser le Load Balancer<\/em> disponible dans le tenant <\/em>en reverse Proxy<\/a> et d’y placer des r\u00e8gle de routage en fonction de l’application \u00e0 utiliser. A l’\u00e9poque, je n’\u00e9tais pas familier avec la technique pour le faire et, de toute mani\u00e8re, cela aurait pos\u00e9 le probl\u00e8me de la charge du syst\u00e8me car si je connaissais le nombre d’utilisateurs internes (les analystes), je ne connaissais pas le nombre de clients qui se connectent \u00e0 un instant donn\u00e9. Un nombre \u00e9lev\u00e9 de connexions aurait entrain\u00e9 la fermeture arbitraire de sessions d\u00e9j\u00e0 ouvertes, puisqu’il y a un pool limit\u00e9 dans le cas de Oracle Free Tiers<\/a>, et cela aurait p\u00e9nalis\u00e9 l’acc\u00e8s par les technicien comme le laisse supposer l’extrait suivant des limitations<\/a>:<\/p>\n\n\n\n The HTTP interface of Always Free APEX Service is rate limited to restrict the number of simultaneous service users. Approximately 3-6 simultaneous users can be supported across all of APEX, Oracle REST Data Services, and SQL Developer Web<\/p>\n<\/blockquote>\n\n\n\n J’ai donc fait le choix d’un sous-syst\u00e8me compl\u00e9tement s\u00e9par\u00e9, responsable uniquement des interactions avec les clients. Google Forms \u00e9tait un choix disons … spontan\u00e9, puisqu’il \u00e9tait question de formulaires.<\/p>\n\n\n\n Tous les formulaires ont \u00e9t\u00e9 con\u00e7us avec Google Forms. Autant le pr\u00e9ciser de suite, ce service souffre de beaucoup de limitations car il est impossible, par exemple, de proposer une liste de valeurs dynamique. Il n’est pas possible non plus d’afficher un champs en mode read-only<\/em>. Il a fallu donc s’accommoder de nombreuses limitations. C’\u00e9tait le prix \u00e0 payer pour avoir l’esprit tranquille quant aux consid\u00e9rations de s\u00e9curit\u00e9 et de mont\u00e9e en charge. Il existe bien s\u00fbr des plugins sp\u00e9cialis\u00e9s pour Google Forms mais ils sont payants ou bien apportent une publicit\u00e9 intempestive.<\/p>\n\n\n\n Le client n’ a jamais connaissance de l’existence de l’url de backoffice<\/em>. Cela \u00e9vite une publicit\u00e9 non d\u00e9sir\u00e9e du syst\u00e8me. Tout ce qu’il voit, c’est l’interface Google Forms qui, je le suppose, est suffisamment prot\u00e9g\u00e9e contre des attaques de type DOS (Denial of service<\/em>).<\/p>\n\n\n\n Un autre avantage indirecte est que toutes les donn\u00e9es saisies sont enregistr\u00e9es dans une base interne \u00e0 Google et peuvent \u00eatre \u00e9galement copi\u00e9es automatiquement dans un tableau (sheet). Cela constitue un backup des informations entrantes dans le cas ou le SAV viendrait \u00e0 \u00eatre indisponible.<\/p>\n\n\n\n Comme la compagnie op\u00e8re avec une marque blanche et des trois distributeurs, il fallait que le bandeau affiche une marques parmi les trois. Chaque formulaire est accompagn\u00e9 d’un script \u00e9crit en langage Google Apps Script<\/a>, qui effectue la collecte des champs remplis et qui effectue un appel de service REST synchrone aupr\u00e8s du SAV via ORDS <\/a>(cf exemple en annexe<\/a>). Ce m\u00eame script notifie le client par mail du r\u00e9sultat de l’appel. Comme il n’y a pas d’authentification, les formulaires de demande de statut, par exemple, utilisent un contexte qui doit \u00eatre transport\u00e9 par le formulaire. Ce contexte est une chaine de caract\u00e8re qui contient le code du ticket et une valeur de contr\u00f4le. <\/p>\n\n\n\n Il est compos\u00e9 du code du ticket sur cinq caract\u00e8res et d’un code de contr\u00f4le (hash code \u00e0 partir d’informations vari\u00e9es). Il fallait proposer une valeur simple \u00e0 retenir pour le client afin de faciliter sa communication avec le SAV, mais aussi d\u00e9courager toute tentation de tester d’autres valeurs de tickets. <\/p>\n\n\n\n Comme le champs ne peut pas \u00eatre en Read Only<\/em>, rien n’emp\u00eache l’utilisateur de modifier le contenu de ce champs. Le risque se limite au fait que le script qui se d\u00e9clenche apr\u00e8s la soumission du formulaire renverra un contexte que le service REST du SAV ne saura pas retrouver. <\/p>\n\n\n\n Les conversations et notifications s’appuient sur l’\u00e9change de mails. Il est envisageable d’avoir recours a des message SMS. J’ai test\u00e9 le service OVH mais cela n’a pas \u00e9t\u00e9 mis en production sur ce projet. <\/p>\n\n\n\n Les mails sont g\u00e9n\u00e9r\u00e9s automatiquement par les scripts attach\u00e9s aux formulaires Google \u00e0 l\u2019exception du cas o\u00f9 c\u2019est un technicien qui d\u00e9cide d\u2019envoyer une question. <\/p>\n\n\n\n L’analyste n’utilise donc que l’interface de backoffice pour effectuer son travail de tous les jours. Lorsqu’il doit demander des informations compl\u00e9mentaires pour instruire le traitement d’un ticket, il passe par une page standard de l’application SAV. La soumission de la page d\u00e9clenche alors l’appel \u00e0 un script PHP d’envoi de mail. (cf sch\u00e9ma d’architecture plus haut<\/a>).<\/p>\n\n\n\n Lors du d\u00e9but du projet, la version Oracle Free Tier<\/em> \u00e0 la diff\u00e9rence de sa version payante ne permettait pas l’envoi de mail , c’est \u00e0 dire qu’il n’y avait pas moyen d’invoquer une passerelle SMTP. En cons\u00e9quence, le contournement a consist\u00e9 \u00e0 se priver des fonctionnalit\u00e9s natives d’Oracle APEX et envoyer des mail via l’API REST de Google Gmail. Celle-ci implique une authentification avec signature des \u00e9changes mais je ne suis pas parvenu \u00e0 utiliser les algorithmes de chiffrement sous PL\/SQL pour d\u00e9clencher OAUTH2 et il n\u2019existe pas de package de connexion pour le PL\/SQL propos\u00e9 par Google. Les tentatives d’obtention d’un token valide ( Actuellement, (d\u00e9cembre 2022), ces limitation ont \u00e9t\u00e9 lev\u00e9es en partie <\/a>puisqu’on peut d\u00e9sormais envoyer des mails avec certains seuils d’usage, mais qui auraient \u00e9t\u00e9 acceptables dans le cadre du projet (cf annexes<\/a>).<\/p>\n\n\n\n Tous les mails contiennent dans leur objet, le contexte (Code Ticket et code de contr\u00f4le) et proposent dans leurs bas de page deux boutons permettant de demander, soit le statut du ticket soit sa fermeture, soit sa r\u00e9ouverture.<\/p>\n\n\n\n Donc, le client final n’a jamais l’initiative d’envoyer un mail au SAV. Il peut en revanche compl\u00e9ter son ticket avec des photos ou vid\u00e9os, par r\u00e9ponse au mail initial de notification d’ouverture d’un ticket.<\/p>\n\n\n\n <\/p>\n\n\n\n R\u00e9guli\u00e8rement, un script Google bas\u00e9 sur un timer <\/em>se d\u00e9clenche toutes les x minutes pour scruter les mails qui seraient munis de pi\u00e8ces attach\u00e9es. Si c’est le cas, les fichiers sont recopi\u00e9s dans un dossier de Google Drive<\/em> nomm\u00e9 avec le nom du ticket et un appel REST informe le syst\u00e8me qu’un pi\u00e8ce attach\u00e9e est disponible (url de Google Drive). Ce m\u00e9canisme ne peut pas \u00eatre synchrone (cette limitation est document\u00e9e par Google) et c’est la raison pour laquelle il faut effectuer du poling<\/em>.<\/p>\n\n\n\n Alternative: Il aurait \u00e9t\u00e9 possible d’utiliser un service d’int\u00e9gration tel que Zapier<\/a> ou Make<\/a> (Integromat), mais cela aurait induit des couts d’usage.<\/p>\n\n\n\n Lorsque le technicien souhaite obtenir un compl\u00e9ment d’information, il utilise l’application de backoffice pour r\u00e9diger la question et c’est le module de SAV qui effectue l’envoi de mail. Dans le corps du mail, il y a un texte g\u00e9n\u00e9rique et un bouton qui redirige vers le formulaire de r\u00e9ponse \u00e0 une question du SAV.<\/p>\n\n\n\n L’appui sur le bouton \u00ab\u00a0Cliquer ici pour r\u00e9pondre<\/em>\u00a0\u00bb redirige vers un formulaire Google tel que celui-ci:<\/p>\n\n\n\n Lorsque le client veut accompagner sa demande d’ouverture de ticket par des photos ou vid\u00e9os, il doit les attacher en r\u00e9ponse au mail de confirmation qu’il aura re\u00e7u du SAV. <\/p>\n\n\n\n <\/p>\n\n\n\n Cet extrait de script Google illustre comment sont consomm\u00e9es les informations issues du formulaires, juste apr\u00e8s sa soumission. Un simple m\u00e9canisme de clef de s\u00e9curit\u00e9 (API_KEY) permet une reconnaissance par le service REST qui est appel\u00e9. <\/p>\n\n\n\n![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2022\/12\/archi-SAV-Generique-1-1024x519.png\")
<\/figure>\n\n\n\nSous-syst\u00e8mes<\/h2>\n\n\n\n
Sous-syst\u00e8me de backoffice<\/h3>\n\n\n\n
![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2022\/12\/image-6-1024x492.png\")
![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2022\/12\/image-10-1024x523.png\")
Fonctionnement sur mobiles<\/h4>\n\n\n\n
Les autres composants Oracle APEX s’adaptent automatiquement \u00e0 la g\u00e9om\u00e9trie du device<\/em>.
J’en ai profit\u00e9 pour mettre un peu de PWA <\/a>pour gagner un peu d’espace sur l’\u00e9cran du mobile et proposer une icone plus naturelle qu’un raccourci du Navigateur.<\/p>\n\n\n\nSous-syst\u00e8me de FrontOffice <\/h3>\n\n\n\n
Formulaires d’interaction<\/h4>\n\n\n\n
\n
Avantages d’utiliser des formulaires externes<\/h5>\n\n\n\n
Design des formulaires<\/h5>\n\n\n\n
Dans chaque formulaire, il a fallu transporter le contexte sous la forme d’un champs de type texte.<\/p>\n\n\n\n![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2022\/12\/image-2.png\")
Formulaires<\/h5>\n\n\n\n
\n
Il y a trois versions de formulaire et le script a \u00e9t\u00e9 mutualis\u00e9 dans une librairie.<\/p>\n\n\n\nContexte<\/h6>\n\n\n\n
Conversations et Notifications<\/h4>\n\n\n\n
https:\/\/oauth2.googleapis.com\/token<\/code>) ont \u00e9chou\u00e9 avec la fonction de chiffrage dbms_crypto.SIGN_SHA256_RSA<\/code>. et je me suis donc repli\u00e9 sur l’emploi d’une Gateway <\/em>qui effectue l’authentification et l’envoi via du code PHP<\/a>. Dans ce cas, Google fournit une librairie PHP pr\u00eate \u00e0 l’emploi, Google Client Library for PHP<\/em>. J’ai utilis\u00e9 une instance compute <\/em>disponible dans le tenant free Tier<\/em> pour h\u00e9berger cette passerelle et je l’ai munie d’un certificat SSL pour permettre la communication avec l’instance APEX.<\/p>\n\n\n\nTypes de mail<\/h5>\n\n\n\n
\n
![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2022\/12\/image-4-1024x662.png\")
Extraction des pi\u00e8ces attach\u00e9es<\/h5>\n\n\n\n
![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2022\/12\/image-8.png\")
![\"\"](\"https:\/\/gpmfactory.com\/wp-content\/uploads\/2022\/12\/image-9.png\")
Annexes<\/h2>\n\n\n\n
Exemple de script accompagnant un formulaire Google<\/h3>\n\n\n\n
On voit ici un appel \u00e0 un service REST de cr\u00e9ation de ticket dans SAV et l’envoi d’un mail de confirmation au client dans le cas o\u00f9 le statut de retour est ok.<\/p>\n\n\n\nfunction createTicket(e, canal) {\n\/\/ ------------------------------------------\n\/\/ Creates a new ticket in SAV subsystem\n\/\/ and sends a mail to the customer\n\/\/ Gpmfactory 2022\n\/\/ ------------------------------------------\n...\nvar url = '<SAV REST CREATE TICKET ENDPOINT>';\nvar formData = {\n 'EMAIL': email,\n 'NAME': t_name,\n 'CUSTOMER': t_customer,\n 'PHONE': t_phone,\n 'DESCRIPTION': t_description,\n ...\n 'API_KEY': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'\n};\n\nvar options = {\n 'method' : 'POST',\n 'payload' : formData,\n 'muteHttpExceptions': true\n};\n...\nvar response = UrlFetchApp.fetch(url, options);\nvar resp = response.getContentText();\nrc = response.getResponseCode();\nif (rc == \"200\" || rc == \"200.0\" ){\n MailApp.sendEmail(email, 'Ticket N\u00b0 ' + resp, body, {'htmlBody' : body }); \n Logger.log('Mail envoy\u00e9'); \n }\n...<\/code><\/pre>\n\n\n\nLimites d’Oracle Email Delivery Service pour Free Tier<\/h3>\n\n\n\n