Un Processus Ormuz décrit comment produire un résultat métier à travers systèmes, services et personnes. Chaque node possède un contrat typé et le processus rend visibles routes, attentes et délégations au lieu de les enfouir dans du code d’intégration.
Un processus définit ses entrées et sorties puis relie des nodes qui lisent ou transforment des données, évaluent une politique, appellent une extension, attendent un événement, collectent une action utilisateur ou invoquent un autre artefact d’orchestration.
Les bindings sont typés. Un node qui attend un tiers, une facture ou un paiement peut consommer directement cet objet plateforme sans obliger chaque designer à câbler des identifiants internes et des chemins de payload provider.
Associer le paiement à la facture.
Lancer votre parcours de relance.
Une facture arrive à échéance sans être réglée. Un prestataire confirme un paiement. Un client termine une étape. Chaque événement peut déclencher la prochaine décision, action ou intervention dans un même processus.
Les définitions de processus sont versionnées. Une instance en cours ou enregistrée conserve la révision exacte dont elle est issue : les modifications ultérieures ne changent pas rétroactivement son exécution.
Le même principe s’applique lorsque le processus appelle une révision de Decision, d’activité Agent ou d’External Task : le contrat choisi fait partie du design et n’est pas une dépendance ambiante mutable.