Документация

How it works

5-минутное введение в архитектуру SUMMING. Если вы только что подключили первого провайдера и не до конца понимаете, почему «оно работает» — это именно та страниц

5-минутное введение в архитектуру SUMMING. Если вы только что подключили первого провайдера и не до конца понимаете, почему «оно работает» — это именно та страница.

Слои сверху-вниз

┌────────────────────────────────────────────────────────┐
│  You + your team                                       │
└────────────────────────────────────────────────────────┘
           │
           ↓  (web-UI / API)
┌────────────────────────────────────────────────────────┐
│  SUMMING control plane                                 │
│                                                         │
│  Space → Agent identity → workload binding             │
│                             ├─ visual Process → Graph  │
│                             └─ native Program → Events │
│                                              ↓         │
│                                        Run instance    │
└────────────────────────────────────────────────────────┘
           │
           ↓  (HTTP / webhooks / SMTP / API)
┌────────────────────────────────────────────────────────┐
│  External providers                                    │
│  Bitrix24 · amoCRM · ЮKassa · 1С · Telegram · VK · ... │
└────────────────────────────────────────────────────────┘

Слова и что они значат

Space — это ваша tenant-изоляция. Один space = одна команда / одна компания. У space'а свои секреты, свои OAuth-подключения, свои агенты. Ничто между space'ами не пересекается. При регистрации SUMMING создаёт вам первый space (см. first-login wizard).

Agent — устойчивая продуктовая identity в вашем space'е. У каждого агента:

имя и goal (human-readable цель)
роль (operations / sales / support / custom…)
один primary workload: визуальный Process или нативная Program
KPI'и, которые автосчитаются по его runs'ам
optional limits: cost cap / working hours / rate limits

Process — DAG-граф из нод: trigger-нода → processing-ноды → output-нода. Версионируется через revisions (git-like: каждая правка — новая revision; deploy revision → она становится активной). Можно откатиться на предыдущую revision одной кнопкой.

Program — versioned manifest модулей, событий, state и capabilities. Program Runtime разворачивается отдельно от текущего API и Graph Runtime, имеет собственные PostgreSQL/Redis и не получает browser cookies или plaintext secrets. На публичном UI это всё тот же Agent, без переключателя engine version.

Run — одно исполнение процесса на конкретном trigger'е: кто-то заполнил форму в Tilda → webhook прилетел → start run → run проходит через ноды → завершается (done / failed / cancelled).

Trace — детализированный лог всех событий внутри run'а: что пришло на trigger, что передалось между нодами, сколько занял каждый шаг, что LLM ответил, какой status-code вернул Bitrix24, сколько стоило в центах. /runs/<id> страница в UI — это trace viewer.

Жизненный цикл trigger → action

Возьмём пример: Tilda-форма → amoCRM-лид.

Подключение: вы создали agent + process в SUMMING. Process содержит ноды:
```
webhook.trigger → ai.classify → amocrm.lead.create
```
Publish: нажали Publish — SUMMING сохранила текущую revision как deployment и выдала webhook-URL.
Tilda hookup: вы скопировали URL в настройки формы Tilda.
User fills the form: Tilda POST'ит payload на webhook-URL.
SUMMING валидирует: webhook.trigger нода проверяет соответствие подписи (HMAC / query-token / без валидации — зависит от preset'а).
Run создаётся: SUMMING материализует новый run, состояние queued. Вы уже видите его в /runs.
Scheduler подхватывает: backend scheduler берёт queued runs и отправляет в step-worker.
Step-by-step execution:
- webhook.trigger → output = body формы
- ai.classify → input = form body, output = "hot" / "warm" / "cold"
- amocrm.lead.create → input = form body + classify label, output = amocrm lead_id
Trace пишется: каждый шаг сохраняет input + output + timing + cost (если есть). Видно в /runs/<id>/traces.
Run completes: финальный статус done. KPI обновляется (runs_today++, cost_today += ai.classify cost).

Всё это — в пределах 1-2 секунд для простого workflow'а. Долгие шаги (LLM-call + Bitrix-call + delay) разбиваются на отдельные фоновые шаги; run состояние running пока все не сойдутся.

Что НЕ делает SUMMING

Не хранит бизнес-данных. Ваши заказы, клиенты, сделки — в вашей CRM / 1С / DB. SUMMING проводит данные между ними, но сама не репозиторий.
Не проксирует платежи. ЮKassa / T-Kassa / ваш эквайринг общаются напрямую с клиентом; SUMMING получает только metadata-события (succeeded / failed / refunded).
Не контролирует ваши accounts. Ваш Bitrix / amoCRM / Google workspace живут где жили. SUMMING ходит в них через вами же созданные integrations.

Что SUMMING делает хорошо

Orchestration: durable journal, retry-с-backoff'ом и idempotency keys. Для внешних writes неопределённый результат не маскируется: он требует reconciliation, а не обещания exactly-once.
Observability: каждый шаг сохраняется trace'ом, ошибки летят в Sentry (если вы его настроили — см. deploy-runbook §12 в репо), KPI auto-computed.
Human-in-the-loop: любой шаг можно гейтить approval'ом («не списывай > 10000₽ без подтверждения owner'а»).
Governance: RBAC (owner / admin / member), soft-delete под 152-ФЗ, audit trail всех действий, рaeversion-based rollback.

Где читать дальше

Agents & Processes — деталь по версионированию процессов и template-resolver'у
Runs & Traces — lifecycle state-machine и retry policies
Secrets — AES-256 encryption model + OAuth refresh

Слои сверху-вниз#

Слова и что они значат#

Жизненный цикл trigger → action#

Что НЕ делает SUMMING#