Динамические сценарии

Динамический сценарий — мощный инструмент для автоматизации коммуникаций, который вы можете реализовать двумя способами: заказать разработку у нашей команды или создать его самостоятельно, используя в

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

1. Логическая схема сценария

Необходимо предоставить детальную диаграмму, описывающую логику работы динамического сценария.

  • Формат: Схема может быть выполнена в любом общепринятом инструменте для проектирования (например, Miro, Draw.io, Visio) и экспортирована в доступном формате (PDF, PNG, SVG).

  • Содержание: Схема должна наглядно отражать все ветвления диалога, точки принятия решений, вызовы API и переходы между состояниями.

Пример схемы для сценария "Уточнение статуса заказа" должен включать шаги по идентификации пользователя, запросу статуса через API и обработке различных ответов (заказ найден, не найден, в пути, доставлен).

2. Спецификация API

Требуется предоставить исчерпывающую документацию по всем методам API, задействованным в сценарии.

  • Доступ: Необходимо указать базовый URL (API URL) и предоставить токен авторизации (API Key) для тестового окружения.

  • Описание методов: Для каждого метода должна быть предоставлена следующая информация:

    • Назначение: Краткое описание бизнес-задачи, которую решает метод (например, "Бронирование занятия").

    • HTTP-метод и эндпоинт: Например, POST /api/v1/bookings.

    • Входные параметры (Request): Описание полей в теле запроса или параметрах URL, включая их тип данных и обязательность (например, lesson_id: integer).

    • Выходные данные (Response): Описание структуры успешного ответа и возможных ошибок с кодами и текстами сообщений.

Пример описания метода:

Метод: Проверка доступных слотов для записи

  • Endpoint: GET /api/v1/teachers/{teacher_id}/slots

  • Входные данные:

    • teacher_id (в пути) - integer, ID преподавателя.

  • Выходные данные (успех, 200 OK):

    • Массив объектов, где каждый объект содержит:

      • slot_id - integer, ID слота.

      • datetime - string, дата и время в формате ISO 8601.

  • Выходные данные (ошибка, 404 Not Found):

    • {"error": "Teacher not found"}

3. Тестовое окружение и данные

Для отладки и верификации сценария необходимо обеспечить доступ к API в тестовой среде.

  • Стабильность: API должен быть развернут в стабильном тестовом окружении (staging) и быть доступным для запросов.

  • Тестовые данные: Необходимо предоставить набор тестовых данных, покрывающий все ключевые ветки сценария.

  • Репрезентативность: Формат тестовых данных должен полностью соответствовать формату реальных (production) данных. Если существуют отличия, их необходимо явно описать.

    • Пример: "Тестовый ID заказа имеет формат test-12345, в то время как реальный — ORD-12345-XYZ."

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

    • Номер телефона или email.

    • ID пользователя в системе.

    • ID заказов, соответствующих разным статусам.

Последнее обновление