L’API Nexar, expliquée : ce que c’est, comment elle fonctionne et ce qu’elle change pour les personnes qui l’utilisent

Tout d’abord, qu’est-ce qu’une API ?

API signifie « interface de programmation d’application ». Une personne utilise un site web en cliquant et en lisant. Un programme ne peut pas cliquer, il lui faut donc une fenêtre de service pour poser une question précise et obtenir une réponse précise dans un format qu’il comprend. Cette fenêtre, c’est l’API. Octopart est un site web où nos utilisateurs peuvent rechercher un composant électronique et l’examiner sous tous les angles. Cette vue inclut notamment les fournisseurs qui ont le composant en stock, son coût, son état dans le cycle de vie, ses attributs techniques, etc. Vous pouvez même rechercher un composant pour voir quels autres composants lui ressemblent. L’API Nexar fournit ces mêmes informations directement dans les systèmes logiciels métier de votre entreprise.

Avantages de l’utilisation de l’API Nexar

• Intégration dans vos propres outils : Vous pouvez intégrer directement dans vos systèmes internes les données à jour de l’API Nexar, par exemple dans un système personnalisé de gestion des bons de commande ou un système de gestion du cycle de vie des produits.
• Plus que des données d’approvisionnement : En plus des informations d’approvisionnement, l’API Nexar récupère aussi les données de conception de vos espaces de travail Altium 365 ; une seule intégration peut donc réunir données d’approvisionnement et données de conception.
• Cohérence entre les équipes : Toute personne utilisant la même requête obtient les mêmes valeurs : le même prix, le même niveau de stock et les mêmes unités, au même instant. Les chiffres restent comparables d’une personne à l’autre, d’un rapport à l’autre et dans le temps.
• Automatisation à grande échelle : L’API Nexar vous permet d’interroger par programmation jusqu’à 100 pièces à la fois et d’exécuter jusqu’à 300 requêtes par minute (soit potentiellement l’analyse de 30 000 pièces en une seule minute !)

L’API Nexar

L’API Nexar se compose principalement de : 

• Données d’approvisionnement : il s’agit des informations sur les pièces d’Octopart. Le volet approvisionnement de l’API donne accès à plus de 95 millions de pièces, avec stock, prix, état du cycle de vie, délais, fiches techniques, attributs techniques, modèles CAO et suggestions de pièces similaires, à partir des données des distributeurs électroniques et mises à jour quotidiennement. 

• Données de conception : elles sont destinées aux clients Altium et couvrent le contenu de vos espaces de travail de conception, depuis les projets jusqu’aux détails des composants. Le modèle de données Nexar est ici une ressource publique utile : Nexar Voyager. Dans le modèle de données, chaque opération porte un préfixe indiquant ce qu’elle concerne : sup pour l’approvisionnement, des pour la conception et adm pour l’administration du compte.

Exemple 1 : vous décrivez la réponse que vous souhaitez

Nexar utilise GraphQL, un langage de requête pour les API. Avec d’autres infrastructures d’API, vous demandez un bloc fixe de données, vous le recevez en entier, puis vous écrivez du code pour écarter ce dont vous n’aviez pas besoin. Avec GraphQL, vous décrivez la forme de la réponse, et c’est cette forme qui revient. Voici la forme documentée d’une recherche par MPN (manufacturer part number, référence fabricant) :

query MpnSearch { 

  supSearchMpn { 

    results { part { id  name  mpn } } 

  } 

} 

À lire à voix haute : lance une recherche sur les références fabricant, indique-moi combien il y a eu de résultats, et pour chaque résultat donne-moi l’identifiant de la pièce, son nom et son MPN. Rien d’autre n’est renvoyé. Demandez-en plus, et vous obtenez plus. Lors d’une démonstration en direct d’Altium, la recherche d’un microcontrôleur RA0E2 de la famille Renesas RA a bien renvoyé la pièce ; l’ajout des spécifications techniques a confirmé qu’elle était signalée comme conforme RoHS (restriction des substances dangereuses) ; l’ajout de la fiche technique a renvoyé un lien vers le fichier, son nom et sa date de création, car Octopart évalue les fiches techniques disponibles et peut renvoyer la meilleure. Rien de tout cela n’est arrivé avant d’avoir été demandé.

Exemple 2 : plusieurs façons de rechercher

Comme Octopart, l’API Nexar offre une grande souplesse dans la manière de rechercher un composant. Si vous souhaitez effectuer une recherche large, vous pouvez rechercher un MPN partiel ou lancer une recherche par mots-clés. Si vous savez précisément ce que vous voulez, vous pouvez alors rechercher le MPN exact.

Pour la recherche large, l’opération à utiliser dans l’API est « supSearch ». Cette opération exécute une recherche par correspondance approximative.

query search { 

  supSearch (q: "Current sensor") { 

    hits 

    results { 

      part { 

        id 

        name 

        shortDescription 

      } 

    } 

  } 

} 

Dans l’exemple ci-dessus, la recherche de « current sensor » renverrait le nombre de résultats, les identifiants des pièces, leurs noms et une brève description du composant. 

L’opération « supMultiMatch » prend une liste pouvant contenir jusqu’à 100 pièces, identifiées par MPN ou par SKU (stock keeping unit, unité de gestion de stock), et les résout ensemble. Contrairement à « supSearch », lorsque vous utilisez « SupMultiMatch », toutes les correspondances partielles sont ignorées. Cet exemple interroge deux composants :

query MultiSearch { 

  supMultiMatch (queries: [ 

      {mpn: "SY55855VKG", limit: 1}, 

      {mpn: "BAV99-7-F"}, 

  ]) { hits  parts { id  name  mpn } } 

} 

Chaque entrée peut correspondre à une ligne d’une nomenclature (BOM, bill of materials), ce qui permet de chiffrer une nomenclature complète sans que personne n’ouvre un navigateur.

Exemple 3 : le volet conception et l’écriture des données

La conception fonctionne de la même façon. Les opérations préfixées par des, comme « desWorkspaces », accèdent à vos espaces de travail Altium 365. Comme les données sont structurées sous forme de graphe, vous suivez les relations à partir de votre point de départ : depuis un espace de travail vers les conceptions qu’il contient, puis depuis une conception vers ce qu’elle renferme, qu’il s’agisse des nets, des détails des composants, des informations MCAD (conception assistée par ordinateur mécanique) ou des informations de position. Vous choisissez jusqu’où aller et quelle quantité d’informations rapporter à chaque étape.

La lecture n’en est que la moitié. Une mutation écrit : ajout d’un commentaire, téléversement d’un projet. Lorsqu’une opération nécessite un fichier, vous devez d’abord le publier vers le service de fichiers Nexar, à l’adresse files.nexar.com/File/Upload, en transmettant un jeton disposant des portées design.domain, user.access et openid. En retour, vous obtenez un identifiant, valable 24 heures s’il n’est pas utilisé, auquel vous faites référence dans la requête elle-même. Considérez cet identifiant comme opaque, car son format peut changer.

Ce que cela change dans votre travail

La valeur ajoutée apparaît plus clairement lorsqu’on observe comment trois rôles consacrent déjà leur temps et à quel endroit l’API leur en restitue.

Le responsable achats ou l’acheteur

Chez un EMS (prestataire de services de fabrication électronique) ou un OEM (fabricant d’équipement d’origine), cette personne vérifie que chaque pièce d’une fabrication est en stock, trouve un distributeur capable de respecter la date de livraison, comprend le prix et passe la commande. Cela peut représenter quelques commandes par semaine ou 50 à 100 par jour. Le travail se fait généralement pièce par pièce à partir d’un tableur : saisir un MPN, vérifier la disponibilité, cliquer vers le distributeur, puis recommencer. Les distributeurs agréés sont vérifiés en premier, et la recherche ne s’élargit à des courtiers non agréés que si rien n’est en stock. Beaucoup d’acheteurs effectuent un second contrôle juste avant de commander, au cas où la situation aurait évolué pendant la nuit.

Chacune de ces étapes a un équivalent ci-dessus. Une seule requête API remplace une centaine de recherches séparées. Utiliser dans l’API le filtre réservé aux distributeurs agréés correspond à cette même logique « d’abord les préférés, puis élargir », mais sous forme de paramètre plutôt qu’au travers d’un second tour de recherche manuelle. La revérification avant commande devient une tâche planifiée qui n’alerte qu’en cas de changement. Ce qui est récupéré, ce n’est pas le jugement, qui reste du ressort de l’acheteur, mais le temps passé à saisir et à jongler entre les onglets, qui l’absorbe aujourd’hui. Les prix contractuels négociés à l’avance restent du côté du distributeur ; l’API sert donc à présélectionner et à détecter les changements, non à remplacer le bon de commande.

L’ingénieur concepteur

Chez un OEM, cette personne est responsable du cycle de vie de la conception électrique, depuis le diagramme fonctionnel jusqu’à la sélection des composants, la saisie du schéma, le routage et la publication de la BOM. Sa contrainte principale est simple : un composant qui ne peut pas être approvisionné est un problème de conception. Octopart est donc utilisé comme étape de validation, pour répondre à la question « peut-on réellement acheter cette pièce, et auprès de plus d’une source ? », mais aussi comme outil de découverte pour trouver et comparer des candidats. L’étendue de la couverture distributeur constitue en elle-même un signal, car une pièce stockée par un seul distributeur (ou par plusieurs distributeurs mais avec un stock global en diminution d’une semaine sur l’autre) représente un risque pour la chaîne d’approvisionnement avant même de devenir un problème d’achat.

Passé par l’API, ce contrôle cesse d’être un réflexe pièce par pièce et devient une étape bloquante. Chaque ligne d’une BOM peut être testée au moment de la publication, et toute pièce n’ayant qu’un seul distributeur, un stock limité ou un indicateur de cycle de vie peut être signalée avant validation de la conception plutôt que plusieurs mois plus tard. La crainte visée ici est spécifique et coûteuse : qu’une pièce passe en EOL (end of life, fin de vie) après avoir été intégrée à la conception, imposant une reprise de conception. Les fiches techniques peuvent aussi être intégrées à vos propres outils au même moment, même si les ingénieurs continueront, à juste titre, de vérifier les spécifications dans la fiche technique elle-même.

L’ingénieur composants

Présent dans les OEM de taille moyenne à grande, en particulier dans l’aéronautique, la défense, l’automobile et le médical, cette personne ne crée généralement pas de nouvelles conceptions. Elle gère les pièces déjà en production : maintien à jour de la bibliothèque de pièces approuvées, détection de l’obsolescence avant qu’elle ne devienne critique et qualification d’alternatives lorsqu’une pièce est abandonnée. Les pièces à risque figurent sur une liste de surveillance contrôlée périodiquement, notamment parce qu’une pièce abandonnée peut parfois revenir sur le marché.

Une liste de surveillance auto-vérifiée est l’avantage le plus évident de cet article. Au lieu que quelqu’un doive penser à revenir consulter une liste, une requête planifiée la parcourt et signale les exceptions. Comme une seule application peut regrouper à la fois les périmètres d’approvisionnement et de conception, la bibliothèque peut être lue côté conception et comparée aux données de marché en direct côté approvisionnement dans une même exécution, transformant un audit manuel périodique en rapport permanent. Octopart continue d’ouvrir l’entonnoir plutôt que de le refermer : les alternatives candidates et la disponibilité sur le marché proviennent d’ici, tandis que la vérification de la forme, de l’encombrement, de la fonction, de la conformité et du cycle de vie continue de se faire dans les outils de PLM (gestion du cycle de vie des produits) et chez les fournisseurs de données spécialisés.

Ce que les trois ont en commun

Aucun de ces profils ne demande à visiter un nouveau site web. Ils demandent que la réponse arrive dans le système dans lequel ils travaillent déjà ; au moment où elle compte, sans que quelqu’un ait à aller la chercher. C’est précisément à cela que sert une API, et cela correspond assez bien à la façon dont Nexar décrit sa propre raison d’être : démocratiser l’information et rapprocher les personnes afin qu’elles puissent travailler plus efficacement et prendre de meilleures décisions commerciales.

Mise en route

1. Inscrivez-vous sur portal.nexar.com avec une adresse e-mail et un mot de passe, ou avec des identifiants Google, Facebook ou Altium 365. Les organisations qui utilisent déjà le SSO (authentification unique) avec Altium 365 peuvent se connecter de cette manière.
2. Créez une organisation ou rejoignez-en une. Cette étape est obligatoire. Pour rejoindre une organisation existante, demandez à l’un de ses membres de vous inviter.
3. Dès votre inscription, une application « Evaluation » préconfigurée sera disponible pour vous. Vous pouvez accéder à Apps et créer des applications supplémentaires si vous le souhaitez.
4. Un environnement sandbox est disponible dans le tableau de bord de l’API pour vous permettre d’explorer immédiatement. Lorsque vous serez prêt à intégrer les données dans votre outil ou votre application, vous pourrez accéder à l’onglet Authorization et récupérer les identifiants d’authentification.
5. Récupérez l’ID client et le secret client dans l’onglet Authorization de l’application. Ce sont des identifiants statiques. Traitez le secret comme un mot de passe.
6. Échangez-les contre un jeton d’accès. Nexar utilise OAuth 2.0 (Open Authorization, version 2.0), et les jetons restent valides pendant 24 heures. Les requêtes d’approvisionnement utilisent le flux client credentials ; les requêtes design et adm utilisent le flux authorization code avec les portées OpenID, design.domain et user.access.

Vous pouvez exécuter tous les exemples ci-dessus dans un éditeur GraphQL tel que Nitro (anciennement Banana Cake Pop) ou Postman avant d’écrire la moindre ligne de code d’application. Les points de terminaison sont api.nexar.com/graphql pour l’API, identity.nexar.com/connect/token pour les jetons, et files.nexar.com/File/Upload pour les téléversements. 

Où aller ensuite

Voyez l’API en action. Rob Barton, Head of Platform API chez Altium, retrace l’évolution de l’API d’Altium et exécute des requêtes en direct sur les données d’approvisionnement Octopart dans le podcast OnTrack : Altium API Deep Dive: Opening PCB Data to Developers sur YouTube.

Écoutez l’épisode. OnTrack: The PCB Design Podcast, animé par Zach Peterson.

Explorez le modèle de données. Nexar Voyager fournit une représentation visuelle du schéma GraphQL.

Consultez la documentation. La documentation complète et un glossaire des termes sont disponibles sur support.nexar.com. Des exemples de code détaillés sont publiés sur le GitHub NexarDeveloper.