AcumatiCaresDans le post d’aujourd’hui, je vais vous présenter les API ERP cloud d’Acumatica qui permettent l’intégration avec des systèmes et des applications externes. Grâce aux services Web, les applications externes peuvent obtenir des enregistrements de données d’Acumatica, traiter ces enregistrements, enregistrer, créer des enregistrements nouveaux ou mis à jour. Aujourd’hui, nous mettons à la disposition du développeur et de l’intégrateur système l’accès aux API basées sur un écran et sur des contrats qui sont basées sur des interfaces SOAP. Dans un proche avenir, nous déploierons nos API contractuelles basées sur REST, où les développeurs pourront utiliser des interfaces REST. J’entrerai dans une certaine profondeur dans un prochain article de blog, fournissant plus de détails sur notre mise en œuvre de REST. La figure 1 ci-dessous représente graphiquement ces interfaces API entre notre base de produits ERP de base et des applications tierces.
API de services Web basée sur un écran
Nos API à écran sont conçues pour fonctionner avec tous nos formulaires ERP Acumatica en utilisant directement les champs et les actions disponibles sur ces formulaires. Par exemple, dans le formulaire ci-dessous, chaque élément – une zone de texte, une zone de liste déroulante ou une colonne de tableau est associé à une classe d’API de services Web particulière et est disponible via une propriété correspondante de cette classe. La propriété a un nom similaire à celui de la zone correspondante sur le formulaire.
Après vous être connecté à Acumatica à l’aide de l’API, vous pouvez accéder aux données sur les formulaires disponibles via un simple service Web. Nous fournissons une classe d’écran des méthodes API pour travailler avec tous les formulaires ERP Acumatica disponibles via le service. Vous pouvez savoir à quelle forme une méthode accède par le préfixe dans le nom de la méthode, qui est l’ID de formulaire. Par exemple, la méthode Export() que vous utilisez pour exporter des données à partir des articles stock à partir du formulaire d’inventaire IN202500 est IN202500Export().
Exemple de code à l’écran : Récupération d’une liste d’articles en stock
Jetons un coup d’œil à un exemple de code où nous récupérons une liste d’articles en stock de l’inventaire à l’aide de l’API basée sur l’écran.
//Retrieving the list of stock items from inventory
public static void ExportStockItems()
{
using
{
//Connect to the web service and log in to Acumatica ERP
Screen context = WebServiceConnector.InitializeWebService()
}
{
try
{
IN202500Content stockItemsSchema = context.IN202500GetSchema();
var commands = new Command[]
{
stockItemsSchema.StockItemSummary.ServiceCommands.EveryInventoryID,
stockItemsSchema.StockItemSummary.InventoryID,
stockItemsSchema.StockItemSummary.Description,
stockItemsSchema.GeneralSettingsItemDefaults.ItemClass,
stockItemsSchema.GeneralSettingsUnitOfMeasureBaseUnit.BaseUnit,
new Field
{
ObjectName =
stockItemsSchema.StockItemSummary.InventoryID.ObjectName,
FieldName = “LastModifiedDateTime”
}
};
}
finally
{
context.Logout();
}
}
}
Notez que la ligne dans le code ci-dessus, IN202500Content stockItemsSchema = contexte. IN202500GetSchema(); fait référence à l’écran Inventaire (IN2025000) et son contenu et est donc lié à un écran spécifique qui est l’écran ou la forme que nous avons montré précédemment dans la figure 2.
Les API basées sur un écran sont uniques à Acumatica - elles offrent une valeur énorme en termes d’un ensemble de capacités riches et d’une grande flexibilité. Cependant, ils sont liés à l’écran et tout changement dans l’écran a tendance à modifier l’API elle-même. Par exemple, déplacer un contrôle d’un groupe à un autre - l’ajout d’une petite bordure peut vous forcer à recompiler votre code afin de vous assurer que tout fonctionne correctement. Tout ce qui peut être fait au niveau de l’écran dans Acumatica peut être fait avec l’API basée sur l’écran. Ce qui signifie que vous pouvez automatiser presque n’importe quelle activité ou tâche. Jetons maintenant un coup d’œil à nos API contractuelles.
API de services Web basée sur des contrats
Ces API ont été introduites dans Acumatica 5.3 en février de cette année et sont relativement nouvelles. Les API basées sur des contrats fonctionnent avec des objets de logique métier non liés à l’écran, en soi - et leurs propriétés et méthodes. Les API basées sur des contrats sont construites sur un modèle objet que l’API des services Web fournit. Ils ne changent pas en fonction de la personnalisation du système, de la localisation ou de toute autre modification apportée à Acumatica ERP, telle que les formulaires.
Par exemple, supposons que vous ayez écrit du code à l’aide du champ ItemClass, qui accède au même élément ItemClass ID que nous avons trouvé dans le formulaire d’inventaire IN2025000 dans notre exemple d’API basé sur un écran. Si vous modifiez le nom de l’élément ItemClass ID dans votre projet de personnalisation, votre code reste entièrement fonctionnel et ne nécessite pas de recompilation, ni de modifications supplémentaires. Vous pouvez accéder à l’élément ItemClass ID sur le formulaire via le même champ ItemClassID.
Exemple de code simple basé sur un contrat: Récupération d’une liste d’articles en stock
Comme l’exemple basé sur l’écran dans la section précédente ci-dessus, nous montrons ici à quel point il est facile de récupérer des articles en stock de l’inventaire. Notez les différences entre le code. Ici, notre code ne fait pas référence à un écran pour récupérer les éléments et est très simple et direct.
//Retrieving the list of stock items from inventory
public static void ExportStockItems()
{
using (DefaultSoapClient soapClient = new DefaultSoapClient())
{
//Log in to Acumatica ERP
WebServiceConnector.InitializeWebService(soapClient);
try
{
//Get the list of stock items
Entity[] stockItems =
soapClient.GetList(stockItemsToBeFound, False);
}
finally
{
//Log out from Acumatica ERP
soapClient.Logout();
}
}
}
Pour tout nouveau projet de développement de nos partenaires actuels ou votre premier projet de développement en tant que nouveau partenaire, doit être construit en utilisant les API contractuelles. Cependant, certaines caractéristiques du système ne sont pas encore exposées. Ainsi, vous utiliserez parfois encore certaines des API basées sur un écran. L’utilisation des nouvelles API contractuelles offre une stabilité accrue - non sensible aux problèmes créés par les modifications apportées à votre application ou à ce que nous pouvons changer de notre côté qui peuvent affecter la fonctionnalité de vos applications sans recompilation. Bien sûr, cela devrait aller de soi : il est important de toujours tester vos applications lorsqu’une nouvelle version du produit est publiée, pas seulement pendant votre cycle de développement.
Résumé
Les API basées sur un écran sont uniques à Acumatica - considérez-les comme une sorte d’interface de script pour obtenir des données et des données de notre plate-forme système. Plus important encore, rappelez-vous qu’ils sont liés à l’écran. Chaque écran Acumatica a des champs, des groupes et des conteneurs... et ainsi de suite. Chaque changement dans l’écran a tendance à changer l’API. Par exemple, déplacer un contrôle d’un groupe à un autre - apporter de petites modifications au formulaire ou au code peut empêcher l’application de fonctionner comme prévu - recompiler votre code pour vous en assurer. Avec ces API, vous obtenez une flexibilité énorme et des fonctionnalités riches. Tout ce qui peut être fait au niveau de l’écran peut également être fait avec l’API, ce qui vous donne la possibilité d’automatiser presque tout dans le système.
Avec la publication des API contractuelles, nous exposons nos modèles de données - par exemple CRUD, détails et méthodes simples - qui sont strictement définis. Vous pouvez créer une entité, mettre à jour, lire par critères, par identificateurs de clé, etc. Nous avons exposé et défini notre modèle de données, dont le développeur peut tirer parti sans se soucier des changements d’écran qui peuvent entrer en conflit et casser l’application. Nous encapsulons les changements et cachons la complexité au développeur. Nous avons essentiellement fourni un « contrat » avec les développeurs qui promet que toutes les modifications sous-jacentes que nous apportons ne casseront pas leur code.
En écoutant les commentaires de nos clients et partenaires, nous avons publié nos API contractuelles en février dernier. Bientôt, nous publierons nos API basées sur des contrats compatibles REST qui présentent un certain nombre d’avantages supplémentaires qui enthousiasment les développeurs. Nous fournirons plus de détails dans les prochains articles de ce blog. Nous publierons très bientôt une discussion vidéo sur nos API, y compris un premier aperçu de la prise en charge REST.
Réitérant un message important à nos lecteurs : toute nouvelle intégration, tout nouveau projet de développement démarré doit être construit à l’aide des API contractuelles. Bien que nous investissions nos efforts dans des API contractuelles, les API basées sur l’écran continueront d’être maintenues dans un avenir prévisible. Nous nous attendons à ce que le code de nos partenaires actuels migre au fil du temps pour profiter des avantages de nos API contractuelles.
Pour plus de détails, téléchargez notre Guide du développeur . Si vous avez des questions, visitez notre forum de développeurs sur StackOverflow et postez toutes les questions que vous pourriez avoir.
