Сценарий описывает POST /dbsynce/api/v1/orders/ в ShariX Open: от получения запроса до сохранённого заказа, HTTP-ответа и событий после commit. Это описание проверенного исходного кода, а не отчёт о выполнении запроса на рабочем сервере.
Где находится операция
Корневой core/urls.py подключает dbsynce.urls по префиксу dbsynce/. При включённом DBSYNCE_OPEN_API_ENABLED регистрируются маршруты apiviews/open_api.py. POST принимает OpenOrderListCreateAPIView, создание выполняет lib/open_order_api.py:create_order_from_payload.
OpenAPIBaseView использует IsAuthenticated | HasAPIKey. Но предметная операция получает request.user и проверяет участников и доступные объекты. Пропуск по API key не означает, что вместо actor можно передать произвольного пользователя или создать заказ от любой организации. Для интеграции сначала определяют поддержанный контекст пользователя и предметные права.
Для проверки нужен предназначенный тестовый контекст: доступный тариф, компания/предложение, пользователь с подходящим основанием и допустимые данные получателя. Не подбирать чужие ID ради прохождения валидации.
Что выбрать до отправки
Условие
Поведение текущей операции
creation_mode=draft
Создать черновик с начальным Ticket TEMPLATE.
creation_mode=place
Разместить заказ с начальным Ticket BOOKED; затем возможно действие назначения.
Режим отсутствует
normalize_order_creation_mode выбирает place. Не считать отсутствующее поле командой сохранения черновика.
Категория subscription
Операция принудительно выбирает place.
self_order=true
Проверяются доступность self-order и предложение исполнителя текущего пользователя. Одновременный корпоративный заказ отклоняется.
Получатель услуги может отличаться от создателя. Операция отдельно получает receiver и его снимок receiver_name/receiver_phone. Состав обязательных полей зависит от выбранного предложения и его правил; произвольный универсальный payload не заменяет доступные клиенту options.
Сохранение в одной транзакции
Нормализуются режим и self-order, выбираются доступные связанные объекты. Проверяются корпоративный контекст, получатель, время, длительность, количество и маршрут.
Создаётся Orders. pk назначает БД; приложение не вычисляет его как максимальный ID плюс один.
create_ticket_order создаёт SERVICE_REQUEST Ticket. Заказ сохраняет ссылку ticket_status и связанные вычисленные значения.
Вызывается initialize_order_execution через backend-порт. Если runtime или политика не настроены, этапов может не быть; вызов сам по себе не доказывает создания плана.
Если режим place и указан provider, выполняется ACTION_ASSIGN_CREATED. Неуспешный результат добавляется в warnings. Созданный заказ при этом может остаться сохранённым.
Планируется мобильное событие order.created или order.placed. Сетевые callbacks, запланированные через on_commit, относятся к следующей границе.
create_order_from_payload помечена transaction.atomic. Исключение внутри неё до commit отменяет её записи. Неуспешный результат назначения, обработанный как warning, не равен такому исключению.
BPMN: границы транзакции и ответа
Описательная схема isExecutable=false. Она показывает проверенный API-путь и отдельно события после commit. Схема не исполняет заказ и не заменяет Blockly последующих обработчиков.
После возврата из операции view получает snapshot по созданному order.pk и формирует ответ:
HTTP-код 201;
поле success;
поле message;
поле warnings;
поле order.
Нужно сохранить ID возвращённого заказа и прочитать warnings: success=true означает успех создания, а не безусловный успех назначения и всех внешних доставок.
Пример трактовки: если заказ создан, но предложение исполнителя не удалось назначить, клиент показывает созданный заказ и причину из warnings. Он не должен отправлять ещё один POST только ради повторной попытки назначения: это уже другое действие над существующим заказом.
Получение snapshot и сериализация ответа выполняются после возврата из функции создания. Поэтому ошибка подготовки HTTP-ответа также не доказывает, что заказ не был сохранён. Эту границу учитывают при восстановлении после таймаута/ошибки.
События после commit
Ticket-сигналы планируют ticket.changed; при каноническом переходе предыдущему обработчику также передаётся ticket.moved. Обработчик получает сигнал и сверяет сохранённое состояние. schedule_order_mobile_event предпринимает доставку мобильного события после commit.
Атомарность БД не гарантирует однократную доставку сети. Если данные уже committed, транспортная ошибка не откатывает их автоматически. Отдельно подтверждают:
создание заказа;
доставку XMPP;
получение уведомления мобильным клиентом.
Это три отдельных свидетельства.
Отказы и неизвестный результат
Ситуация
Что зафиксировано в коде / что делать
PermissionDenied из создания
View возвращает 403 с success=false и message.
Django ValidationError из создания
View возвращает 400 с success=false и errors.
Неизвестный creation_mode
Нормализация бросает ValueError; эта view явно его не перехватывает. Нельзя обещать готовый ответ 400 — это известное ограничение.
Таймаут, обрыв или ошибка после сохранения
Сначала установить, создан ли заказ. Повтор POST может создать ещё один.
В изученном клиентском POST не найден отдельный контракт idempotency key. Сначала проверить доступный пользователю список/историю и контекст операции; если исход нельзя установить однозначно — передать его на разбор. Последний ID в общей таблице не является доказательством результата именно этого запроса.
HTML-форма проверяется отдельно
sharix_admin.views.order.OrderCreateView.form_valid собирает заказ через OrderForm и собственный atomic-блок. Она использует общие ticket/action/execution primitives, но не вызывает целиком create_order_from_payload; у неё есть дополнительные шаги подписки и расширений.
Форма отдельно перехватывает неизвестный способ сохранения и возвращает ошибку формы. Это не исправляет API-ветку ValueError. При изменении общего правила нужно проверить оба входа, а не считать успешный API доказательством правильности формы.
Как принять изменение этой операции
На предназначенной установке проверить:
режимы draft и place;
сохранённые Orders и Ticket;
доступность заказа создавшему пользователю;
отказ для недоступных объектов или организации;
self-order;
предупреждение при отказе назначения;
отсутствие частичных записей при исключении до commit;
доставку события после commit;
неизвестный mode;
затронутый HTML-путь.
Не повторять создание на рабочих данных для проверки потери ответа. Такой случай воспроизводят в изолированном тестовом контексте. Общие критерии — приёмка изменений, структура данных — заказ и Ticket, локальное API-расхождение — Webservice Running.
Сценарий касается открытого API ShariX Open. Внутренние операции Platform и закрытых компонентов описываются в intrawiki; проверку shared-изменения другим продуктом передают его ответственному.
Исходники, сверенные 31.10.2026
Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение версии, данных или выполненного запроса на сервере.