Utilisation des évènements métiers (bp)

De Wiki1000
Version du 21 août 2009 à 16:09 par Syfre (discuter | contributions)
(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)

Sommaire

Introduction

Cet exemple décrit le déclenchement de processus métier par un évènement métier.

Description du modèle et du processus métier

La classe WFClasseA possède un Code (attribut unCode) et un état (attribut unEtat).

Deux règles d’état sont définies :

  • La règle RegleEtat_unCode détecte le changement de l’attribut code.

image41.png

  • La règle RegleEtat_unEtat détecte le changement de l’attribut unEtat :

image42.png

Le processus va réaliser les opérations suivantes :

  1. Lorsque l’utilisateur modifie le code d’un objet de WFClasseA, une instance du processus est déclenchée.
  2. Cette instance modifie l’attribut Etat de l’objet correspondant à la valeur « Initial ».
  3. Le processus attend ensuite que l’attribut Etat passe à la valeur « Etat3 », changement réalisé par l’utilisateur.
  4. L’instance du processus change alors la valeur de l’attribut Etat à « Final » et se termine.

Définition du processus métier

Le processus métier correspondant est défini.

image43.png

L’évènement initial est l’évènement métier généré par la règle d’état de changement de code.

image44.png

Le changement du code d’un objet de cette classe va donc créer une instance du processus.

L’activité suivante est une activité script qui modifie la valeur de l’attribut « Etat » de l’objet.

image45.png

La classe de l’objet métier est connue par le processus. Ainsi les outils d’aide à l’édition de code fonctionnent.

image46.png

Le corps du code modifie l’attribut de l’instance dans une transaction.

image47.png

Le processus attend ensuite la modification de l’état de l’objet. Pour cela il utilise un évènement « Attente » d’Evènement métier.

image48.png

Lorsque la case « Evènement de l’instance principale » est cochée, l’évènement doit provenir de la même instance d’objet métier que celle qui a déclenchée le processus.

Sur l’onglet « Post-Condition », la condition est la suivante : l’objet métier doit être dans l’état 3.Cette condition sera testée par l’activité. Si elle n’est pas remplie, l’activité sera toujours en attente.

image49.png

Lorsque l’objet a été changé, ici par l’utilisateur, le processus enchaine l’activité suivante qui modifie de nouveau l’état de l’objet, puis se termine.

image50.png

Déroulement

Une interface utilisateur simple est utilisée pour modifier les objets. Le processus est en cours d’exécution dans une machine locale.

image51.png

La modification du code entraine la création d’une instance. Les différentes activités du processus sont exécutées jusqu'à l’attente d’un nouvel évènement métier:

image52.png

Si on rafraichit l’interface utilisateur, on constate que l’état de l‘objet a été changé.

image53.png

Passez l’objet dans l’état Etat3.

image54.png

L’instance du processus enchaîne les dernières activités puis se termine. En rafraichissant l’interface utilisateur, on constate que l’objet est dans l’état final.

image55.png

Vous remarquez dans cet exemple que :

  • La création d’un nouvel objet de la classe ne déclenche pas d’instance de processus, cela parce que les règles d’état ne sont évaluées qu’en mode modification.
  • La modification de l’objet dans un autre état que l’état 3 n’a pas d’influence sur le processus.

Processus Métiers (bp)Développement DSM

Outils personnels