Test Protocol on the shared platform

Before you start

Open Applications. Click Sign in with Keycloak. This is the local development realm central-dev, not the enterprise identity provider and not Keycloak’s master administration console.

Use the existing Demo password from the private protocol-bpmn/central-access.txt on your local machine. Passwords are intentionally not published on this guide. The Keycloak administrator account and native CIB developer account are separate; neither is needed for the main walkthrough.

Testing several people: use separate browser profiles, or complete the sign-out steps below between roles. Separate tabs in one browser profile share login state. “Sign out” currently invalidates every platform session for that pilot user, including other browsers. Save any edits first.

1. Author: create a Protocol

1. Sign into the catalog as author. Under Protocol, click Open application →. Its stable link is /protocol.
2. If Protocol shows a login screen, click Войти через Keycloak. Because you already signed into Keycloak, you should return without entering your password again. A product may still require this initial sign-in click to create its own secure session.
3. On Протоколы, confirm the selected division is Пилот КТ. Click Создать протокол.
4. Fill Название with a unique title, for example BA TEST — Shared platform — your initials.
5. For Блок, open — Не выбрана — and select Рабочие совещания (Совещания П.).
6. For Категория, select Совещание пилота. Confirm Дивизион-владелец shows Пилот КТ. The existing block supplies the chairman; you do not need to add a substitute for the main test.
7. Enter a short description under Повестка. Other optional fields can remain unchanged. Click Сохранить once and wait for the detail page.
8. Expect business status Создание and Процесс BPMN · Выполняется. The current task is Подготовить и отправить. Copy the page URL and the Протокол / Business Key and Процесс values.

Create the business record in Protocol first. Do not use the engine’s generic “Start process” action for this business workflow: it would bypass creation of the corresponding Protocol record.

2. Author: submit from the central Task Hub

1. Open Central Task Hub. Click Sign in with Keycloak → if shown. Confirm the top-left account is author.
2. In Search tasks, enter your unique Protocol title. Open Подготовить и отправить for that title. Do not complete unrelated existing tasks.
3. Under Choose approvers, select Первый Согласующий and Второй Согласующий. Hold Ctrl on Windows / Cmd on macOS when selecting the second name.
4. Optionally enter a Comment. Click Send for approval once. Wait until the selected task leaves your inbox; use ↻ Refresh if necessary.
5. Return to the saved Protocol page and reload. Expect На подписании. Its BPMN banner should list Подписать протокол and two Согласовать / отклонить tasks. Both reviewers initially show в ожидании.

The actual route is Task Hub → task API → Protocol business API → CIB seven → Java delegate → integration service → Protocol callback. The existing durable command and process mapping protect the business operation from duplicate execution.

3. First reviewer: approve

1. If sharing one browser profile, click Sign out in the Task Hub. Keycloak then asks Do you want to log out?; click Logout. Complete this step before attempting a different username.
2. Click Sign in with Keycloak → and sign in as approver. Confirm the account name before continuing.
3. Search for the same title. Open Согласовать / отклонить. The task displays the actual Protocol details and participants.
4. Enter an optional comment. Click Approve protocol. Wait until the task leaves the filtered inbox.
5. Leave reviewer’s task untouched for the main test. It will demonstrate the existing chairman rule in the next step.

Optional rejection test: click Request changes with an empty comment first; the UI requires a comment. Add one and retry. In this existing Protocol business model, rejection records the review decision and permits a later approval; it does not automatically return the entire process to the author. The automated suite verified that path.

4. Chairman: sign

1. Sign out fully, including Keycloak’s Logout confirmation. Sign into the Task Hub as chairman.
2. Search for the same title and open Подписать протокол.
3. Confirm Первый Согласующий · agreement approved and Второй Согласующий · agreement pending.
4. Click Sign protocol once. Wait for the task to disappear.

This is the current Protocol rule: the chairman can sign while reviews are pending or declined. Signing closes the approval stage and cancels remaining BPMN review tasks. The platform migration deliberately preserves this behavior. Requiring every reviewer’s approval would be a separate business-rule/process change.

5. Verify completion in Protocol

1. Open the saved Protocol URL. If asked to sign in again, click Войти через Keycloak. The currently signed-in chairman can view the record. Alternatively, sign out and return as author.
2. Confirm business status Подписан and engine status Процесс BPMN · Завершён. The business key and instance ID must match the values saved at creation.
3. Confirm there is no current-task list in the completed BPMN banner. История изменений shows the recorded business changes.
4. As reviewer, refresh the central inbox and search this title. The remaining review task must no longer be present.

The second reviewer may still appear as в ожидании in the saved business participant list. This is retained business data, not a still-running BPMN task. Check the BPMN state and inbox to distinguish them.

The existing Открыть CIB seven ↗ link opens the native engine tools for deeper inspection. They retain their separate developer login; product SSO does not automatically sign you into native engine administration. The main test can be completed using the Protocol banner and Task Hub without administrator access.

Additional acceptance checks

Developer steps, separately from BA testing

The developer maintains shared login, product grants, integration contracts and the deployment. The BA works in the product/BPMN and tests behavior. No CI/CD pipeline or embedded AI builder was added.

1. Read protocol-bpmn/PLATFORM.md locally. The auth, task API and integration services are separate containers. Protocol continues to have its existing NextJS frontend and NestJS backend. New products can use the full-stack nextjs-starter.
2. Before changing an integration, define its allowed caller, operation, input/output, authorization, timeout and retry/idempotency behavior. Implement fixed destinations in platform/integrations.mjs; do not introduce a generic “call any URL with any token” route.
3. For a new BA product, copy the NextJS starter and register its own slug/origin, OIDC client, database credentials, service keys, product grants and process operations. Creating a NextJS folder alone does not grant platform access.
4. Upload this project’s platform change set from the local parent folder:

python protocol-bpmn/tools/upload-platform.py

On the VM, use all three Compose files:

cd /opt/protocol-bpmn
sudo docker compose -f compose.yaml -f compose.central.yaml -f compose.platform.yaml build
sudo docker compose -f compose.yaml -f compose.central.yaml -f compose.platform.yaml up -d
python3 tools/setup-platform.py model
python3 tools/verify-platform.py

Use --restart on the verification script only when deliberately testing persistence outside manual testing. It restarts this Protocol engine and shared auth/task/integration services. The suite creates synthetic records, temporarily revokes/restores the pilot author’s Protocol grant and signs the test author out across products.

Earlier bare docker compose up and legacy bootstrap/test commands omit the platform overlay or rely on the now-disabled dev login. Use the commands above for this deployment.

What was tested

20 automated checks passed, including live OIDC/PKCE login, SSO, host-bound sessions, disabled legacy login, business/task permissions, CSRF and Origin checks, actor spoofing, attachment handling, duplicate-submit protection, real delegate callbacks, review/sign/substitute rules, token refresh, product grant revocation, service caller restrictions, database isolation and restart persistence. The independent NextJS starter completed its own real BPMN review.

The browser walkthrough also passed: a new Protocol was created, submitted, approved and signed through the exact screens shown above. Its final business and engine states were checked in the UI.

Automated test evidence · Manual walkthrough evidence

This remains a single-VM development platform. Central authorization currently governs product access; Protocol owns record-specific permissions. Enterprise Keycloak, a permission-management UI, arbitrary custom task-form hosting and high availability are not implemented. The older comparison environments remain separate.