Architecture de processus

Le système de gestion des processus dans Dynamics 365 Customer Engagement (on-premises) inclut les services Web Dynamics 365 Customer Engagement, les plug-ins, les formulaires et d’autres composants.

Diagramme de l’architecture des processus

Le schéma suivant illustre l’architecture système de haut niveau pour Dynamics 365 Customer Engagement (on-premises) et met en évidence les parties du système spécifiques aux processus.

Ce schéma montre l’architecture des processus de Dynamics 365 Customer Engagement (on-premises), dont les composants internes, les composants externes, l’infrastructure et les données.

Composants internes. Les composants internes qui prennent en charge le modèle de programmation de processus de Dynamics 365 Customer Engagement (on-premises) incluent des services web, la plateforme partagée et la logique métier. La plateforme partagée comprend les composants Dynamics 365 Customer Engagement (on-premises) courants qui fournissent l’inscription, le cache des métadonnées et les services d’accès aux données. La logique métier contient l’implémentation de la logique métier pour les entités métier de Dynamics 365 Customer Engagement (on-premises).

Composants externes. Les composants externes sont les suivants :

• Modèle objet Windows Workflow Foundation, qui contient un ensemble de classes utilisées pour créer et analyser les définitions de processus de workflow au format XAML.

• exécution de Windows Workflow Foundation, qui contient un ensemble de classes utilisées pour exécuter les processus de workflow.

Infrastructure de processus. L’infrastructure des processus Dynamics 365 Customer Engagement (on-premises) inclut les composants suivants :

• Le modèle d’entité de processus, qui contient un ensemble de classes utilisant le modèle objet Windows Workflow Foundation et expose les activités de workflow de Dynamics 365 Customer Engagement (on-premises).

• Logique métier de processus, qui implémente la logique métier pour les entités propres aux processus.

• Exécution de processus, qui fournit les services d’exécution de workflow, comme l’hébergement et la persistance de workflow.

Données de processus. Le modèle de programmation de processus Dynamics 365 Customer Engagement (on-premises) est pris en charge par les données suivantes :

• données métier, contenant les informations associées aux entités Dynamics 365 Customer Engagement (on-premises) ;

• données de configuration de processus, qui comprend les définitions de processus de workflow, les processus compilés de workflow et les paramètres de processus de workflow ;

• données d’exécution de processus, qui est nécessaire pour exécuter les processus de workflow et implémenter les fonctions de processus de workflow, telles que la persistance et les notifications.

Processus et le modèle d’événement unifié

Dynamics 365 Customer Engagement (on-premises) utilise un modèle d’événement unifié utilisé dans les plug-ins (légendes) et dans les processus. Ce sous-système de traitement des événements ajoute davantage de flexibilité à l’exécution des processus et aux plug-ins en présentant le modèle d’exécution du pipeline.

À l’aide de ce modèle, les processus et les plug-ins sont exécutés selon leur inscription, leur type message et un groupe prédéfini de paramètres configurables. Les opérations de plateforme principales participent à l’ordre d’exécution pour former un modèle d’exécution beaucoup plus fiable et extensible.

Cycle de vie des processus

Le cycle de vie d’un processus décrit les transitions d’état de la création à l’exécution. Un processus peut être dans l’un des états suivants : Prêt, Suspendu, Verrouillé et Terminé. Les événements qui se produisent durant toute la durée de vie du processus entraînent une transition d’un état à un autre.

Workflows

Le cycle de vie du workflow est le suivant :

1. lorsque vous créez un workflow, il est à l’état Brouillon. Vous devez activer le workflow avant qu’il ne puisse s’exécuter. Lorsque vous activez un workflow, il s’abonne à des événements Dynamics 365 Customer Engagement (on-premises) spécifiques. Lorsque ces événements sont déclenchés dans la plateforme, une capture instantanée des dépendances de workflow et des paramètres d’entrée est créée, et une nouvelle opération asynchrone est ajoutée au gestionnaire des files d’attente asynchrones. L’opération asynchrone représente une tâche d’exécution de workflow et attend l’exécution dans la file d’attente dans l’état Prêt.

2. Lorsque l’opération asynchrone est traitée, une instance de workflow, associée à cette opération, est créée par le moteur d’exécution de Windows Workflow Foundation et l’état de celui-ci passe de Prêt à Verrouillé.

3. L’opération asynchrone est mise à jour avec l’état de l’instance de workflow lors de chaque transition. Lorsque l’opération asynchrone est bloquée, le moteur d’exécution de Windows Workflow Foundation place l’instance de workflow dans l’état Suspendu et la supprime de la mémoire. Lorsque les conditions de l’état Suspendu sont satisfaites, l’instance de workflow est rechargée en mémoire.

4. L’exécution du workflow reprend en plaçant l’instance de workflow dans l’état Prêt, puis dans l’état Verrouillé. Dans le scénario simple, l’instance de workflow passe à un état Terminé lorsque toutes les activités de workflow se sont déroulées avec succès.

L’état des opérations asynchrones peut également être modifié par l’utilisateur. Par exemple, une opération asynchrone qui se trouve dans un état Suspendu peut être explicitement redémarrée par l’utilisateur.

Boîtes de dialogue

Le cycle de vie d’une boîte de dialogue est le suivant :

1. lorsque vous créez une boîte de dialogue, elle est à l’état Brouillon. Vous devez activer la boîte de dialogue avant qu’elle ne puisse s’exécuter. Une boîte de dialogue peut être exécutée depuis le formulaire et la grille de son entité principale, ou directement à l’aide de l’URL de la boîte de dialogue. Pour plus d’informations, voir Démarrer un dialogue à l’aide d’une URL.

2. Chaque fois que vous exécutez une boîte de dialogue, une instance de session de processus est créée pour la boîte de dialogue. Au fur et à mesure que vous progressez dans l’exécution de la boîte de dialogue, l’entité de session du processus est mise à jour avec les actions exécutées pendant l’exécution de la boîte de dialogue.

3. Si vous avez terminé l’exécution de la boîte de dialogue avec succès, l’enregistrement de la session de processus correspondante est créé avec l’état Terminé. Si vous annulez la boîte de dialogue sans l’achever, l’enregistrement de la session de processus correspondante est créé avec l’état Incomplet.

Processus et le service asynchrone : pour les workflows uniquement

Le service asynchrone vous permet d’exécuter, analyser et gérer les différentes opérations de longue durée, comme l’importation en nombre, le courrier en nombre et les processus de workflow. Pour améliorer les performances, l’évolutivité et la fiabilité de Dynamics 365 Customer Engagement (on-premises), ces opérations sont exécutées de façon asynchrone. Cela signifie qu’une opération demandée n’est pas traitée immédiatement, mais ajoutée à une file d’attente et traitée par Dynamics 365 Customer Engagement (on-premises) au moment approprié.

Lorsqu’un événement est levé dans le pipeline de la plateforme Dynamics 365 Customer Engagement (on-premises), tous les workflows associés à l’événement sont exécutés par le service asynchrone. Les gestionnaires d’événements de workflow sont ajoutés à la file d’attente asynchrone et traités selon l’ordre d’exécution des événements.

Persistance et arrêt de processus : pour les workflows uniquement

Un workflow peut être une opération commerciale à long terme qui peut nécessiter des heures, des semaines ou des mois pour se terminer. Il peut être réellement inactif pendant de longues périodes, dans l’attente d’informations fournies par les utilisateurs ou par d’autres systèmes.

Pour améliorer les performances, l’évolutivité et la fiabilité de Dynamics 365 Customer Engagement (on-premises), les opérations longue durée telles que les workflows utilisent le service asynchrone.

Le service asynchrone, comme l’hôte du moteur d’exécution Windows Workflow Foundation, ne peut pas toujours mettre en cache et conserver tous les objets qui s’accumulent au cours de l’activité de workflow continue. Sous certains conditions, comme lorsque le redémarrage ou l’arrêt se produisent à l’exécution d’un workflow, le moteur d’exécution du workflow utilise un service de persistance pour enregistrer l’état de l’instance de workflow sur le disque. Le service de persistance est également appelé lorsque d’autres conditions interviennent, par exemple lorsqu’un workflow devient inactif et attend qu’un certain événement externe se produise. La persistance de ces instances de workflow inactives économise de la mémoire et augmente considérablement l’évolutivité. Si un serveur exécutant le service asynchrone est arrêté ou si le workflow s’interrompt lors de l’exécution, le workflow peut être redémarré à partir de son dernier point de persistance, une fois que le serveur redémarre. Quand le workflow n’est plus inactif, l’état de l’instance de workflow est restauré en mémoire à l’état qui était le sien lors du dernier point de persistance.

Pour plus d’informations : Persistance de workflow.

Voir aussi

Service asynchrone
Infrastructure d’événements
Processus dans Dynamics 365 Customer Engagement (on-premises)