Оптимізація робочих процесів Shopify Flow
Створюючи робочий процес, ви прагнете переконатися, що він виконується максимально ефективно. У цьому документі описано сценарії, які можуть призвести до вповільнення ваших робочих процесів або вичерпання лімітів API, а також наведено поради щодо того, як усунути ці проблеми або знайти обхідне рішення.
На цій сторінці
Поширені проблеми з продуктивністю
У цьому розділі описано поширені сценарії, які можуть спричинити проблеми з продуктивністю ваших робочих процесів. Можливе одночасне виникнення кількох сценаріїв, що підвищує ймовірність проблем із продуктивністю. Якщо виникають помилки, пов’язані з конфігурацією редактора або обмеженням частоти запитів, скористайтеся посібником з усунення несправностей.
Тригери з високою частотою спрацьовувань
Тригери з високою частотою спрацьовувань — це тригери, пов’язана з якими подія відбувається часто. Наприклад, тригер Змінилася кількість запасів варіанта товару запускається під час кожної зміни запасів у магазині. Кількість спрацьовувань тригера діє як множник для будь-якої проблеми у вашому робочому процесі. Наприклад, якщо робочий процес отримує 100 товарів і запускається 1000 разів на хвилину, він отримуватиме 100 000 товарів за хвилину. Це може спричинити проблеми з продуктивністю.
Рішення: оптимізуйте свої робочі процеси, використовуючи менше даних, або додайте кроки очікування, щоб розділити робочий процес.
Кілька робочих процесів використовують однаковий тригер
У Flow можна створити кілька робочих процесів з однаковим тригером. Такі робочі процеси запускатимуться паралельно під час виникнення події. Це може бути проблематично, якщо ви запускаєте забагато робочих процесів з однаковим тригером, з наведених нижче причин.
- Робочі процеси можуть конфліктувати між собою.
- Робочі процеси намагаються отримувати дані та викликати API одночасно, а максимальна кількість запитів, які магазин може обробляти водночас, визначається обмеженнями Shopify API.
Рішення: об’єднайте робочі процеси з однаковим тригером в один. Це також дає змогу контролювати час їхнього виконання, щоб вони не конфліктували один з одним. Об’єднання робочих процесів особливо корисне, якщо вони не отримують багато даних або отримують однакові дані. Якщо ж робочі процеси отримують великі обсяги різних даних, краще їх розділити — це може підвищити продуктивність.
Використання списків або неправильних даних
Під час створення робочого процесу ви можете використовувати список об’єктів, наприклад товарів або замовлень. У такому разі Flow отримуватиме всі об’єкти зі списку. Це може стати проблемою, якщо список містить багато даних.
Ще одна поширена проблема — випадковий вибір неправильних даних. Наприклад, щоб перевірити дані товару в замовленні, ви могли вибрати order / publication / products / tags замість order / line items / product / tags. Перший результат зазвичай неправильний, оскільки він повертає всі товари для публікації, хоча метою є перевірка товарів у замовленні. Вибір такого великого списку може спричинити проблеми з продуктивністю, а вибір неправильного — призвести до некоректної роботи автоматизації.
Рішення: ретельно вибирайте потрібні дані та уникайте використання списків без необхідності. Тестуйте робочі процеси, щоб переконатися, що вони виконуються так, як очікується.
Метаполя
Отримання даних окремих метаполів або метаоб’єктів не має спричиняти проблеми з продуктивністю. Однак поширеною проблемою є вибір списку metafields і перебір усіх метаполів для ресурсу. Якщо поле value містить багато даних (наприклад, використовуються об’єкти HTML), це призведе до обробки великого обсягу даних і потенційних проблем із продуктивністю.
Рішення: використовуйте об’єкт metafield замість metafields.
Надмірне використання дій «Отримати дані»
Робочі процеси, що використовують дію Отримати дані (наприклад, Отримати дані замовлення), розраховані на повернення максимум 100 об’єктів на один робочий процес із таких дій. Перевищення ліміту у 100 об’єктів може спричинити проблеми з продуктивністю.
Рішення: запускайте робочий процес частіше, щоб запит не повертав понад 100 результатів. Використовуйте одну й ту саму дію Отримати дані повторно замість створення нових запитів.
Відсутність фільтрів запиту в діях «Отримати дані»
Дії Отримати дані викликають Shopify API. За відсутності запиту API поверне всі ресурси або жодного. Це може спричинити проблеми з продуктивністю, а також призвести до виконання хибних дій у вашому магазині під час подальшого використання отриманих даних у робочому процесі.
Рішення: завжди додавайте фільтри запиту до дій Отримати дані.
Неправильні фільтри запиту в діях «Отримати дані»
Запити Отримати дані підтримують обмежений набір фільтрів запиту, спеціальний синтаксис і певний набір значень, які можна використовувати у фільтрах. Уведення неправильного фільтра, його значення чи синтаксису може призвести до ігнорування всього запиту та спричинити проблеми, подібні до тих, що виникають за відсутності фільтра запиту.
Рішення: скористайтеся документацією до відповідної дії у Flow, щоб знайти список доступних фільтрів запиту. Завжди тестуйте свої фільтри запиту, щоб переконатися, що вони повертають очікувані дані. Ви можете скористатися дією Зареєструвати виведені дані у Flow, щоб переглянути повернуті дані, або викликати Shopify Admin API напряму за допомогою клієнта API (наприклад, Postman) чи застосунку GraphiQL.
Додаткові рішення поширених проблем із продуктивністю
Використовуйте кроки очікування, щоб відкласти отримання даних
Кроки очікування дають змогу призупинити робочий процес на визначений час, але їх також можна використовувати для оптимізації робочих процесів. Кожен крок очікування фактично ділить виконання робочого процесу на окремі фази. Під час запуску робочий процес автоматично отримує дані, необхідні до першого кроку очікування (а після кроку очікування — знову отримує дані для решти робочого процесу).
Якщо робочий процес використовує тригер із високою частотою спрацьовувань і отримує багато даних, але виконує дію лише зрідка, ви можете розмістити будь-які складні дані чи логіку після пари «умова та крок очікування». Наприклад:
- Тригер: Змінилася кількість запасів варіанта товару.
- Умова: Перевірити, чи є товар у колекції.
- Якщо так, Дія: Очікувати 2 секунди.
- Дія: Надіслати клієнту електронний лист (із великою кількістю даних).
У цьому прикладі дані, необхідні для кроку 4, запитуються лише після завершення кроку очікування. Якщо умова зазвичай хибна, це означає, що робочий процес виконуватиметься швидше й ефективніше.
Що не слід оптимізувати
Використання однакових даних у кількох діях
Коли ви використовуєте те саме поле в кількох кроках, Flow аналізує використання цих полів і отримує ці дані лише один раз. Це означає, що ви можете використовувати дані скільки завгодно разів, не турбуючись про продуктивність.