Import de données : le guide de base pour Business Analyst

Dans la plupart des projets que vous rencontrerez en tant que Business Analyst IT, vous devrez vous connecter à une ou plusieurs plateformes existantes. Il faudra par exemple mettre en place une interface pour obtenir ou envoyer des données.

Dans mon domaine, l’e-commerce, c’est une étape essentielle pour chaque projet. En effet, chez les grandes entreprises, la principale source de données la plus complète n’est pas la plateforme e-commerce, mais l’ERP.   Quand je parle de « données » dans ce contexte, il s’agit principalement des produits, des tarifs, des remises et/ou des clients ou utilisateurs.  Il existe deux types d’interfaces d’import de données : les interfaces synchrones et les interfaces asynchrones. Ici, vous devrez vous poser les questions suivantes : 

  • À quelle fréquence les données changent-elles ? 
  • Quelle sera la tolérance du client vis-à-vis des données inexactes ?

Import de données avec des interfaces synchrones 

Avec une interface synchrone, il faut faire une requête à chaque fois que vous avez besoin de données. La source et la cible sont toujours alignées et synchronisées.  En d’autres termes, vous n’avez pas besoin de stocker les données dans la base de données. Cependant, il est possible de mettre en cache les données reçues pour ne pas nuire aux performances et aux délais d’exécution des requêtes. L’utilisation et la fréquence de la mise en cache dépendent de la tolérance de l’entreprise. Vous devrez donc poser des questions telles que :   Quel délai d’actualisation de données pourriez-vous tolérer ? (Donnez des exemples : 0 seconde, 10 minutes, 1 heure, etc.) 

Comment ? 

Pour les interfaces synchrones, on utilise les services Web. La requête est envoyée d’une extrémité (destinataire) à l’autre (expéditeur), et attend sa réponse. Ici, il est important de prendre en charge les différents scénarios. En tant que Business Analyst, vous devrez discuter des sujets suivants avec votre client ou son représentant : 

  • Identification des différents champs obligatoires et le comportement à adopter en cas de champs manquants ; 
  • Identification des différentes erreurs : réponses 4xx et 5xx et timeouts ; 
  • Identification des scénarios extrêmes et des comportements à adopter : réponses vides et situations particulières (aucun résultat, par exemple). 

Fichiers 

Ici, les données sont généralement reçues sous forme de fichiers JSON, ou JavaScript Object Notation. Ce format représente les données reçues avec des structures et des objets de données. À cette étape, vous devez demander les éléments suivants : 

  • Le swagger, un fichier JSON qui définit le contrat entre l’expéditeur et le destinataire. Il décrit la structure de données qui sera appliquée aux données reçues, ainsi que la nature/le type de données reçues. Il devrait également décrire les différentes réponses qui seront reçues en cas de réussite ou d’erreur. 
  • Si possible, il serait utile d’inclure un exemple de réponse. Cela vous permettra de consulter un exemple des données que vous recevrez et d’avoir une base pour un éventuel stub, ce qui est toujours recommandé si jamais l’expéditeur n’est pas encore prêt à déployer une réponse.

Import de données avec des interfaces asynchrones 

Dans les interfaces asynchrones, les données de la source et de la cible ne sont pas toujours alignées/synchronisées en permanence. Dans cette situation, vous devez vous assurer que votre client peut tolérer ce décalage.  Si l’interface asynchrone répond aux besoins métier, vous devez poser la question suivante :  Quel est le meilleur moment pour exécuter l’interface ?  Ici, vous devrez guider la discussion afin d’identifier le pic de trafic et éviter cette période, pour ne pas affecter l’expérience client. Il est également important de connaître la quantité approximative/moyenne de données (lignes de base de données) à transmettre, pour estimer le temps de traitement requis. 

Comment ? 

Les interfaces asynchrones peuvent être déployées de deux manières : 

  • Tâche périodique vous pouvez programmer une tâche périodique (par exemple journalière). Cette tâche peut être lancée à l’aide d’un déclencheur, ou manuellement. Ici, un fichier d’importation doit être placé dans un dossier défini pour que la tâche puisse l’utiliser. 
  • Hot Folder : pour consommer les fichiers d’importation, vous pouvez également utiliser une autre option : les Hot Folders. Ici, il suffit de déplacer le fichier d’importation dans un dossier (Hot Folder) pour déclencher le traitement. Une fois le fichier ajouté au dossier, il est instantanément consommé par une tâche. 

Fichiers 

Pour préparer ce type d’interface, vous aurez besoin de deux fichiers : 

  • Un exemple du fichier d’importation vous serait très utile pour comprendre la structure des données reçues. De plus, il vous donnera un bon exemple des données que vous recevrez. 
  • Le fichier XSD est un élément essentiel à demander, car il définit l’accord et le contrat entre l’expéditeur et le destinataire. Il contient également tous les paramètres qui seront envoyés, y compris leur nom et leur type. Il spécifie aussi les paramètres obligatoires. 

Ici, il est important de vous mettre d’accord avec votre client concernant les comportements à adopter en cas de paramètre obligatoire manquant. Chaque champ obligatoire doit être traité séparément, car la pondération peut varier d’un champ à l’autre.  (!) En plus de définir le comportement à adopter en cas de paramètre manquant avec votre client, il est également important de déterminer le comportement à mettre en place lorsqu’une balise est manquante. La balise est le nom du paramètre qui se trouve dans le fichier d’importation et qui identifie le moment où la valeur du paramètre va être spécifiée.

Conclusion 

J’espère que cette introduction à l’import de données vous sera utile, en tant qu’analyste business. Ce guide a pour but de faciliter votre travail, notamment grâce aux exemples de questions à poser à votre client.