Accueil Blog Accéder aux données dans les requêtes génériques en utilisant des API basées sur les contrats

Accès aux données dans les requêtes génériques à l'aide d'API basées sur les contrats

Diane Cawley | 14 août 2021

Les dames accèdent aux données sur l'ordinateur portable pour des questions génériques

Introduction

Les API Acumatica basées sur les contrats sont très puissantes pour sélectionner les données des différentes entités commerciales au sein de la plateforme Acumatica XRP. Acumatica fournit d'emblée une définition des points de terminaison des services Web pour la plupart des entités utilisées dans le système. Cependant, il arrive que l'on ait besoin de données qui ne sont pas formatées comme une entité définie existante. Pour répondre à ce besoin, vous pouvez créer des requêtes génériques (IG) pour rassembler des données provenant de plusieurs tables et formatées d'une manière utile. Si ces données sont nécessaires à l'intégration, il est possible d'étendre le point de terminaison des services Web afin d'ajouter une définition pour ces requêtes génériques (GI). Cet article de blog explique comment atteindre cet objectif pour les modèles d'API basés sur SOAP et REST.

Je vais expliquer cela en créant un cas d'utilisation et les étapes de la solution pour répondre aux besoins de ce cas d'utilisation.

Cas d'utilisation

Dans mon application externe, je dois obtenir les quantités de stock actuelles pour tous les articles de l'entrepôt WHOLESALE.

Solution utilisant le point de terminaison des services Web par défaut : Utiliser l'entité Inventory Summary. Parcourez en boucle chaque numéro d'article en stock et appelez l'API de l'entité InventorySummary une fois pour chaque article. Cette méthode est extrêmement lente et consomme beaucoup de ressources car elle nécessite de nombreux appels à l'API et donc à la base de données.

Meilleure solution : Créer une demande générique pour afficher les données nécessaires pour tous les éléments dans un formulaire de liste. Utiliser ensuite l'API pour sélectionner des enregistrements à partir de cette IG. Cette solution est plus performante car elle permet d'obtenir des centaines (ou des milliers) de lignes en un seul appel.

Étape 1 - Créer l'enquête générique
Dans cet exemple, j'ai créé une IG appelée InventoryByLocation. Elle indiquera la quantité en stock pour chaque article par WarehouseID et LocationID. Les deux captures d'écran suivantes montrent la définition de l'IG et les résultats de l'enquête.

Tableau de bord des demandes génériques - Inventaire par lieu

 

Inventaire par lieu - Filtre de configuration

 

Étape 2 - Étendre le point de terminaison du service Web par défaut pour ajouter les champs IG
C'est ici que vous devez faire attention. La configuration correcte du point de terminaison facilitera grandement le processus d'appel à l'aide de l'API.

Tout d'abord, vous devez étendre le point de terminaison par défaut. Allez dans le menu Intégration, section Préférences, et choisissez le menu Points de terminaison du service Web. Sélectionnez le point de terminaison par défaut pour la dernière version. En 2019 R1, la dernière version est 18.200.001.

 

Intégration : Tous les éléments - transactions, profils, processus, préférences.

 

Segment des points de terminaison des services Web

 

Ensuite, cliquez sur EXTEND ENDPOINT dans les actions en haut de l'écran. Il vous sera demandé de renommer votre point de terminaison étendu et de lui donner une version. Pour cet exemple, j'utilise MyExtEndpoint et la version 18.200.001 (identique à la version du point de terminaison par défaut).

 

Prolonger le point d'arrivée actuel - humeur par défaut

 

Lorsque l'écran s'affiche, cliquez sur INSERT. Cela vous permettra de créer une nouvelle définition d'entité pour l'IG qui a été créée. Vous devrez alors spécifier l'ID de l'écran - qui faisait partie de la création de l'IG lors de la première étape.

 

Propriétés du point final - Création d'une entité

 

Ensuite, vous devez ajouter les champs au point de terminaison, ce qui signifie que vous devez remplir toutes les colonnes affichées sur l'IG. De cette manière, elles seront disponibles pour être utilisées dans l'API.

Faites attention à cette étape. Vous aurez tout d'abord tendance à remplir tous les champs comme indiqué dans l'image ci-dessous. Cela créera les champs au niveau supérieur de l'entité InventoryByLocation.

 

Web Service Endpoints - Remplir les champs

 

Si vous configurez le point de terminaison de cette manière, vous ne pourrez pas sélectionner de données dans l'IG sous-jacente.

Au lieu de cela, il faut d'abord créer un niveau "Résultats" sous le niveau supérieur de l'entité, puis remplir ce niveau avec les champs. En effet, ce sont les résultats qui sont renseignés dans l'IG lorsqu'elle est exécutée.

Insérer au niveau de l'entité InventoryByLocation, puis créer une autre entité en dessous appelée Result. Le nom de l'objet doit être unique. Dans ce cas, j'ai choisi InvByLocation.

 

Section Création d'entités aux points de terminaison des services web

 

Enfin, une fois ce résultat créé, il peut être renseigné avec les champs de l'IG. Cet exemple est illustré ci-dessous.

Les résultats dans les champs à remplir

Étape 3 - Accédez au point final et à l'entité dans votre code d'intégration.

Utiliser SOAP

Maintenant, dans le code, il est facile de sélectionner les données de l'IG.

Vous trouverez ci-dessous un court exemple d'utilisation de l'API SOAP et de sélection de toutes les lignes du résultat de l'IG. Notez que l'appel standard Get est celui qui fonctionne avec la méthodologie SOAP. Remarquez que vous demandez le résultat, qui est le niveau de détail défini dans le point de terminaison.

 

  InventoryByLocation ToBeFound = new InventoryByLocation
   {
     Result = new InvByLocation[]
    {
       new InvByLocation { ReturnBehavior = ReturnBehavior.All }
    }
   };

   InventoryByLocation invByLoc = (InventoryByLocation)soapClient.Get(ToBeFound);

   foreach (InvByLocation InvRow in InvByLoc.Result)
   {
       ...process the results here…
   }

 

Utiliser REST

Examinons maintenant l'option basée sur REST. Il y a une petite différence avec cette option. J'utiliserai Postman pour montrer comment effectuer les appels.

Tout d'abord, si vous essayez d'envoyer une requête GET, cela ne fonctionnera pas. Dans l'exemple ci-dessous, vous obtiendrez une erreur BQL Delegate.

 

Option basée sur REST, l'exemple d'une erreur de délégué BQL.

 

Au lieu de cela, vous devez utiliser une requête PUT. Pour ce faire, vous devez spécifier le point de terminaison, suivi du nom de l'IG(InventoryByLocation). Comme l'IG n'a que des détails - comme expliqué dans la section SOAP ci-dessus - vous devrez également ajouter un paramètre de requête "$expand=Result".

La requête PUT nécessite la présence d'un élément dans le "corps" de la requête. Celui-ci doit être vide - vous le spécifierez donc avec { } comme indiqué dans l'exemple ci-dessous.

Lorsque vous exécutez la commande "SEND" de cette requête PUT, vous obtenez des résultats JSON contenant tous les détails de l'IG.

 

InventoryByLocation, en ajoutant un paramètre de requête "$expand=Result.

 

Pour plus d'informations sur la création d'IG et l'utilisation des API SOAP et REST, veuillez vous référer à la documentation d'aide Acumatica pour les demandes génériques et à la documentation d'aide Acumatica Contract-Based API Reference.

Résumé

Lorsqu'il s'agit de synchroniser les données entre Acumatica et des systèmes logiciels externes, il existe souvent plusieurs façons d'accomplir cette tâche. Mais en tant que développeurs, nous souhaitons que nos solutions soient efficaces, évolutives/performantes et faciles à maintenir. La fonctionnalité Generic Inquiryd'Acumatica nous permet de construire des requêtes de base de données spécifiques qui peuvent nous aider à atteindre ces objectifs de performance. Le modèle d'API contractuelle permet d'étendre les points de terminaison des services Web afin que nous puissions utiliser ces requêtes génériques pour créer un nombre illimité d'entités auxquelles il est possible d'accéder en utilisant les dernières techniques et modèles logiciels. Acumatica fournit les outils et tout ce que nous avons à faire est de construire les solutions.

Auteur du blog

Diane Cawley est cofondatrice et architecte en chef de Savant Software, qui fournit des solutions pour la chaîne d'approvisionnement depuis 1995. Elle est titulaire d'une licence en informatique et d'un MBA de l'Arizona State University. Elle dirige les équipes de développement et de mise en œuvre et est responsable de l'évolution continue du produit ainsi que de son intégration avec des systèmes ERP tels qu'Acumatica. Diane est MVP Acumatica depuis 2018. Elle a participé à tous les Hackathon annuels à ce jour. Elle travaille avec le cadre Acumatica en se concentrant sur les API depuis la version 5.1 et a développé plusieurs intégrations complexes entre le WMS de Savant et Acumatica. En dehors du travail, Diane et son mari aiment voyager à travers le monde et apprendre de nouvelles choses en participant à diverses rencontres - en particulier celles liées à l'IoT et à la robotique.

Recevez les mises à jour du blog dans votre boîte de réception.