Sous-processus et modularité

Les sous-processus soutiennent la clarté du modèle en regroupant les activités connexes dans une structure réutilisable unique. Ils aident à réduire la complexité des diagrammes, à isoler la logique métier et à encourager la réutilisation.

Dans BPMN, un sous-processus peut être modélisé soit en ligne, soit via une activité d'appel réutilisable. Dans Maestro :

• Seules les activités d'appel sont prises en charge.
• Le sous-processus doit être modélisé sous forme de diagramme distinct.
• Le processus d'appel transmet les entrées et reçoit les sorties par le biais de paramètres définis.

Pourquoi utiliser des activités d'appel ?

Une activité d'appel fait référence à un sous-processus défini ailleurs dans le projet ou l'environnement. Il se comporte comme une fonction réutilisable. Les activités d'appel améliorent la modélisation des processus comme suit :

• En réduisant la duplication entre les diagrammes
• En isolant la logique réutilisable (par exemple, approbations, validations, distribution)
• En préservant la concision du diagramme principal
• En maintenant un comportement cohérent entre les variantes de processus.

Modélisation des sous-processus

Pour créer un sous-processus dans Maestro :

• Modélisez le sous-processus comme son propre diagramme autonome.
• Dans le diagramme parent, insérer une activité d'appel.
• Liez l'activité d'appel au sous-processus.
• Configurer les variables d'entrée et de sortie pour échanger des données.

Exemples de modélisation

Cas d'utilisation: un workflow d'intégration utilise le même sous-processus Collect Documents dans les processus d'intégration des employés et des fournisseurs. Au lieu de dupliquer les étapes, une activité d'appel est ajoutée dans chaque processus parent référençant le même sous-processus.

Cas d'utilisation: cet exemple de sous-processus montre un workflow conditionnel de téléchargement et de chargement de fichier dans Maestro. Le processus commence par un événement de démarrage par message et par des branches utilisant une passerelle exclusive. Selon la condition, il télécharge une pièce jointe d'e-mail ou un fichier à partir d'un champ d'enregistrement. Les deux chemins conduit à une tâche Charger le fichier , suivi d’un élément Sous-processus nommé Sous-processus1. Ce sous-processus encapsule des étapes supplémentaires liées aux actions post-chargement avant de terminer le workflow à l'événement de fin.

Directives de modélisation

• Donnez aux sous-processus des noms métier significatifs (par exemple, Verify Contract Terms).
• Documentez les paramètres d'entrée/sortie et leur utilisation attendue.
• Gardez les sous-processus concentrés sur une seule responsabilité ou un seul résultat.
• Évitez de concevoir des sous-processus avec des hypothèses sur le contexte parent.

Conventions d'affectation de noms

Les noms des activités de sous-processus et d'appel doivent :

• Utiliser un langage métier, pas des termes techniques
• Décrivez le résultat (par exemple, Collect Customer Data, et pas Form Step 2)
• Refléter ce que le sous-processus accomplit, pas comment.

Non pris en charge

• Les sous-processus étendus (c'est-à-dire les sous-processus en ligne) ne sont pas pris en charge. Tous les sous-processus doivent être modélisés sous forme de diagrammes distincts et invoqués à l'aide des activités d'appel.
• Les sous-processus ad hoc ne sont pas pris en charge.
• Le partage de variables implicites n'est pas pris en charge. Les données doivent être mappées explicitement par le biais de liaisons d'entrée/sortie.

Marqueurs multi-instances

Les sous-processus prennent en charge les marqueurs multi-instances, dans lesquels chaque élément est exécuté plusieurs fois. Les éléments qui peuvent être marqués comme multi-instances sont tous les types de tâches, à l'exception des sous-processus.

Marqueurs imbriqués

Les variables de chaînes de caractères suivantes sont prises en charge en tant qu'itérateurs imbriqués :

Catégorie	Attributs	Comment utiliser ou accéder
OuterSP : Obtenir les coordonnées de chaque utilisateur	InputCollection	var.GetUsers
OuterSP : Obtenir les coordonnées de chaque utilisateur	Iterator Item	iterator.item.gid
InnerSP : obtenir tous les e-mails de chaque contact	InputCollection	iterator[0].item.contactArray
InnerSP : obtenir tous les e-mails de chaque contact	Iterator Item	iterator[1].item.ContactId
Envoyer un e-mail	InputCollection	iterator[1].item.EmailArray
Envoyer un e-mail	Iterator Item	iterator[2]item.emailAddress

Pour de plus amples informations sur les éléments BPMN pris en charge dans Maestro, consultez la section Prise en charge de BPMN.