Dans le cadre de notre contrat avec la société La Poste, nous avons été mandatés afin d’effectuer la Tierce maintenance applicative (TMA) pour une filiale spécialisée dans l’envoi des objets perdus et dans la récupération des objets interdits en cabine.

Nous avons donc pris en charge une application basée sur le Framework Php CakePhp dans ce cadre là.

Or notre client nous contacte pour nous informer que certaines étiquettes Colissimo, générée par l’API Colissimo, sont erronées et ce de manière aléatoire. Les étiquettes présentes des données relatives à des colis qui datent de 2 ans.

Début de l’investigation, nous observons dans nos fichiers de log que nous transmettons bien les bonnes informations à l’API Colisismo.

Malgré tout, des étiquettes sont éditées avec des données anciennes. Pourtant au retour de l’API Colissimo, l’outil enregistre l’étiquette avant de la présenter pour impression. Or à l’ouverture de ce fichier PDF, celui-ci indique bien la bonne adresse.

Pourtant, des étiquettes continuent d’être imprimées avec de informations anciennes.

Soudain, notre client nous indique qu’il arrive à lire le fichier avec les bonnes données alors que le poste informatique qui a généré l’étiquette Colissimo affiche une étiquette PDF avec les anciennes données.

Chouette une piste.

A savoir que Colissimo recycle les numéros de colis tous les 18 mois environ.

Toute plage colis allouée à un code produit donné :

  • a une durée de vie d’environ 1 an et demi,
  • est automatiquement réinitialisée après le dernier numéro de colis.


cf. II.2.3Réinitialisation automatique des plages colis

Nous téléchargeons le fichier avec un logiciel de transfert FTP/SCP Filezilla en version binaire. Le fichier que nous téléchargeons affiche les bonnes informations.

Nous supprimons les caches, pourtant le poste affiche toujours les anciennes données. Nous supposons un cache sur le réseau informatique du poste. Mais cela reste difficilement vérifiable et pour les grandes structures comme les grands comptes que nous servons, trouver les bons services cela peut prendre du temps.

Or le temps nous manque car la génération des étiquettes est suspendue de peur d’envoyer des colis à des mauvais destinataires.

Donc dans les cas ou nous ne pouvons pas reproduire le problème, le plus simple est d’essayer de se caler à l’environnement du client pour être au plus proche de ses caractéristiques et donc reproduire le problème.

Le poste étant équipé d’un environnement Windows, direction Microsoft pour récupérer une version de Windows gratuite afin de tester sur cet environnement. En effet, Microsoft propose aux développeurs des environnements Windows téléchargeables gratuitement sous forme de machines virtuelles.

Une fois récupérée et importée dans notre outil de Machine Virtuelle Oracle Virtual Box, direction Internet Explorer. Oui je sais, certains services utilisent encore Internet Explorer.

Et la contre attente, nous arrivons à télécharger le fichier PDF avec les anciennes données. Nous pouvons donc écarter le cache car cette machine virtuelle est lancée pour la première fois et se trouve sur un réseau que l’on gère et qui ne contient pas de serveur Proxy jouant le rôle de cache. Cette machine ne peut donc absolument pas connaître les anciennes données.

Nous testons de télécharger le fichier via Internet Explorer mais de l’ouvrir en dehors d’Internet Explorer. C’est donc le lecteur PDF de Windows qui s’ouvre et qui présente les anciennes données.

Cela épaissis le mystère puisque le fichier téléchargé par Internet Explorer affiche les données erronées et celui téléchargé sur la machine hôte via un outil de transfert de fichier affiche des données correctes. La logique veux que ces fichiers doivent présenter la même chose.

Afin de diminuer le mystère, nous prenons la décision d’installer un nouveau navigateur sur cette machine virtuelle. Notre choix se porte sur Chrome. Une fois l’installation de Chrome effectuée dans la machine virtuelle, nous téléchargeons le fichier. Là le fichier est correct.

Il s’agit donc d’un problème à l’intérieur de la machine virtuelle entre Internet Explorer et Chrome.

Une intuition nous pousse à afficher le fichier PDF incorrect téléchargé sous Internet Explorer sous Chrome. Et là, le ciel s’éclaire.

Le même fichier physique affiché sous Chrome est correct alors que sous Internet Explorer ou le lecteur PDF de Windows affiche l’ancienne version.

Nous éditions le fichier PDF avec l’éditeur de texte notepad disponible sous Windows.

Nous constatons que le fichier PDF commence par les caractères « %PDF-1.3 ». Or une recherche de cette de chaîne de caractères nous amène à trouver une deuxième instance en plein milieux du document juste après une balise EOF.

Le fichier PDF physique contient donc 2 documents PDF complets, mais juste concaténé et donc mal construit au sens du format PDF.

Cela se vérifie en regardant la taille des derniers fichiers générés, ils font le double en taille d’une étiquette classique qui fonctionne correctement.

Les outils Microsoft (Internet Explorer et Lecteur PDF) se comportent différemment des autres outils. Et dans ce cas là, les outils Microsoft se chargent de lire le premier document, alors que les autres outils vont afficher le deuxième document.

En regardant le fichier php du projet CakePhp, effectivement le développeur de cette solution avait indiqué


fopen($label_file, 'a');

Or le paramètre ‘a’ de la commande fopen permet d’ajouter des données à un fichier et créer un fichier si celui-ci n’existe pas.

Afin de régler la génération incorrecte des fichiers nous avons donc changé le paramètre pour le passer en ‘w’ afin d’écraser le fichier à chaque demande d’écriture.
De ce fait, le fichier le plus vieux est écrasé par sa version plus récente. Il ne peut donc plus avoir 2 documents PDF dans un même fichier physique.

Pour corriger ces fichiers PDF mal formés, nous les avons d’abord identifié

ls -S -l | more

Cela nous a permis de détecter tous les fichiers ayant une taille double de celle normalement constaté. Généralement plus de 150 Ko pour une étiquette à imprimer sur une imprimante A4.

Suite à cela nous avons créer un script qui permet de « dissocier » proprement les fichiers PDF en utilisant l’outil bbe :

#!/usr/bin/env bash

###################
# Set default env var
# @author http://kvz.io/blog/2013/11/21/bash-best-practices/
###################
__dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" 
__file="${__dir}/$(basename "${BASH_SOURCE[0]}")" 
__base="$(basename ${__file})" 

cd "${__dir}" 

result_dir="results" 

mkdir -p "${result_dir}" 

for fullfile in *.pdf
do
    filename=$(basename -- "$fullfile")
    extension="${filename##*.}" 
    filename="${filename%.*}" 

    oldfilename="${filename}-old.${extension}" 

    echo "Processing ${fullfile}" 
    bbe -b '/%PDF/:' -e 'D 2' -o "${result_dir}/${oldfilename}" "${fullfile}" 
    bbe -b '/%PDF/:' -e 'D 1' -o "${result_dir}/${fullfile}" "${fullfile}" 
done

!! Attention de toujours faire une sauvegarde de vos fichiers avant de les manipuler. !!

Si vous ne comprenez pas ce que vous faites, ne pas modifier votre fichier et demander à votre agence ou une agence de développement spécialisée dans Prestashop d’apporter ces modifications sur votre site Internet.

Ce « petit » article illustre la difficulté des sociétés spécialisées dans le développement de site Internet et d’applications mobiles à proposer des offres de maintenance auprès de clients.

En effet, la correction est rapide, nous avons changé un caractère ,le ‘a’ est devenu ‘w’, son déploiement aussi avec un bon workflow de livraison. Par contre, pour justifier que ce changement de caractère à pris une journée et donc un coût non négligeable, cela est moins aisé.

Heureusement, nos clients nous connaissent et savent qu’en cas de blocage, nous faisons tout notre possible pour résoudre leurs problèmes même en dehors de leur journée de commande ouverte qui leur est dédiée.

Cela vient souligner une fois de plus, qu’une véritable relation qui va dans les deux sens, c’est la clé pour la réussite d’un projet informatique.