My Geocode

Миграция

Перенос автоматизации Zapier или Make на новый хост геокодирования

· 3 мин чтения · My Geocode · #zapier#make#automation#no-code#geocoding#migration

Автоматизации, созданные в Zapier или Make, часто содержат шаг геокодирования, встроенный в более крупный процесс: через форму приходит новый лид, его адрес геокодируется для проверки закрепления за территорией, и результат запускает решение о маршрутизации дальше по цепочке. Такие процессы нередко создаёт человек без опыта разработки программного обеспечения, используя готовый коннектор приложения или универсальный HTTP-модуль, который платформа предлагала в тот момент, и это меняет то, как на самом деле выглядит миграция, по сравнению с собственной кодовой базой.

Если ваш текущий шаг геокодирования использует специальный коннектор приложения, то есть официальную интеграцию, созданную Zapier или Make именно для этого поставщика, переход к поставщику без аналогичного специального коннектора означает замену этого шага универсальным HTTP- или webhook-модулем, настроенным на прямой вызов API нового поставщика. Это реальное изменение в устройстве автоматизации, а не просто замена учётных данных, и замещающий шаг стоит тщательно протестировать в изолированном тестовом сценарии, прежде чем трогать рабочую автоматизацию, от которой зависят другие части бизнеса.

Конкретные шаги для такого перехода:

  1. Создайте копию существующей автоматизации в конструкторе платформы, а не редактируйте её на месте, чтобы рабочая версия продолжала работать, пока замещающая версия не будет полностью протестирована
  2. Замените шаг геокодирования универсальным HTTP-модулем, настроенным на эндпоинт и аутентификацию нового поставщика, поскольку ключ в параметре запроса или заголовок Authorization: Bearer (здесь поддерживаются оба варианта) легко настроить в универсальном HTTP-модуле без специального коннектора
  3. Сопоставьте поля ответа вручную на шаге сопоставления данных в автоматизации, поскольку универсальный HTTP-модуль возвращает необработанные данные ответа, которые нужно явно сопоставить с полями, ожидаемыми последующими шагами автоматизации, в отличие от специального коннектора, который часто делает это сопоставление автоматически
  4. Протестируйте на разнообразных реальных входных данных, включая особые случаи вроде неполных адресов или необычного форматирования, поскольку именно такое тестирование легко пропустить в no-code инструменте, где сам «код» не виден для проверки так, как был бы виден скрипт
  5. Переключите триггер с тестовой версии на скопированную и проверенную автоматизацию и только потом отключите исходную, убедившись, что новая в течение некоторого времени корректно работает на реальных данных

Поскольку совместимый хост воспроизводит точный формат ответа знакомого поставщика, то если шаг геокодирования в вашей исходной автоматизации вызывал поставщика, для которого здесь есть совместимый хост, сопоставление полей в шаге 3 выше может сильно напоминать то, которое ваш исходный коннектор уже использовал внутри, и это может заметно сократить миграцию. Полный список совместимых хостов находится на странице /compatibility/, и его стоит проверить, прежде чем решать, что сопоставление полей придётся делать с нуля.

Для критически важной для бизнеса автоматизации дополнительная осторожность (тестирование на копии вместо правки рабочей версии) стоит небольших дополнительных затрат времени на настройку, поскольку сломанную автоматизацию распределения лидов обычно быстро замечают, причём люди за пределами технической команды.

Ещё в разделе «Миграция»