Когда приложение отправляет HTTP-запрос, важно понимать, что произошло дальше. Принял ли его сервис доставки? Ответил ли получатель? Будет ли следующая попытка? Если вебхук направлен в несколько приложений, у каждого из них может быть свой результат.
В большом обновлении Adal Cloud от 3 ноября мы уделили внимание всему этому пути: от приёма запроса до разбора конкретной попытки. Обновили Outbound и доставку входящих вебхуков, добавили сводки в кабинете и управление API-токенами. Вместо подписок теперь используются разовые пакеты трафика, а правила хранения стали едиными и понятнее описаны в документации.
Главная задача обновления — дать больше информации для повседневной работы с интеграциями и упростить управление доставкой.
Outbound: от отправки через API до ответа получателя
Adal Outbound позволяет передать исходящий HTTP-запрос через API и поручить Adal Cloud его исполнение в выбранном регионе. Приложение задаёт адрес получателя, метод, заголовки и тело. Для такой отправки не нужно создавать входящий Сервер или настраивать маршрут вебхуков.
Мы обновили работу с Outbound, чтобы после отправки было проще проследить результат. В карточке доступны история попыток, HTTP-коды, ошибки и подробности соединения. Можно разобраться, на каком этапе возникла проблема: при установлении соединения, работе TLS или получении HTTP-ответа. Данные доступны в кабинете и через API. Поток интеграции описан в документации Outbound, а разбор попыток — в руководстве по диагностике.
Например, приложение передало уведомление внешнему получателю, но первая попытка завершилась ошибкой. В истории видно эту попытку и последующее исполнение. Команде проще понять, нужно ли исправлять адрес или доступ к получателю либо достаточно дождаться автоматического retry.
Ещё одна возможность — сохранение тел ответов. Если включить save_response_body при отправке, сохранённый ответ конкретной попытки можно скачать отдельно от исходного тела запроса. Это помогает исследовать содержимое ошибки, которое вернул получатель. По умолчанию сохранение ответов выключено; включить его задним числом для уже полученного ответа нельзя. У сохранённого ответа также может быть признак неполного чтения или усечения — его стоит проверить перед использованием файла. Подробнее — в документации HTTP-данных.
При этом ответ 202 от API Adal Cloud подтверждает приём задания. Фактический результат нужно смотреть по запросу и его попыткам. Даже успешный HTTP-ответ получателя сам по себе не подтверждает завершение бизнес-операции в его приложении.
Входящие вебхуки: результат для каждого получателя
Для Inbound мы обновили настройку связей и историю доставки. Сервер Adal Cloud принимает вебхуки на публичный URL. Канал объединяет Ендпоинты — адреса получателей, а Маршрутизатор связывает Серверы с Каналами. Один Канал можно использовать для нескольких Серверов.
Канал типа Direct доставляет запрос доступному из региона HTTP-получателю. Канал типа CLI используется для доставки приложению, доступному с компьютера, где запущен Adal CLI. Публичные настройки описаны в разделах «Каналы и Ендпоинты» и «Маршрутизаторы».
У каждого получателя собственные попытки и результат. Если один обработчик успешно принял вебхук, а второй временно недоступен, успех первого не завершает доставку второму. В истории можно открыть нужный Канал, посмотреть Ендпоинт, его URL и отдельные попытки.
Это особенно полезно при частично успешной доставке. Например, вебхук дошёл до системы учёта, а попытки доставки дополнительному обработчику закончились неуспехом. Общий статус partial показывает различие итоговых результатов, а подробности помогают увидеть, какой получатель требует внимания. Не нужно судить о всём запросе по одному HTTP-коду. Разбор таких состояний есть в документации истории Inbound.
Мы также улучшили возобновление незавершённых доставок CLI после переподключения и перезапуска клиента. Уже сохранённую работу клиент продолжает при сохранении его локальных данных. Доставка запросов, накопленных за время отсутствия клиента, отдельно регулируется настройкой Deliver backlog. Эти два случая важно различать; подключение клиента не означает безусловную доставку всей истории. Порядок работы описан в документации Adal CLI.
После прерывания HTTP-доставка может повториться. Получателю по-прежнему нужна идемпотентная обработка, чтобы повтор события не создавал повторную бизнес-операцию.
Сводки и журналы для повседневной работы
На главной странице кабинета появились отдельные сводки Inbound и Outbound. Они показывают активность, недавние запросы, ошибки и незавершённые доставки, а затем позволяют перейти к журналу для разбора подробностей.
Обновлённые фильтры помогают сузить поиск по периоду, статусу и региону. В журнале и карточках виден регион приёма или отправки, а также расход трафика. Мы обновили работу регионов в Стокгольме, Нюрнберге и Алматы; региональная привязка запроса остаётся видимой при диагностике.
Для интеграций в кабинете теперь можно создавать API-токены, выбирать срок их действия, проверять последнее использование и отзывать ненужные. Секрет показывается при выпуске один раз. API-токен используется приложением для вызовов Outbound; у CLI-Канала свой отдельный секрет. Подробности — в документации доступа и API-токенов.
Пакеты трафика вместо подписок
Мы изменили модель оплаты: теперь трафик приобретается разовыми пакетами. Покупки суммируются, оплаченные байты не сгорают, налоги включены в стоимость пакета. Это удобно для интеграций с неравномерной нагрузкой: приобретённый объём можно расходовать по мере поступления запросов.
Inbound и Outbound используют общий баланс аккаунта. В Billing отдельно видны бесплатный и оплаченный остатки, дата обновления Free и состояние покупок.
Бесплатный объём составляет 10 MiB после подтверждения почты и обновляется каждые 30 дней без накопления. При обновлении бесплатный остаток заменяется на 10 MiB; оплаченный остаток сохраняется. Сначала расходуется Free, затем оплаченный трафик. Актуальные пакеты доступны в Billing.
Для понимания расхода важны различия направлений. У Inbound учитываются путь и query, заголовки и тело принятого запроса. Несколько получателей и повторные попытки не умножают исходное списание.
У Outbound исходное декодированное тело учитывается один раз при начале первой HTTP-попытки. Если сохранение ответов включено, дополнительно учитываются сохранённые байты ответа каждой попытки, включая ошибочные и неполные ответы. Например, тело запроса на 1000 байтов и два сохранённых ответа на 200 и 300 байтов дадут 1500 байтов расхода. Повторная попытка не добавляет исходные 1000 байтов ещё раз.
Полные правила приведены в документации трафика и оплаты.
HTTP-данные доступны 90 дней
Для входящих и исходящих запросов действует срок доступности HTTP-данных 90 дней с момента приёма. Он одинаков для всех пакетов трафика. Повторы, чтение данных, покупка пакета и обновление Free этот срок не продлевают.
При этом содержимое запроса и запись о доставке имеют разный жизненный цикл. После удаления HTTP-данных в журнале могут оставаться статус и история исполнения. Видимая строка запроса не означает, что его тело всё ещё доступно для скачивания.
У Outbound этот же срок относится к сохранённым ответам и подробной HTTP-диагностике. Ориентироваться нужно на дату удаления конкретного запроса. Правила собраны в разделе о хранении и удалении.
Обновлённая документация и следующий шаг
Вместе с продуктом мы обновили документацию, описание безопасности, политику конфиденциальности и условия использования. В них отражены текущие возможности Inbound и Outbound, работа с HTTP-данными, пакеты трафика и правила хранения.
Откройте кабинет Adal Cloud, посмотрите новые сводки и выберите запрос в журнале. В его карточке можно проследить результат доставки, проверить попытки и увидеть, какие данные доступны для разбора. Полный список изменений опубликован в changelog от 3 ноября.