Публикация и планирование через MCP

За пределы Papera выходят четыре инструмента: два публикуют, два управляют расписаниями. Эта страница описывает, что делает каждый и какой шаг подтверждения у них общий.

Чтобы публиковать, процессу нужен пост, хотя бы один связанный с ним подключённый аккаунт и триггер, связанный с постом. Как это соединяется, описано в статье Сборка процесса.

Шаг подтверждения

Каждый инструмент на этой странице вызывается дважды:

1. Клиент вызывает его без confirm_token. Papera возвращает план, где точно описано, что произойдёт, и вместе с ним токен.
2. Клиент показывает вам план. Если вы согласны, он вызывает тот же инструмент ещё раз с теми же аргументами и с токеном, и Papera действует.

Токен одноразовый и истекает через десять минут. Он привязан ровно к тем аргументам, для которых выдан, поэтому, если между планом и подтверждением что-то изменится, вы получите новый план, а не неожиданность.

Публикация определения процесса

publish_workflow сохраняет снимок процесса, чтобы по нему могли работать расписания. Ничего не публикуется наружу. Это должно произойти до того, как триггер можно поставить на расписание.

Публикация по-настоящему

publish_post публикует в подключённые аккаунты. Читайте его план внимательно, прежде всего по одной причине:

Подтверждение запускает весь триггер целиком. Каждый пост, до которого дотягивается этот триггер, уходит во все связанные с ним аккаунты, а не только тот пост, который вы назвали.

План сообщает вам:

• каждую пару «пост и аккаунт», её площадку и число медиафайлов в ней,
• сколько аккаунтов получат пост,
• каждый пост, оставленный в стороне из-за того, что его содержимое не удалось прочитать,
• и два побочных действия: сохранённый снимок заменяется текущим черновиком, а любое расписание, чей триггер больше не входит в черновик, останавливается.

Если до поста дотягивается больше одного триггера, Papera не выбирает за вас и спрашивает, какой trigger_id запускать.

Как следить за результатом

Публикация идёт в фоне. publish_post возвращает идентификатор запуска (occurrence id), а get_publish_status сообщает результат по каждому аккаунту по мере его завершения: аккаунт, опубликовано или не удалось, ссылку на живой пост при успехе и причину при неудаче. Ваш клиент опрашивает его, пока не будут перечислены все аккаунты.

Повторный запуск того же срабатывания не публикует дважды.

Планирование

arm_schedule ставит триггер на расписание. Ему нужны идентификатор триггера, время первого срабатывания (fire_at, дата и время по ISO 8601) и recurrence:

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

План словами описывает первое срабатывание, ритм и часовой пояс до того, как что-либо будет поставлено на расписание. Если процесс не опубликован, arm_schedule отказывает и просит сначала выполнить publish_workflow.

disarm_schedule убирает расписание триггера, и он перестаёт срабатывать. Уже вышедшие посты это не затрагивает, а поставить триггер на расписание снова можно в любой момент.

Разобранные примеры

• Один пост во все аккаунты публикует сразу.
• Пост каждую неделю ставит еженедельное расписание.