Meilleures pratiques en matière de fonctionnalités

Utilisez les fonctions pour écrire dans des tables

Approche recommandée

Créez des fonctions lorsque plusieurs applications ou étapes d’application écrivent dans la même table et lorsque vous devez appliquer :

• Des champs obligatoires
• Des valeurs valides (par exemple, le statut doit figurer dans une liste approuvée)
• Des métadonnées cohérentes (créé par, créé le)

Pourquoi est-ce important ?

Lorsque des développeurs amateurs créent des enregistrements de table directement dans des déclencheurs, ils peuvent :

• Ne pas respecter les conventions de nommage des identifiants
• Oublier des champs obligatoires
• Faire des fautes d'orthographe dans les valeurs des champs (« en cours » vs « en-cours »)
• Remplir les métadonnées de manière incohérente

Une fonction impose le même schéma et empêche ces erreurs.

Exemple

Au lieu de laisser chaque développeur d’application créer des enregistrements « Échantillon » avec des champs et un contenu incohérents, créez une fonction « Créer un échantillon » qui :

• Exige des données de saisie cohérentes (ID de tâche, type d’échantillon, quantité, horodatage, utilisateur, nom de l’application)
• Vérifie que le type d’échantillon figure bien dans une liste approuvée

Fonction:CreateSampleEntrées : - job_id (texte) - sample_type (texte) - quantity (nombre) - nom de l'application (texte) - utilisateur demandeur (utilisateur)

Logique: 1. Vérifier que type\_d'échantillon figure dans ["A", "B", "C"] 2. Si invalide, renvoyer un message d'erreur 3. Créer un enregistrement de table avec : - ID : généré au sein de la fonction - ID de tâche : valeur fournie - Type d’échantillon : valeur fournie - Quantité : valeur fournie - Numéro de lot : valeur fournie (ou vide si non fourni) - Créé par : valeur fournie4. Renvoyer un message de réussite

Sorties: - statut (texte) : « success » ou « error » - message (texte) : description de l'erreur en cas d'échec

Lorsque vous devez créer une fiche de table pour un échantillon, transmettez les données d’entrée à une fonction, qui se charge du reste.

Modèle à éviter

Ne créez pas de fonction pour chaque opération d’écriture dans la table, même les plus simples.

Pourquoi cela pose-t-il problème ?

• Cela entraîne une prolifération de fonctions (des centaines de fonctions à usage unique)
• Cela ajoute de la complexité sans apporter d'avantage pour les écritures simples
• Rend le débogage plus difficile (plus d'endroits à vérifier)

Quand éviter d'utiliser des fonctions pour les écritures dans les tables

• Mise à jour d'un enregistrement existant dans une table (par exemple, mise à jour du statut ou diminution de la quantité)
• Écritures dans une table effectuées par une seule application
• Aucune gouvernance ni validation requise

Utilisez des fonctions pour les logiques répétitives en plusieurs étapes

Approche recommandée

Si la même séquence d’actions déclenchées se produit à plusieurs étapes dans plusieurs applications, extrayez-la dans une fonction.

Exemple : obtenir le code ZPL pour l'impression d'une étiquette

Fonction: Obtenirle code ZPLEntrées: - ID du matériel (texte)

Variables: - Variable « Code ZPL » (texte)

Sorties: - Code ZPL (texte)

Logique: 1. Mise à jour des données : configuration « Variable de code ZPL » - Définir sur - [Expression pour le code ZPL incluant @Inputs.ID du matériel] 2. Retour : « Code ZPL » Source de données « Variable de code ZPL »

Modèle à éviter

Ne créez pas de fonctions pour une logique qui ne se produit qu’une ou deux fois au total dans l’ensemble des applications.

Pourquoi cela pose-t-il problème ?

• La charge liée à la gestion de la fonction dépasse les avantages qu’elle apporte
• Oblige les développeurs d’applications à apprendre l’interface de la fonction pour un cas rare
• Cela complique le débogage, en raison de la nécessité de basculer entre les fonctions et les applications

Intégrez les fonctions de connecteur dans les fonctions

Approche recommandée

Lorsque vous utilisez une fonction de connecteur, transmettez les entrées de cette fonction à une fonction qui l'appelle. Cette dernière peut alors gérer les tentatives en cas de délai d'expiration et le traitement des erreurs de manière plus simple et centralisée, ce qui vous permet de simplifier la logique des applications dans l'ensemble de votre solution.

L'intégration des fonctions de connecteur dans des fonctions peut également minimiser l'effort lié à une éventuelle migration ERP future en réduisant le nombre de modifications à apporter aux applications individuelles.

Exemple

Fonction: Mise à jourde la commande de processusEntrées : - ID de la commande (texte) - Statut (texte)

Sorties: - Message d’erreur (texte)

Variables: - Code HTTP (entier) - Nombre de tentatives en cas de délai d’expiration (entier) - Message d’erreur (texte)

Logique: 1. Exécuter la fonction du connecteur 2. Si le code HTTP indique une réussite, terminer la fonction 3. Si le code HTTP indique un délai d’expiration et que le nombre de « tentatives en cas de délai d’expiration » est inférieur ou égal à une valeur spécifiée, incrémenter le nombre de « tentatives en cas de délai d’expiration » et revenir à « Exécuter la fonction du connecteur »4. Si le code HTTP correspond à un code qui ne peut pas être résolu par la logique de la fonction, renvoyer un message d’aide dans la sortie « Message d’erreur »

Transmettez les identifiants des enregistrements, et non les champs individuels des enregistrements de la table

Approche recommandée

Lorsqu’une fonction a besoin de données provenant d’un enregistrement de table, transmettez l’ID de l’enregistrement et chargez l’enregistrement à l’intérieur de la fonction.

Exemple

Bien que l’exemple suivant soit logiquement correct (où « ID de commande » correspond à l’ID de la table « Commandes » et où les autres champs sont des colonnes de cette table), il existe une configuration plus simple.

Fonction: Traiterla commandeEntrées: - ID de commande (texte) - Nom du client (texte) - ID du produit (texte) - Quantité (nombre) - Date d'échéance (date-heure) - Priorité (texte)

Logique: 1. [Appliquer la logique à l’aide des champs de saisie]

L’exemple ci-dessous utilise un minimum de données d’entrée pour obtenir le même résultat :

Fonction: Traiterla commandeEntrées: - ID de commande (texte)

Logique: 1. Récupérer un enregistrement de la table « Commandes » où ID = l’ID de la commande saisi 2. [Appliquer la logique à l’aide des champs de l’enregistrement]

Pourquoi le deuxième exemple constitue-t-il une meilleure approche ?

• Moins de données d'entrée (1 au lieu de 6+)
• La fonction s'adapte facilement en cas de modification du schéma de la table
• Appels de fonction plus clairs dans les applications
• Réduit le risque d’associer un champ incorrect à une entrée incorrecte

Nommer et décrire les fonctions et les paramètres de manière cohérente

Approche recommandée

Utilisez une convention de nommage cohérente pour toutes les fonctions de votre espace de travail.

Noms des fonctions

• Utilisez un verbe + un nom : Créer un échantillon, Mettre à jour le statut d’une tâche, Valider le numéro de série
• N'utilisez pas uniquement des noms : Échantillon, Tâche, Numéro de série

Description de la fonction

• Rédigez une description intuitive de ce que fait la fonction. Par exemple, pour une fonction nommée « Créer un défaut », rédigez une description telle que « Crée un nouvel enregistrement dans la table Défauts avec le statut OUVERT ».

Noms des champs de saisie

• Utilisez une terminologie cohérente : toujours « ID de bon de travail » (et non pas parfois « ID de commande » ou « Work_id »)
• Faites correspondre les noms des champs de la table dans la mesure du possible

Noms des blocs logiques

• Soyez explicite : « Récupérer l'enregistrement de la tâche » et non « Récupérer l'enregistrement de la table »
• Aidez les futurs lecteurs : « Valider le type d'échantillon » et non « Vérifier la valeur »

Pourquoi est-ce important ?

• Les développeurs d'applications comprennent rapidement l'objectif des fonctions
• Réduit la charge cognitive lors de l'utilisation de plusieurs fonctions
• Facilite l'analyse des « utilisations »
• Améliore la documentation et la formation

Gère de manière transparente la validation des entrées et les messages d'erreur destinés aux utilisateurs

Approche recommandée

Marquez toujours les entrées des fonctions comme des champs obligatoires et utilisez des règles de validation des entrées lorsque cela est approprié. Ne validez pas les entrées au sein des fonctions.

Pourquoi est-ce important ?

• Les utilisateurs de l'application reçoivent un retour d'information clair lorsqu'ils saisissent des valeurs
• Cela simplifie la logique des fonctions, car l'application se charge de la validation des entrées et permet à la fonction de s'exécuter avec des entrées dont la validité est garantie
• Cela évite que des données soient corrompues par des entrées erronées

Pratique à éviter

Ne validez pas les entrées au sein de la fonction.

Pourquoi cela pose-t-il problème ?

• Cela fait double emploi avec les fonctionnalités de validation des entrées disponibles dans l’éditeur d’application
• Latence supplémentaire inutile liée à la revérification de la validité des entrées au sein de la fonction

Réduisez au minimum les requêtes sur les tables à l'intérieur des boucles

Si votre fonction parcourt un tableau en boucle, évitez d'interroger les tables à chaque itération. Interrogez plutôt la table une seule fois avant la boucle et utilisez le résultat en référence.

Utilisez les fonctions pour la logique, pas pour de simples références

Ne créez pas de fonctions qui se contentent de récupérer un seul enregistrement de table : c’est à cela que servent les requêtes « record placeholders ». Réservez les fonctions à la logique qui transforme les données.

Limitez la taille des résultats

Si votre fonction renvoie des objets ou des tableaux volumineux, envisagez de ne renvoyer que les champs dont l’application a besoin, et non l’intégralité du tableau d’objets.

Ressources supplémentaires

{{snippet.Avez-vous trouvé ce que vous cherchiez ?}}