Назначение: Архитектура. Продукт: ShariX Open · Общий компонент.

Для кого: Разработчик · Интегратор · Оператор развёртывания · Нейросеть.

Темы: Обработчики → Blockly · Обработчики → Runtime.

Страница показывает, где искать алгоритм обработчика, как получить исполняемый Python и какие проверки нужны перед передачей изменения. Runtime исполняет выбранный Python-файл; Blockly — редактируемый источник алгоритма, а не интерпретируемая при обработке заявки программа.

Признак shared не определяет лицензию. У общего runtime есть открытый контракт, но подключаемый модуль может оставаться закрытым. Его внутренние алгоритмы документируют в intrawiki; публично обозначают только имя и границу. Подробности — владение моделями.

Для open_st_request_new используются:

• handlers_examples/catalog.py — идентичность, тип Ticket, рабочий статус и capabilities.
• handlers_examples/generated_handler_blocks/open_st_request_new.json — Blockly workspace.
• handlers_examples/handlers/open_st_request_new.py — встроенный runnable Python.
• handlers_examples/generated_handlers/open_st_request_new.py — поставляемая копия результата генерации.
• handlers_examples/generated_handler_blocks/.provenance.json — сведения о происхождении встроенных версий.
• handlers_backend/ticket_codegen_contract.json — шаблоны и хеши исходников генераторов.

Это расположение встроенной пары ShariX Open, а не универсальная структура всех contributions. Для module-owned handler берут пути из contribution и provenance и проверяют их согласованность с владельцем.

• Builtin: поставляемая Git-версия. Для ShariX Open её каталоги задаёт handlers_examples/runtime_provider.py.
• Локальная версия: отдельная версия в conf-real/handlers/local_versions с workspace, Python и сведениями о происхождении.
• Выбранная версия: версия, указанная в installation-local конфигурации conf-real/handlers/handler_runtime.json.

Наличие правильной builtin-пары не доказывает, что на сервере запущена именно она. При диагностике выясняют выбор версии и фактический файл. Конфигурацию и секреты не копируют в Wiki или отчёт целиком.

1. Найти текущий handler в каталоге и определить владельца его исходников.
2. Прочитать workspace, полученный Python и вызываемые runtime/API-операции. Установить условия, действия и отказы.
3. Если работающая ветвь Python отсутствует в Blockly, сначала отразить её в workspace. При необходимости добавить узкий переиспользуемый блок с ясным контрактом.
4. Обновить генераторы/шаблоны, когда меняется сам набор поддержанных блоков. Не прятать новый процесс в блок «выполнить произвольный Python».
5. Получить Python из workspace и сравнить его с поставляемыми файлами.
6. Согласовать provenance, contribution-пути, toolbox/help, переводы и поведенческие проверки затронутой части.
7. Проверить разрешённые операции и события с учётом выбранной runtime-версии.
8. Обновить текст сценария и BPMN по тем же исходникам; передать человеку патч и полный сценарий применения.

Ручная правка generated Python и замена сохранённых хешей не восстанавливают соответствие. Неизвестный блок или изменившийся генератор должны дать явную ошибку. Перегенерация неполной модели с потерей работающей функции также не является исправлением.

Из корня checkout ShariX Open с установленными исходниками:

./venv/bin/python handlers_backend/tools/check_canonical_ticket_codegen.py \
  --workspace-dir handlers_examples/generated_handler_blocks \
  --python-dir handlers_examples/handlers \
  --generated-dir handlers_examples/generated_handlers \
  --contract handlers_backend/ticket_codegen_contract.json \
  --project-root .

В этом режиме инструмент повторно получает Python и сравнивает файлы; он не запускает обработчики, не обращается к БД и не использует сеть. Параметр –write здесь намеренно не используется: изменение файлов генерации — отдельный авторский шаг после проверки workspace.

Для настроенной Django-установки существует дополнительная проверка:

./venv/bin/python manage.py check_handler_blockly_sync

Она проверяет materialized contribution manifest и builtin provenance. Отсутствующий или устаревший manifest — конкретная причина отказа, а не основание пропустить проверку. Подготовка contributions выполняется штатной процедурой; эта команда не доказывает исправность XMPP или успех пользовательского процесса.

• Кто инициирует действие и с каким объектом работает.
• Какие условия выбирают ветвь.
• Какой API вызывается и какое право/capability требуется.
• Где сохраняется бизнес-состояние.
• Когда действует человек или внешняя система.
• Какое событие возвращается после изменения.
• Какая настройка определяет таймер или повтор.
• Что происходит при отказе, повторном событии и завершении.

Для процесса сначала используют BPMN. Сверяют не только workspace, но и Python, операции runtime, API/ACL и внешний интерфейс. Значение таймера на сервере не угадывают по имени переменной. Просмотрщик Wiki не исполняет процесс; схема описательная.

• Генерация совпала: workspace воспроизвёл данный Python.
• Происхождение проверено: сведения о файлах, генераторе и владельце согласованы.
• Процесс запущен: служба стартовала с нужной версией.
• Handler готов: подтверждены нужные runtime/XMPP-признаки.
• Сценарий выполнен: разрешённое действие привело к ожидаемому сохранённому и видимому результату.

Эти результаты не подменяют друг друга. Бизнес-состояние изменяет владелец через предусмотренную операцию; handler не записывает произвольный статус в обход прав. После публикации shared-изменения оповещают ответственного Platform для его проверки и принятия по intrawiki; публичный сценарий не запускает обновление другого продукта.

Подробности: приёмка, runtime health, ST_REQUEST.

Опубликованные встроенные обработчики разобраны по одному: алгоритм, внешние участники, таймеры и границы доменных действий.

CLOSED — терминальная стадия; отдельного встроенного open_st_request_closed в текущем каталоге нет. Историческое имя open_st_request_dublicate не является второй доступной реализацией DUPLICATE.

Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение версии, конфигурации или выполнения сценария на сервере.

• sharix-open-webapp-base: CODING_POLICY.md.
• sharix-open-handlers-examples: catalog.py.
• sharix-open-handlers-examples: README.md.
• sharix-open-handlers-backend: README.md.
• sharix-open-handlers-backend: ticket_blockly_codegen.py.
• sharix-open-handlers-backend: tools/check_canonical_ticket_codegen.py.
• sharix-open-webservice-running: views/blockly.py.
• sharix-open-handlers-backend: handler_versions.py.
• sharix-open-handlers-backend: blockly_provenance.py.
• sharix-open-handlers-backend: runtime_provider.py.
• sharix-open-backend: lib/handler_contributions.py.
• sharix-open-webservice-running: management/commands/check_handler_blockly_sync.py.
• sharix-open-handlers-examples: runtime_provider.py.