Comment optimiser un scénario Make efficacement ?

Introduction

Le no-code est devenu un élément incontournable dans les entreprises de toutes tailles, et de plus en plus de workflow, permettant d’automatiser une partie des tâches répétitives d’une entreprise - dans le cadre du Robotic Process Automation (RPA), sont utilisés dans le but de réduire la pénibilité ou les coûts. En particulier, Make est un outil simple mais puissant permettant de répondre à des cas d’usages variés d’automatisation. Aujourd’hui nous allons discuter de moyens d’optimiser un workflow Make en analysant un exemple de récupération de donnée.

Pourquoi optimiser les performances de mes scénario ?

Le besoin d’optimiser un scénario peut répondre à plusieurs problématiques. Tout d’abord il faut savoir que Make impose un temps limite à l’exécution d’un scénario, qui est de 45 minutes. Bien que ce temps soit légèrement suffisant dans la plupart des cas, des scénarios complexes de synchronisation ou des ensembles de données volumineux peuvent facilement faire dépasser cette limite. Dans ce cas le scénario s’arrête sans pouvoir continuer à son terme, d’où le besoin d’optimiser.

Aussi, au vu de la tarification de Make (qui facture par pack de nombre d’opérations et de transfert de donnée), il peut être intéressant d’optimiser le fonctionnement des scénarios pour gagner en coûts de fonctionnement.

Enfin, l’optimisation de processus no-code est aussi pertinent dans le cadre de l’éco-conception. En effet le faite de raccourcir le temps d’exécution d’un scénario va mécaniquement impacter sa consommation de ressources à la baisse.

Cas d’usage: récupération d’informations d’un CRM

Dans cette partie nous allons détailler l’exemple suivant: nous voulons récupérer toutes les tâches qui ne sont pas closes et dont l’échéance est passé, pour une liste de contacts donnée. Le CRM utilisé sera Hubspot et le workflow retournera le nombre de tâches dont l’échéance est passée.

Une méthode triviale peut être implémentée comme ceci:

• On récupère tous les contacts concernés
• Pour chaque contact, on récupère les associations contacts > tâches
• Pour chaque association, on récupère la date d’échéance de la tâche
• Si la tâche a une échéance dépassée, on incrémente la variable comptant le nombres de tâches à l’échéance dépassée.

En soit cette approche est valide pour la plupart des cas. Cependant dans le cas où le compte est volumineux, cela peut faire exploser le temps pris par le scénario. Par exemple ici avec un compte contenant plus de 1k contacts concernés:

Nous allons donc voir comment optimiser ces opérations et le temps de fonctionnement.

Optimisation des workflows: la méthode

Afin d’optimiser un workflow, il est possible de suivre un plan très simple afin de réduire drastiquement la consommation de ces processus:

1. Identifier le passage le plus critique en terme de consommation de ressource
2. Penser à une autre méthode d’implémentation de ce point. (par exemple, sortir une opération longue d’un itérateur, etc…) et définir le gain possible
3. Implémenter la modification
4. S’assurer que l’optimisation appliquée est bien conforme aux attentes (parfois une modification censé améliorer les choses peut en fait les empirer)
5. Recommencer à l’étape 1 autant que souhaitable

Dans notre exemple, on peut voir que l’étape de récupération individuelle des tâches est la plus chronophage et importante en terme de timing (3862 appels dans l’exemple et un temps par appel non négligeable). On va donc chercher tout d’abord à optimiser cette étape en premier lieu.

Ici, pour réduire le nombre d’appels effectuées lors de la récupération des tâches, une solution possible peut être d’utiliser un traitement par batch. Le traitement par batch est une technique permettant d’envoyer des requêtes portant sur plusieurs entités en une seule fois, et agir sur les données de toutes ces entités (soit via la récupération ou la modification des entités).

Pour implémenter le traitement par batch, on va tout d’abord récupérer toutes les références vers les tâches (comme lors du scénario précédent), mais au lieu de récupérer chaque tâche individuellement par la suite, on va les récupérer par batch de 100 (le maximum qu’il est possible de soumettre en un appel). Par conséquent le nombre d’appels concernant les tâches sera divisé par 100, ce qui peut apporter un gain significatif.

Pour implémenter la solution, la première partie du processus sera inchangée. Par contre le reste devra être modifié pour pouvoir traiter les éléments par lot. Il va falloir stocker les tâches à aller récupérer, calculer les lots de tâches à envoyer à chaque appel, et utiliser l’api de batch fournie par Hubspot (à l’aide du module “Make an API Call” de Make). Une fois toutes les modifications effectuées on se retrouve avec un scénario certes plus complexe, mais qui a pour but d’être plus optimisé:

• On initialise les variables utiles à l’implémentation du traitement par lot
• On récupère tous les contacts correspondant
• Pour chaque contact, on liste les associations avec une tâche
• Pour chaque association, on stocke l’identifiant de la tâche correspondante
• Ensuite on construit des requetés par lot de 100 tâches avec les tâches précédemment stockés
• Et on compte les quelles ont une échéance passée.

Nous pouvons voir que le temps pris par ce scénario exemple avec le même ensemble de donnée est deux fois plus cours, ce qui valide l’optimisation réalisée.

Maintenant que nous avons vu la principale source d’optimisation était résolu, intéressons nous à la seconde: similairement au tâche, la récupération des associations peut également se faire en batch. Dans la version précédente du scénario, il y a autant d’appels à l’API d’association que de contacts présents (soit plus de 1K). Dans un processus similaire à l’optimisation précédente, on se retrouve avec ce scénario:

Et bien que le scénario semble aussi complexe que le précédent, le nombre d’appels à l’API d’association a lui aussi été divisé par 100 du fait du traitement par lot. D’où un gain spectaculaire en temps et en nombre d’opérations

Conclusion

Dans cet article nous avons vu qu’avec une stratégie d’optimisations simple, il est possible de gagner des performances de manière massive sur un workflow Make utilisant hubspot (temps divisé par 13, nombre d’opérations divisé par 4). Bien sûr, des techniques similaires existes pour d’autres modules Make ayant des finalités différentes, ou même d’autres outils de workflow no-code (par exemple n8n ou zapier). Ces optimisations, lorsque elles sont bien exécutées et testées peuvent engendrer des économies significatives ainsi que de permettre certains workflow exigeants de tenir dans les délais imparti par Make.