Как из шаблона ZP сделать Webhook?

[BAZAg]

Значит сама проблема такая - что нужно обратиться как-то к шаблону с помощью POST запроса.
Подобные хотелки уже были в теме тут, но там было предложение к разработчикам Zenno.

Зачем это может быть нужно?
Например, хочу написать с помощью ZennoPoster телеграм бота.
Единственное, что сейчас возможно напрямую - это опрашивать обновления телеграм.
Как следствие - нажал кнопку в телеграм боте - и ждешь пока Зенно опросит телеграм.

Но, мне хотелось бы, чтобы телеграм мне присылал обновления сам.
Сейчас мне приходится что-то делать на PHP, который ловит нужный запрос, добавляет в базу, и дальше уже какая-то обработка.
Тоесть, право ответа на обновление от TG у PHP.
Это тоже не особо то, что мне хочется, хочу чтобы ZP отвечал на на обновления.

Понятно, что на уровне сервера ставим какой-то NGINX, который слушает 443 порт (или 80, если домен проксируется клаудфларе).
После чего, данные должен ловить ZP на каком-то локальном порту.
Производить нужные манипуляции, после чего отдавать ответ.
И уже этот ответ сразу же будет отображаться пользователю в телеграме.

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

Или это только у меня такие "уникальные" мысли - и никто о подобном даже не задумывается?

Конечно, ничего не мешает написать через AI какой-то маленький сервер.
При запуске шаблона крутиться там в бесконечном цикле, и слушать только кнопку Прервать от Зеннопостера.
Или, написать что-то подобное на NodeJS, и запускать с помощью шаблона Зеннопостера (типа при закрытии - закрывать NodeJS).

Но... Как потом бороться с конфликтами портов...
Интересно, как вообще решаются подобные хотелки (AI хорошо, но лучше все же собственный опыт, например запуск чего-то подобного написаного AI).

 

[Dr.Pipetka]

Так а что мешает "долбится"? ТГ бот апи поддерживает long polling, раз в 50 сек просто отправлять запрос. Можно библиотеки бот апи использовать.
Но этот подойдет если слушать нужно отдельным шаблоном, а не любым шаблоном во время выполнения другого сценария.

 

[backoff]

так как зенка позволяет запускать шаб с шагом в 1 мин, я запускал шаб проверяющий обновление ТГ
потом запускал шаб, который проверял за эту минуту 10 раз останавливался и сразу запускался, то есть в шаблоне просто сделал цикл проверки, например каждые 10 сек или 5сек

 

[hstq]

BAZAg, ваша схема с PHP и базой уже подходит для webhook. HTTP 200 подтверждает Telegram получение события, а сообщение пользователю можно отправить позже отдельным вызовом sendMessage, когда шаблон закончит работу. Я бы оставил один постоянно работающий обработчик: Nginx принимает HTTPS, PHP проверяет запрос и сохраняет задание в базу. После успешного сохранения возвращает 200. ZennoPoster забирает задания и выполняет их. Тогда перезапуск шаблона не отключает приём событий, а несколько экземпляров не пытаются занять один порт.

В базе стоит хранить update_id и проверять повторы: Telegram может доставить одно событие повторно. Для проверки входящих запросов есть secret_token в setWebhook. Если событие сохранить не удалось, успешный ответ отдавать нельзя. Если проблема именно в задержке, сначала посмотрите, как ZP забирает задания. Запуск раз в минуту и даст ожидание до минуты независимо от скорости webhook.

 

[BAZAg]

BAZAg, ваша схема с PHP и базой уже подходит для webhook. HTTP 200 подтверждает Telegram получение события, а сообщение пользователю можно отправить позже отдельным вызовом sendMessage, когда шаблон закончит работу. Я бы оставил один постоянно работающий обработчик: Nginx принимает HTTPS, PHP проверяет запрос и сохраняет задание в базу. После успешного сохранения возвращает 200. ZennoPoster забирает задания и выполняет их. Тогда перезапуск шаблона не отключает приём событий, а несколько экземпляров не пытаются занять один порт.

В базе стоит хранить update_id и проверять повторы: Telegram может доставить одно событие повторно. Для проверки входящих запросов есть secret_token в setWebhook. Если событие сохранить не удалось, успешный ответ отдавать нельзя. Если проблема именно в задержке, сначала посмотрите, как ZP забирает задания. Запуск раз в минуту и даст ожидание до минуты независимо от скорости webhook.

Что-то подобное я делаю.
Из-за чего при привел как пример PHP.

Но... Это чуток не то что я хочу...
Когда телеграм присылает обновления - он ожидает не меньше 30 секунд на ответ.
Я на своей стороне (PHP) выполняю какой-то код, после чего отвечаю телеграму в виде body.

Что-то похожее мне надо и с ZP. Чтобы ZP получил обновление от телеграма, выполнил какие-то кубики логики и в том же запросе ответил телеграму. Это и дало бы необходимую динамичность без задержек.

 

[qckl]

Для этого нужен один постоянно работающий HTTP-обработчик он присваивает запросу ID, передаёт задачу запущенному шаблону и ждёт результат с тем же ID. Сразу предусмотрите таймаут, ограничение параллельных запросов и защиту от повторной обработки update_id.