n8n Google Calendar: перевірка доступності перед бронюванням зустрічі
Створіть крок перевірки доступності n8n Google Calendar, який блокує подвійне бронювання та створює події лише коли час вільний.
Перевірено за наведеними джерелами .
Що ви створите: вправа з перевірки доступності
Це редакційна вправа, а не опублікований кейс: практична побудова, яку ви можете самостійно протестувати у власному інстансі n8n. Мета — невеликий, але реальний крок перевірки доступності n8n Google Calendar: workflow, який приймає запит на бронювання, перевіряє, чи дійсно вільний запитаний часовий слот, і створює подію в календарі лише тоді, коли він вільний. Вузол Google Calendar у n8n містить окрему операцію Calendar Availability, створену спеціально для перевірки, чи вільний часовий слот, перш ніж виконається будь-яка дія бронювання.
Перш ніж починати, вам знадобиться запущений інстанс n8n, уже підключені облікові дані Google Calendar у n8n та реальний календар, на якому дозволено тестувати, оскільки операція Availability вимагає вибору конкретного календаря для перевірки як параметра конфігурації. Ми б радили спершу оформити це як окремий невеликий workflow, відокремлений від будь-якої форми бронювання чи чат-бота, щоб результат перевірки доступності був видимий сам по собі, перш ніж щось інше під'єднається.
Кожен запуск визначають три вхідні дані: запитаний час початку, запитаний час завершення та ID календаря для перевірки. Задайте їх явно для цієї вправи, а не покладайтесь на те, що саме надішле тригер, оскільки явні, фіксовані вхідні дані роблять тест відтворюваним на одному й тому ж календарі щоразу.
- Запитаний час початку
- Запитаний час завершення
- ID календаря для перевірки
- Часовий пояс для обох значень часу
Sources: Google Calendar | Nodes | n8n Docs, Calendar operations | Nodes | n8n Docs
Покроково: перевірка доступності n8n Google Calendar
Коли вхідні дані готові, сам workflow проходить чотири етапи, показані нижче.
Перший етап — тригер, що фіксує запит на бронювання: вузол Webhook або Form, який отримує час початку, час завершення та ID календаря, а потім вузол Edit Fields для нормалізації їх у послідовний формат для наступного кроку.
Другий етап виконує сам крок перевірки доступності n8n Google Calendar: операцію Calendar Availability, спрямовану на обраний календар, з параметром Output Format, установленим на Availability. З таким налаштуванням вузол повертає інформацію про те, чи перетинаються існуючі події із запитаним слотом, що фактично є способом перевірити чиюсь доступність у Google Calendar зсередини автоматизованого потоку, а не вручну відкриваючи застосунок календаря. Під капотом документація n8n описує цю операцію як виклик власного free/busy-запиту Google, який повідомляє дані про зайнятість/вільність для набору календарів.
Третій етап розгалужує цей результат за допомогою вузла IF або Switch — стандартного способу n8n розділити один workflow на кілька шляхів залежно від умови.
Четвертий етап діє відповідно до гілки: на вільному шляху операція Event Create додає бронювання, знову ж після вибору цільового календаря як параметра. На зайнятому шляху не піддавайтеся спокусі просто завершити workflow; натомість надішліть заявнику повідомлення або альтернативний час, замість того щоб дати запиту мовчки зникнути.
Sources: Google Calendar | Nodes | n8n Docs, Calendar operations | Nodes | n8n Docs, Event operations | Nodes | n8n Docs, API Reference | Google Calendar | Google for Developers, Split with conditionals | Build | n8n Docs
Обмеження: часові пояси, формат виводу та стан гонитви
Кілька обмежень визначають, чи поводитиметься ця вправа передбачувано. По-перше, часові пояси: встановіть явний часовий пояс як для запитаного часу початку, так і для часу завершення, а не покладайтеся на вирази вузла за замовчуванням на основі $now, щоб один і той самий тест давав один і той самий результат щоразу під час запуску.
По-друге, важливий формат виводу, обраний для операції Availability. З Output Format, установленим на Availability, вузол повідомляє простий результат перетину, а не базовий список подій, що відповідає на питання, як показати доступність у даних Google Calendar, не розкриваючи повні деталі подій тому, що запустило перевірку. Для цієї вправи такого простого результату «так чи ні» достатньо, оскільки наступному кроку потрібно лише вирішити, яку гілку обрати.
По-третє, стани гонитви: один навчальний матеріал спільноти n8n про побудову потоків бронювання радить перевіряти доступність безпосередньо перед створенням події, тримаючи ці два кроки якомога ближче один до одного, щоб звузити вікно, у якому два запити могли б одночасно бачити той самий слот як вільний. Ми б розглядали вільний результат цієї перевірки як відповідь у конкретний момент часу, а не як блокування слота, тож продакшн-версія цього workflow все одно потребує власного механізму захисту від подвійного бронювання; ця рекомендація походить із власного запропонованого дизайну workflow в блозі постачальника, а не з перевіреного чи виміряного результату.
- Явний часовий пояс для часу початку і завершення
- Output Format, установлений на Availability, для простого розгалуження так/ні
- Перевірка доступності виконується безпосередньо перед кроком створення події
Sources: Calendar operations | Nodes | n8n Docs, Publish technical n8n tutorial with full code examples and screenshots - DEV Community
Критерії завершення, усунення несправностей і запропоноване рішення
Завершення цієї вправи має два тести: запит на слот, який уже зайнятий, має бути заблоковано, а не заброньовано, а запит на справді вільний слот має призвести до бронювання зустрічі. Це друге очікування відповідає плану тестування, який ставить перед собою навчальний матеріал спільноти про workflow бронювання в n8n, хоча там описано запропонований тест, а не результат, який хтось незалежно перевірив.
Поширені збої, на які варто звернути увагу: відсутній або неправильний ID календаря в операції Availability чи Event Create, оскільки обидві вимагають цей параметр явно; помилка API Google Calendar, яка взагалі не перехоплюється; і зайнята гілка, що пропускає перевірку нижче щодо надсилання якоїсь відповіді заявнику. Той самий навчальний матеріал спільноти пропонує побудувати окремий workflow обробки помилок n8n, щоб перехоплювати такі збої, як невдалий виклик API календаря. Ми вважаємо, що це варто робити навіть для навчальної вправи, оскільки це різниця між workflow, що гучно падає, і тим, що падає непомітно.
Запропоноване рішення в загальних рисах: вузол тригера, що фіксує час початку, завершення, ID календаря і часовий пояс; операція Calendar Availability з Output Format, установленим на Availability; вузол IF, що розгалужує за результатом; операція Event Create на вільному шляху; і крок сповіщення на зайнятому шляху, підкріплений workflow обробки помилок для всього, з чим не впорається вузол Calendar. Побудуйте це, запустіть обидва тестові випадки на власному календарі, і ви охопите суть справжнього кроку перевірки доступності n8n Google Calendar, а не демо «тригер-дія».
Sources: Publish technical n8n tutorial with full code examples and screenshots - DEV Community, Calendar operations | Nodes | n8n Docs, Event operations | Nodes | n8n Docs
