DoculaDevelopersDezvoltatori
API 0.8.0 · BuildVersiune produs 0.33.0
Documentation navigationNavigare documentație

Guide 7 of 7Ghidul 7 din 7 · API 0.8.0

Provision a document type from scratch via APIConfigurează de la zero un tip de document prin API

Create a dedicated automation identity and deploy an intake, deterministic transforms, DOCX templates and their immutable versions without using the authenticated UI.Creează o identitate dedicată automatizării și implementează un intake, transformări deterministe, șabloane DOCX și versiunile lor imuabile fără interfața autentificată.

Derived from:Derivat din: docs/SECURITY.mdscripts/deploy-rca-demo.sh

Prepare one deployment service accountPregătește un singur cont de serviciu pentru deployment

An operator creates the fixed docula-automation identity with docula-api service-account prepare. The password is accepted only through SERVICE_ACCOUNT_PASSWORD_FILE: an absolute, operator-owned, mode-0400 regular file with no links or line breaks. Plaintext SERVICE_ACCOUNT_PASSWORD is rejected. The identity has only the engineer role, is immediately usable for API configuration, and has no special bypass. Preparing it again rotates the password and revokes every existing session; service-account seal replaces the password with an unknown random value and also revokes sessions.Un operator creează identitatea fixă docula-automation cu docula-api service-account prepare. Parola este acceptată numai prin SERVICE_ACCOUNT_PASSWORD_FILE: un fișier absolut, obișnuit, deținut de operator, cu modul 0400, fără legături sau sfârșituri de linie. Variabila plaintext SERVICE_ACCOUNT_PASSWORD este respinsă. Identitatea are numai rolul engineer, poate configura imediat API-ul și nu are nicio scurtătură specială. Repetarea pregătirii rotește parola și revocă toate sesiunile; service-account seal o înlocuiește cu o valoare aleatorie necunoscută și revocă sesiunile.

Automation logs in through the normal login operation. Keep the returned cookie in a temporary jar and the returned csrf_token in memory. Every mutation still sends the exact Origin, session cookie and X-CSRF-Token; canonical mutations also use stable Idempotency-Key values and draft updates echo strong ETag values through If-Match. This short-lived session token flow avoids browser token storage and gives audit records the fixed service identity. Never commit the password, cookie jar, CSRF token or a generated receipt.Automatizarea se autentifică prin operația normală login. Păstrează cookie-ul întors într-un jar temporar și csrf_token numai în memorie. Fiecare mutație trimite în continuare originea exactă, cookie-ul sesiunii și X-CSRF-Token; mutațiile canonice folosesc chei Idempotency-Key stabile, iar actualizările ciornelor reflectă ETag ferm prin If-Match. Acest flux cu token de sesiune scurt evită stocarea tokenurilor în browser și leagă auditul de identitatea fixă. Nu comite parola, jar-ul, tokenul CSRF sau receipt-ul generat.

provision-document-type/provision-options.json · Non-secret local provisioning options.Opțiuni locale de provisioning fără secrete.
{
  "base_url": "http://127.0.0.1:18081",
  "service_username": "docula-automation",
  "receipt_file": "/tmp/docula-provision-rca-receipt.json"
}

Provision producers before consumersConfigurează producătorii înaintea consumatorilor

The runnable example provisions the repository's synthetic RCA document type because it exercises the complete real protocol. It creates and publishes the JSON Schema contract, imports deterministic cases, creates canonical declarative-v1 transformer families, validates their drafts against cases, freezes immutable versions and schedules their activations. It uploads each DOCX template, validates package safety and bindings, test-renders representative data, freezes immutable template versions, then creates and validates the ingestion model that names the contract and complete processing topology.Exemplul rulabil configurează tipul sintetic RCA din repository deoarece acesta exercită protocolul real complet. Creează și publică contractul JSON Schema, importă cazuri deterministe, creează familiile canonice de transformatori declarative-v1, validează ciornele cu cazuri, îngheață versiuni imuabile și programează activările. Încarcă fiecare șablon DOCX, validează siguranța pachetului și binding-urile, execută randări de test, îngheață versiunile imuabile ale șabloanelor, apoi creează și validează modelul de ingestie care numește contractul și topologia completă.

Finally the script validates one atomic configuration deployment and applies it in producer-before-consumer order. Release records pin ingestion-model, transformer, template and case identities plus hashes, so a later execution never depends on whichever draft happens to be current. Every create and publish key is derived from canonical input, making an interrupted deploy safe to rerun. Existing matching resources are read and verified; drift is updated only through revision-checked draft operations and new versions. A receipt records only non-secret identities and hashes for the next deployment comparison.La final scriptul validează un deployment atomic de configurare și îl aplică în ordinea producător-înainte-de-consumator. Release-urile fixează identitățile și hash-urile modelului, transformatorului, șablonului și cazului, astfel încât o execuție ulterioară nu depinde de ciorna curentă. Fiecare cheie de creare și publicare derivă din intrarea canonică, deci un deployment întrerupt poate fi reluat. Resursele identice sunt citite și verificate; driftul trece numai prin operații cu revizie și versiuni noi. Receipt-ul păstrează doar identități și hash-uri fără secrete.

provision-document-type/provision.sh · Complete local/deploy-time provisioning wrapper.Wrapper complet pentru provisioning local sau la deployment.
#!/bin/sh
# Provision the repository's synthetic RCA document type from scratch.
# The complete request bodies are generated and checked by scripts/deploy-rca-demo.sh.
set -eu
REPO_ROOT=${DOCULA_SOURCE_ROOT:-$(CDPATH= cd -- "$(dirname "$0")/../../../.." && pwd)}
: "${DOCULA_USERNAME_FILE:?absolute mode-0400 file containing docula-automation}"
: "${DOCULA_PASSWORD_FILE:?absolute mode-0400 service-account password file}"
export DOCULA_BASE_URL=${DOCULA_BASE_URL:-http://127.0.0.1:18081}
export DOCULA_RECEIPT_FILE=${DOCULA_RECEIPT_FILE:-${TMPDIR:-/tmp}/docula-provision-rca-receipt.json}
exec "$REPO_ROOT/scripts/deploy-rca-demo.sh"

Verify the immutable resultVerifică rezultatul imuabil

Treat a successful response as the beginning of verification, not merely an accepted write. Resolve each family at an instant after its activation and compare the returned version and content hash with the receipt. Validate that every release points to the intended ingestion model, transformer, template and case versions. The provisioning order is part of the fixture so code review can see that no consumer is published before its producer exists. If any identity or hash differs, stop the deployment and inspect the structured API error and audit correlation identifier before retrying.Consideră răspunsul de succes începutul verificării, nu doar acceptarea unei scrieri. Rezolvă fiecare familie la un moment ulterior activării și compară versiunea și hash-ul întors cu receipt-ul. Verifică faptul că fiecare release indică versiunile dorite ale modelului de ingestie, transformatorului, șablonului și cazului. Ordinea de provisioning face parte din fixture, astfel încât review-ul vede că niciun consumator nu este publicat înaintea producătorului. Dacă o identitate sau un hash diferă, oprește deployment-ul și inspectează eroarea API structurată și identificatorul de corelare din audit înainte de reluare.

provision-document-type/lifecycle.json · Producer order and immutable checkpoints.Ordinea producătorilor și checkpoint-urile imuabile.
{
  "order": ["contract", "cases", "transformers", "templates", "ingestion_model", "releases"],
  "protocol": ["validate", "version", "publish", "resolve"],
  "idempotent": true
}

Dry-run against make dev-upVerifică local cu make dev-up

Start the local stack with make dev-up, prepare the service account inside the API container using a temporary password file, and create separate mode-0400 username and password files owned by your user. Run make provision-document-type with DOCULA_USERNAME_FILE and DOCULA_PASSWORD_FILE pointing at those files. The target fixes the origin to http://127.0.0.1:18081 and invokes exactly the same script used at deployment time. A successful run prints verified resource identities and writes the chosen receipt path; a failed HTTP or validation response stops immediately.Pornește stack-ul local cu make dev-up, pregătește contul de serviciu în containerul API folosind un fișier temporar pentru parolă și creează fișiere separate cu modul 0400 pentru username și parolă, deținute de utilizatorul tău. Rulează make provision-document-type cu DOCULA_USERNAME_FILE și DOCULA_PASSWORD_FILE către acele fișiere. Targetul fixează originea la http://127.0.0.1:18081 și invocă exact același script folosit la deployment. Un succes afișează identitățile verificate; orice răspuns HTTP sau validare eșuată oprește imediat secvența.

Run the target a second time before promoting an integration change. The second pass proves idempotency and detects unexpected drift rather than duplicating families. Inspect the resulting versions and executions through the observability console, not through an authoring page. When an automation credential is no longer needed, run docula-api service-account seal; preparing a replacement later is an owner-level database operation and produces an audit event. Production scripts should keep secret files outside the checkout and delete temporary cookie jars on every exit.Rulează targetul încă o dată înainte de promovarea integrării. A doua trecere dovedește idempotenta și detectează driftul neașteptat fără să dubleze familiile. Inspectează versiunile și execuțiile rezultate în consola de observabilitate, nu într-o pagină de authoring. Când credentialul nu mai este necesar, rulează docula-api service-account seal; pregătirea ulterioară a unui înlocuitor este o operație owner asupra bazei de date și produce audit. Scripturile de producție păstrează secretele în afara checkout-ului și șterg jar-urile temporare la ieșire.