Vous pouvez également accéder à ce tutoriel en anglais et en allemand.

 

Ceci est le premier de quatre tutoriels sur la flexibilité dans YAWL. Il donne un aperçu du service worklet, de la gestion des exceptions à l'aide d'exlets et des règles Ripple-Down (RDR).

 

Bonjour et bienvenue dans un autre tutoriel YAWL! Il s'agit du premier d'une série de didacticiels sur la flexibilité des flux de travail. Il y a un dicton qui dit que 95% des discussions concernent environ 5% des cas dans le développement de logiciels. Et c'est à peu près la même chose pour Business Process Automation. Il est donc important d'être flexible d'une part mais de ne pas être obligé de tout spécifier lors du développement initial d' un workflow. Il existe deux types de flexibilité: dans les flux de travail, le premier est une flexibilité au moment de la conception. Nous avons déjà vu que par la séparation des préoccupations de séparation des flux de contrôle, des ressources et des données et d'avoir un éditeur graphique, nous obtenons déjà une certaine flexibilité dans les flux de travail. De plus, vous pouvez modifier une spécification dans un système en cours d'exécution et faire en sorte que les anciens cas qui sont déjà en cours d'exécution se terminent avec l'ancienne spécification et démarrer les nouveaux cas avec une nouvelle spécification. Alors déjà, nous avons une certaine flexibilité. Ce que nous discuterons dans ce didacticiel et dans les didacticiels suivants, est une flexibilité améliorée, où vous avez également la possibilité d' étendre le comportement d'une spécification de flux de travail sans changer la spécification elle-même. Le deuxième type de flexibilité concerne le fait de changer quelque chose pendant qu'une affaire est en cours. Il s'agit donc plutôt d'une flexibilité dynamique. Et aussi ici, nous aurons quelques concepts concernant les worklets et les exlets dans YAWL qui couvriront cela. Comme déjà dit, vous ne pouvez pas penser à toutes les possibilités lors de la première conception d'une spécification de flux de travail. Donc, dans la première catégorie de flexibilité, nous avons des concepts dans YAWL comme les worklets qui spécifient un certain comportement et vous pouvez appeler ces worklets en utilisant des règles dites de ripple down. Les règles d'ondulation sont des arbres, des arbres binaires avec des conditions et des conclusions que vous pouvez utiliser pour étendre de manière flexible le comportement d'une spécification de flux de travail lorsque vous découvrez de nouveaux cas particuliers. Ceux-ci sont également appelés cas de pierre angulaire. L'autre chose est que nous avons le problème que, par exemple, les exceptions lorsqu'elles se produisent impliquent souvent que vous mettez fin à un cas. Mais vous voulez faire quelque chose avant de mettre fin anormalement à un cas. Si nous essayions de les implémenter avec des moyens de flux de contrôle ordinaires, nous aurions beaucoup d'arcs allant de certains endroits à la fin de la spécification. Et cela conduirait à la fin à un graphique qui ressemble plus à des spaghettis et qui n'est plus très clair. Et donc - pour ce cas - nous avons la possibilité d'utiliser des exlets et de définir certaines pré- ou post-conditions dans les tâches, puis d'une manière ou d'une autre de terminer un cas avec une certaine gestion des exceptions et de ne pas utiliser ces arcs qui mènent à la fin. Dans la deuxième catégorie pour le comportement dynamique, nous pouvons définir des déclencheurs externes dans YAWL et nous pouvons modifier le comportement d'un cas en cours d'exécution en utilisant ces déclencheurs externes, écrire des worklets qui définissent un nouveau comportement et l'ajouter au système. Nous obtenons ainsi un système de gestion du flux de travail d' apprentissage qui intègre de nouvelles exceptions au fil du temps. Enfin, il est possible de prendre en compte le comportement commun dans les spécifications de flux de travail à l'aide de worklets. Cela n'a pas à voir directement avec le sujet de la flexibilité, mais c'est une autre utilisation des worklets. Nous avons déjà vu dans les vidéos précédentes que vous pouvez avoir des tâches complexes avec des sous-flux de travail à l'intérieur. Le problème de ces tâches complexes est qu'elles sont limitées à une spécification. Si nous pensons à un système plus grand avec de nombreux flux de travail tout autour du même sujet - disons que nous avons besoin de la possibilité de prendre en compte le comportement commun dans les sous-flux de travail - et nous ne pouvons pas le faire en utilisant des tâches complexes car les tâches complexes n'existent que dans une spécification et à cette fin, nous pouvons également utiliser des worklets avec une règle très simple qui est toujours vraie. Ensuite, nous pouvons invoquer la même spécification de workflow à partir de différentes spécifications parent. D'accord, c'est tout pour l'introduction théorique. Et dans les didacticiels suivants, nous aborderons les sujets et les examinerons dans le système YAWL.