Перейти к содержанию

Жизненный цикл Session

Session — один акт поставки: один поставщик, один период, один комплект файлов, проведённый через пайплайн обработки. Она связывает DataContract, Transformer и Entity своего Project, загруженные файлы и контекст сессии.

Стейт-машина

CREATED → UPLOADED → PARSED → TRANSFORMED → VALIDATED → CONFIRMED → APPROVED → EXPORTED
Стадия Что происходит
Parse Сырые файлы становятся Parquet через Python-native парсеры.
Transform SQLGlot компилирует маппинги; DuckDB их выполняет.
Validate Правила entity выполняются как DuckDB-запросы нарушений.
Reconcile Правила проекта выполняются как межсущностные JOIN'ы.
Confirm / Approve Человек подтверждает (одинарное или двойное одобрение).
Export Производится пакет в настроенном формате.

Массовые данные никогда не грузятся в память Python — Python генерирует SQL, DuckDB делает работу над Parquet в объектном хранилище.

Health vs стадия

У сессии есть и стадия (где она в пайплайне), и health (блокирует ли что-то — например ERROR-нарушения). View сессий отслеживает оба, чтобы с одного взгляда видеть, какие поставки требуют внимания.

Типы ошибок — format, content, system

Когда стадия падает, Expecto классифицирует почему — чтобы сразу было видно, чья это проблема и что делать дальше:

Класс Смысл Типичная причина Кто чинит
Format Доставленный файл нарушает согласованный формат (схему source) — структуру или синтаксис значений. Отсутствующие/лишние колонки, неверный разделитель, дата 01.12.2025 вместо YYYY-MM-DD, нечисловая сумма, значение вне допустимого набора. Data provider — исправить файл и прислать заново. Пока это не сделано, содержательные проверки не запускаются.
Content Формат корректен, но данные нарушают правило валидации или бизнес-правило. Дебет/кредит не сходятся, счёт без маппинга, аномалия арендного дохода. Разбирается как содержимое поставки — внимания требуют сами цифры/маппинги.
System Expecto не смог выполнить шаг — сбой конфигурации или платформы. Отсутствующий справочник, сломанное выражение маппинга, правило, чьё выполнение падает. Организация или Expecto — от провайдера ничего не требуется; повторная отправка того же файла не поможет.
Not applicable Правило не смогло выполниться, потому что необязательная source не доставлена. Правило по НДС, когда необязательный VAT-файл отсутствует. Никто — это ожидаемо, а не ошибка. См. Необязательные sources.

Каждая сессия несёт агрегированный доминирующий класс ошибки (приоритет: system → format → content → not applicable), показываемый бейджем в шапке сессии — и в админском интерфейсе, и в портале провайдера. Степпер пайплайна помечает каждую стадию её итогом; format-ошибки блокируют содержательные стадии, а system-сбой останавливает пайплайн (fail-fast), вместо того чтобы гнать последующие стадии по данным, которые так и не удалось получить.

Сессия с технической ошибкой: бейдж рядом с заголовком, степпер с проваленной стадией Verified и само правило-источник ошибки ниже

Ошибки трансформации простым языком

Трансформация чаще всего падает, когда значение не подходит под целевой тип — например нечисловая строка в колонке суммы. Вместо обрезанной ошибки БД стадия Transform называет точные колонку, значение, целевой тип и строку(и) источника (например Column "amount": value "abc" is not a valid number) и подсвечивает проблемную ячейку. Сырой технический детал остаётся доступен под раскрывающимся блоком для тех, кому он нужен.

То же касается валидации и бизнес-правил: правило, которое не смогло выполниться — неизвестная колонка или таблица, неудачная конвертация, нехватка памяти — показывает понятное сообщение (например The rule references an unknown table "vat_options") с сырой ошибкой движка в один клик, а не голое исключение БД.

Контентная ошибка: бейдж Content, помеченная стадия и подсвеченная проблемная ячейка в таблице данных рядом с её нарушением

Отслеживание по файлам и по трансформерам

Внутри сессии у каждого исходного файла и каждого трансформера свой статус и свой Parquet-результат, так что можно инспектировать результаты парсинга по файлам и результаты transform/validate по трансформерам.

Необязательные sources

Source у DataContract может быть необязательной. Когда необязательная source не доставлена, пайплайн не падает с ошибкой:

  • Transform — трансформер, у которого все входные роли — недоставленная необязательная source, фиксируется как SKIPPED (а не ERROR). Сессия считает пропущенный трансформер разрешённым, поэтому он не блокирует прогресс.
  • Validate — пропущенный трансформер проходит как checked с причиной missing_optional_source, а не ошибкой «нет трансформированных данных».
  • Export — пакет опускает отсутствующую необязательную source и фиксирует её под omissions в datapackage.json (зеркально в export_report сессии); каждая запись называет role и причину optional_not_delivered.

Отсутствие обязательной source остаётся жёсткой ошибкой на каждой стадии. Бизнес-правила, зависящие от недоставленной source, помечаются как неприменимые (not applicable), а не проваленные — см. Бизнес-правила.

Тайминги пайплайна

Воркспейс может записывать, сколько длится каждый прогон пайплайна. Owner или admin включает это в Настройках → Pipeline → Measure stage timings; по умолчанию выключено, и пока выключено — ничего не измеряется и не сохраняется.

Когда включено, каждый прогон фиксирует для каждой автоматической стадии (parse, transform, check, export) её длительность и время, прошедшее от запуска пайплайна до завершения стадии. Под каждым бейджем стадии в степпере статусов показана её длительность, а рядом — накопленное время от старта для непрерывной цепочки parse → check. Развёрнутая панель Full details добавляет сводку прогона: когда он начался, когда завершились автоматические стадии и суммарное машинное время.

Ручные стадии (uploaded, confirmed, approved) — действия человека, поэтому показываются как гейты без машинной длительности. Пока замер выключен, степпер не показывает подписей таймингов — ровно как раньше.

Журнал аудита

Активность сессии фиксируется как комментарии (только добавление) — типы COMMENT, INTERNAL_NOTE и STATUS_CHANGE — давая устойчивую историю, кто что и когда сделал.

Кто может создавать сессии

В зависимости от режима создания сессий в проекте, сессии могут создаваться вашей организацией, Data Provider'ом или и теми и другими.

Связанное