Интеграция с Zapier

Интеграция скучна. И тоже неизбежно. Но я не буду писать о шаблонах корпоративной интеграции . Вместо этого я объясню, как создать приложение для интеграции с Zapier.

Что такое Zapier ? Это сервис, который позволяет вам соединять два (или более) иным образом не связанных сервиса через их API (или протоколы). Вы можете делать такие вещи, как «Создать задачу Trello из заметки Evernote», «публиковать новые элементы RSS в Facebook», «добавлять новые электронные письма в электронную таблицу», «публиковать сообщения о приближении календарного собрания в Slack», «сохранять большие вложения электронной почты в Dropbox». »,« Чирикать все инстаграммы выше определенного порога лайков »и так далее. Фактически, он охватывает в основном те же случаи использования, что и другой известный сервис, который мне действительно нравится — IFTTT (если это то, что) , с моим любимым сценарием использования «Получите уведомление, когда международная космическая станция проходит над вашим домом». И все эти взаимодействия могут быть настроены через пользовательский интерфейс.

Теперь это хорошо для конечных пользователей, но какое это имеет отношение к разработке программного обеспечения и интеграции? Zapier (в отличие от IFTTT, к сожалению) позволяет включать сторонние сервисы. Поэтому, если у вас есть собственная служба, вы можете создать «приложение» и позволить пользователям интегрировать вашу службу со всеми другими сторонними службами. IFTTT предлагает способ вызова конечных точек сети (включая службы RESTful), но он не позволяет устанавливать заголовки, что делает его весьма ограниченным для реальных API.

В этой статье я кратко объясню, как написать собственное приложение для Zapier, а затем расскажу, где такие сервисы, как Zapier, стоят с точки зрения архитектуры.

Вещь, в которой я нуждался, — возможность интегрировать LogSentinel с любыми третьими лицами, доступными через Zapier, т.е. хранить журналы аудита для событий, которые происходят во всех этих сторонних системах. Так как мне это сделать? Есть учебник, который делает это простым. И это с несколькими уловами.

Во-первых, есть два урока — один на GitHub и один на сайте Zapier . И они немного отличаются, что становится сложно в некоторых случаях.

Сначала я следовал учебному пособию по GitHub, и моя сборка не удалась. Утверждалось, что зависимость от платформы zapier отсутствует. После того, как я сравнил его с примерами приложений , я обнаружил, что перед зависимостью от платформы zapier есть каретка. Удаление просто привело к другой ошибке — версия моего узла должна быть точно 6.10.2. Почему?

Zapier CLI требует, чтобы у вас была установлена ​​точно версия 6.10.2. Вы увидите ошибки и не сможете продолжить.

Похоже, что они используют AWS Lambda, которая застряла на узле 6.10.2 (на самом деле — это 6.10.3, когда вы проверяете). Текущий основной выпуск — 8, так что минус баллы за выбор… javascript для инструмента командной строки и для создания изолированных приложений. Возможно, у других решений были и свои недостатки, я не буду спекулировать. Может быть, это просто моя нелюбовь к динамическим языкам .

Итак, после того, как вы удостоверились, что на узле установлена ​​правильная старая версия, вы вызываете zapier init и проверяете, нет ли карет, npm install и затем zapier test Пока все хорошо, у вас есть фиктивное приложение. Теперь, как вы делаете RESTful звонок на ваш сервис?

Zapier разделяет программируемые объекты на два — «триггеры» и «создает». Триггер — это событие, которое запускает все приложение, а «создание» — это то, что происходит в результате. В моем случае мое приложение не публикует никаких триггеров, оно только принимает входные данные, поэтому я не буду упоминать триггеры (хотя они кажутся простыми). Вы настраиваете все элементы в index.js (например, этот ):

Интересен сам файл log.js — там вы указываете все параметры, которые должны быть переданы вашему вызову API, а также делаете сам вызов API:

Вы можете передать входные параметры в ваш вызов API, и это так просто. Затем пользователь может указать, какие параметры из источника («триггера») должны быть сопоставлены с каждым из ваших параметров. В примере zap я использовал триггер электронной почты и передал отправителя как actorId, sibject — как «действие», а тело письма — как детали.

Есть еще одна вещь — аутентификация. Аутентификация может быть выполнена разными способами. Некоторые сервисы предлагают OAuth, другие — HTTP Basic или другие пользовательские формы аутентификации. В документации есть раздел обо всех опциях. В моем случае это была (почти) базовая аутентификация HTTP. Моя первоначальная мысль состояла в том, чтобы просто предоставить учетные данные в качестве параметров (которые вы просто жестко кодируете, а не отображаете для запуска параметров). Это может сработать, но это не канонический способ. Вы должны настроить «аутентификацию», поскольку она запускает дружественный пользовательский интерфейс для пользователя.

Вы включаете authentication.js (в котором есть поля, необходимые для вашей аутентификации), а затем предварительно обрабатываете запросы, добавляя заголовок (в index.js):

И тогда вы zapier push свое приложение, и вы можете проверить его. Он не запускается автоматически, так как вы должны пригласить людей попробовать его и использовать его в первую очередь , но во многих случаях этого достаточно (например, используя Zapier при интеграции с конкретным клиентом)

Можно ли использовать Zapier для решения проблем интеграции? Маловероятно — это довольно ограниченно и просто, но это тоже сила. Вы можете за полдня сделать так, чтобы ваш сервис интегрировался с тысячами других для наиболее типичных сценариев использования. И не то, чтобы, хотя это было предназначено для интеграции общедоступных служб, а не для корпоративной интеграции (когда вы заставляете множество внутренних систем взаимодействовать друг с другом), поскольку все большее число систем полагается на сторонние службы, оно может найти свое место в корпоративной системе, заменив некоторые функции ESB.

По сути, такие услуги (Zapier, IFTTT) являются «простыми ESB-как-услуга». Вы переходите в пользовательский интерфейс, заполняете кучу полей и получаете системы, взаимодействующие друг с другом, не касаясь самих систем. Я не большой поклонник ESB , в основном потому, что со временем их становится все труднее поддерживать. Но минималистские, внешние могут быть применимы в определенных ситуациях. И хотя такие сервисы в первую очередь предназначены для конечных пользователей, они могут быть полезны в корпоративной архитектуре, основанной на сторонних сервисах.

Может ли она обрабатывать требуемую нагрузку, готова ли организация передавать свои данные через стороннего поставщика (который может хранить промежуточные параметры), — это вопрос, на который следует отвечать в каждом конкретном случае. Я бы не рекомендовал это как общее решение, но это, безусловно, вариант для рассмотрения.