Dans cet article, nous allons voir comment récupérer par l’intermédiaire d’un webservice paramétré dans IWS, des fichiers binaires et les stocker dans l’IFS.
Prenons par exemple, sur un site web, un formulaire avec des champs « texte », d’identification, et 2 champs de sélection de fichiers pour les pièces jointes à transmettre.
Côté client :
Vous aurez :
- Votre page html classique
- Le CSS qui va bien
- Du javascript pour :
- Faire les contrôles de surface : limite sur les extensions autorisées, limite de poids d’une pièce jointe,….
- Encoder les fichiers en base 64, on en reparle après…
- Construire le json qui formera le corps de la requête
- Appeler le service REST méthode POST
Je ne m’étendrais pas sur le html et le CSS, ce n’est pas l’objet de cet article.
Côté serveur :
- Un serveur de webservice – IWS, CGI, autre…
- Un service Méthode POST
- Un programme qui va :
- Parser le json pour récupérer les différents éléments
- Décoder les fichiers pour revenir à la donnée originale
- Ecrire les pièces jointes dans l’IFS
Pourquoi encoder les pièces jointes en base64 ?
Les fichiers stockent des informations par octet sous forme binaire.
Pour un fichier texte, il y a des tables de transcodage pour transformer un octet en lettre, chiffre, caractères spéciaux, …., en quelque chose de visuel qu’un humain comprend. C’est le rôle du CCSID sur IBM i.
Pour les fichiers binaires, un octet ne contient pas forcément un caractère au sens large, mais ça peut être un bout d’image, de son, de code…. qui n’ont pas vocation à être affichés comme du texte.
Or lors de l’appel au webservice, les fichiers seront encapsuler dans un flux json, qui est un champs textuel. Ce flux subira un transcodage entre l’UTF-8 de la requête HTTP et le CCSID de votre IBM i. Si vous enregistrez le résultat obtenu, votre fichier sera corrompu. Ca revient à ouvrir un pdf, une image, …, avec notepad !
Pour éviter, cette incidence là, on encode en base 64, ce qui nous donnera une donnée qui ne subira aucune modification lors du passage UTF-8 vers CCSID, et une fois dans le job IBM i, par le décodage, nous revenons à la donnée initiale.
L’inconvénient est le temps d’encodage/décodage ainsi que le volume de la donnée transmise qui augmentera.
Revenons à notre sujet.
Dans votre html, il faut donc un peu de javascript :
- Récupération des informations saisies dans le formulaire
- Fonction d’encodage en base 64 :
- Construction du flux json, dans notre exemple, les deux pièces jointes sont envoyées en tant qu’éléments indépendant, on aurait très pu choisir de construire un tableau des pièces jointes avec un post par fichier sélectionné.
- Appel au webservice. Dans notre exemple, aucune authentification, mais il faudra bien entendu pour une implémentation de production s’aligner sur vos standards de sécurité : Authentification, appel reçu par un gateway avant routage vers l’IBM i, …
On retrouve l’URI d’invocation du service (https…), la méthode POST (method), avec le formulaire qui passe dans le corps de la requête (body) en tant que flux json (content-type dans le header). De l’API REST standard.
Prenons un exemple de saisie de formulaire avec deux pièces jointes transmises :
Le flux json généré sera :
Et si un seul fichier est transmis :
Le flux json correspondant, contiendra l’état null au niveau du fichier sans sélection :
Voilà pour le côté client, côté serveur, il faudra un serveur, pour ma part j’ai utilisé un serveur IWS, dans lequel sera déployé un service avec la méthode post. Ce service attend un seul paramètre, le flux json, dans le corps de la requête.
Côté programme, le code est succinct :
Un premier parsing, pour récupérer les informations du formulaire : nom, prénom, nom du fichier 1 et nom du fichier 2 sans le contenu des fichiers, avec gestion de l’état null sur les fichiers.
Puis si j’ai un nom de fichier renseigné, l’écriture du fichier dans l’IFS, qui contient le parsing pour obtenir le contenu base64 du fichier binaire, le décodage de la base 64.
Et c’est tout !
Mes fichiers binaires se retrouvent dans l’IFS, et si le répertoire est partagé, directement accessible par les gestionnaires qui auront besoin d’accéder à ces fichiers.
Cliquer ici pour ajouter votre propre texte
