Types d'actions

Mutations côté serveur typées, soumises au point de décision de politique — préconditions, postconditions, effets de bord, audit.

Un type d'action est une mutation côté serveur, typée, sur l'ontologie. Exemples : AssignAsset, FileSAR, EscalateCase, MergeEntities.

Contrairement aux outils de workflow (qui encapsulent un appel API externe), les types d'actions opèrent sur l'ontologie elle-même — ils créent ou modifient des instances, créent des liens ou changent d'état. Chaque action est soumise au point de décision de politique et produit un événement d'audit.

Pourquoi les actions typées sont importantes

Sans actions typées, les workflows muteraient directement le magasin de données sous-jacent — en contournant les classifications, le masquage et l'audit. Les types d'actions fournissent :

Entrée typée — l'action déclare son schéma ; les appelants ne peuvent pas passer des champs arbitraires.
Préconditions typées — l'action déclare ses exigences d'état ; les échecs sont renvoyés comme erreurs typées, sans corruption silencieuse.
Effets de bord typés — l'action déclare ce qu'elle modifie ; les relecteurs peuvent voir l'impact complet.
Autorisation — chaque dispatch passe par le point de décision de politique avec l'identité de l'appelant.
Audit — chaque dispatch produit un événement avec l'acteur, l'action, la cible et le résultat.

Anatomie

Champ	Rôle
`id`	L'identifiant de l'action (par ex. `AssignAsset`).
`title`	Nom lisible par l'humain.
`input`	Le schéma d'entrée (propriétés typées).
`preconditions`	Prédicats qui doivent être satisfaits sur l'entrée avant l'exécution de l'action.
`effect`	La mutation elle-même — ce qui change.
`postconditions`	Prédicats que le système vérifie après l'effet — garanties pour les appelants en aval.
`auditMetadata`	Ce qui est enregistré dans l'événement d'audit.

Exemple

defineActionType({
  id: "AssignAsset",
  title: "Assign Asset",
  input: {
    assetId: { type: "string", required: true },
    userId: { type: "string", required: true },
  },
  preconditions: [
    { rule: "asset-exists",        params: { ref: "assetId" } },
    { rule: "user-in-workspace",   params: { ref: "userId" } },
    { rule: "asset-unassigned",    params: { ref: "assetId" } },
  ],
  effect: {
    kind: "update-object",
    type: "Asset",
    set: { ownerId: "{userId}", assignedAt: "{now}" },
  },
  postconditions: [
    { rule: "asset-owner-equals", params: { ref: "userId" } },
  ],
});

Dispatch

Les actions sont dispatchées depuis :

Un agent de workflow — l'outil Run Ontology Action.
Le plan de travail — dispatch manuel depuis l'onglet Actions.
Une interface personnalisée — via l'API de la plateforme avec une session à portée d'espace de travail.

Dans les trois cas, le dispatch passe par :

Validation du schéma — l'entrée doit correspondre aux types déclarés.
Autorisation — le point de décision de politique évalue l'identité de l'appelant par rapport à l'action.
Évaluation des préconditions — toutes les préconditions doivent être satisfaites ; un échec renvoie une erreur typée PreconditionFailed.
Exécution de l'effet — la mutation s'exécute dans une transaction.
Vérification des postconditions — les échecs annulent la transaction.
Émission de l'audit — un événement structuré est enregistré dans le journal d'audit.

Une action échouée est observable. Si une précondition échoue, l'appelant reçoit une erreur typée ; le journal d'audit enregistre la tentative ; aucune mutation partielle ne se produit. Les workflows peuvent bifurquer sur la classe d'erreur.

Idempotence

Les actions peuvent déclarer une clé d'idempotence. Redispatcher la même action avec la même clé dans la fenêtre d'idempotence renvoie le résultat précédent sans réexécution. Utile pour les schémas de workflow sûrs lors des réessais.

Autorisation

Chaque action déclare quels rôles ou droits sont nécessaires pour la dispatcher. Un membre d'espace de travail sans le droit approprié ne peut pas voir l'action dans le plan de travail, et un workflow sans le droit approprié ne peut pas appeler l'outil Run Ontology Action contre elle.

Voir aussi

Concepts → Types d'actions — place des actions dans les cinq couches.
Utilisation dans les workflows — comment un agent dispatche une action.
Sécurité → Autorisation — comment le point de décision de politique évalue les dispatches.
Journal d'audit — ce que chaque action émet.