Architecture de système de workflow

Mise à jour : February 1, 2013

S'applique à: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

L'infrastructure du workflow est constituée de deux composants hébergés sur le serveur d'objets d'application (AOS) : l'exécution du workflow X++ et l'exécution du workflow managé.

L'exécution du workflow X++ comprend :

• l'API d'exécution du workflow ;

• un traitement par lots de messagerie ;

• une file d'attente de messages.

Le traitement par lots de messagerie ou l'API d'exécution du workflow peut invoquer le code d'application, au besoin. L'exécution du workflow X++ est compilée en langage intermédiaire commun (CIL) de .NET Framework. Pour plus d'informations, voir X++ Compiled to .NET CIL.

L'exécution du workflow managé est composée des extensions Windows Workflow Foundation et Microsoft Dynamics AX.

Logiquement, l'infrastructure du workflow est une extension de Microsoft Dynamics AX, transparente pour les utilisateurs. Physiquement, l'exécution du workflow X++ et les exécutions du workflow managé sont hébergées sur l'AOS. L'infrastructure du workflow utilise le traitement par lots sur l'AOS et .NET Interop pour intégrer les sous-systèmes et passer les messages d'un sous-système à un autre. Le code X++ qui est exécuté dans le processeur de traitement par lots est compilé en .NET CIL. Le traitement par lots s'exécute dans le CLR (Common Language Runtime) .NET.

La figure suivante illustre l'architecture de haut niveau de l'infrastructure du workflow.

Les utilisateurs peuvent se servir des écrans et des contrôles du workflow dans le client Microsoft Dynamics AX et dans Enterprise Portal pour Microsoft Dynamics AX pour participer aux processus entreprise. Par programme, les composants qui peuvent appeler le code X++ peuvent utiliser X++ pour appeler un workflow ou soumettre un document à un workflow. Le tableau suivant décrit les étapes de workflow lorsqu'un utilisateur soumet un état de dépenses au système de workflow pour approbation.

Étape	Exécution	Activité
1	Exécution du workflow X++	Un utilisateur soumet un état de dépenses en cliquant sur le bouton Soumettre de l'un des contrôles de workflow. Le code X++ active donc une instance de workflow en appelant l'API d'exécution du workflow. L'API d'exécution du workflow valide un message sur la file d'attente des messages. Le traitement par lots de messagerie lit le message et envoie une demande d'activation de workflow à l'exécution du workflow managé. > [!Note] > Le traitement par lots de messagerie traite la file d'attente de messages à des intervalles d'une minute.
2	Exécution du workflow managé	.NET Interop de X++ reçoit le message et démarre une nouvelle instance de workflow via Windows Workflow Foundation. Cette instance de workflow exécute un rappel sur l'API d'exécution du workflow X++ via .NET Interop vers X++ CIL et valide un message indiquant que le workflow a démarré. Après validation du message, l'exécution du workflow managé enregistre l'instance de workflow inactive dans la base de données Microsoft Dynamics AX. L'exécution la supprime ensuite de la mémoire. Lorsque l'exécution du workflow managé reçoit un autre message de l'exécution du workflow X++ pour cette instance de workflow, elle restaure l'instance de workflow en mémoire et la reprend. Chaque instance de workflow est unique. Si deux utilisateurs soumettent leurs états de dépenses pour approbation, deux instances de workflow sont démarrées.
3	Exécution du workflow X++	Le traitement par lots de messagerie lit le message Workflow démarré de la file d'attente de messages et appelle le gestionnaire d'événements d'application pour traiter un événement Workflow démarré. Le traitement par lots valide ensuite un message d'accusé de réception indiquant que l'événement a été traité.
4	Les deux	Le même schéma de messagerie est répété, au besoin, tout au long du cycle de vie de l'instance de workflow.

L'architecture de workflow permet de fournir un système de messagerie fiable et durable et assure la synchronisation entre l'état du workflow et celui de l'application. En cas de panne matérielle ou logicielle imprévue, l'état de l'instance de workflow est renvoyé à son dernier point d'enregistrement connu et le message reste dans la file d'attente. Du point de vue de l'architecture, le modèle de récupération permet donc de résoudre le problème et de reprendre le workflow.