IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Tutoriel Alfresco et jBoss BPM : exemple d'implémentation d'un workflow avancé de gestion des dossiers de crédit

Tutorial Alfresco - jBPM:
exemple d'implémentation d'un workflow avancé

Date de publication : 12 mai 2009


 

III. Modélisation (workflow) jBPM du processus métier
III-1. Diagramme du Workflow
III-1-1. Node "Credit-receipt"
III-1-2. Node "Quottation"
III-1-3. Noeud Contact-client
III-1-4. Node "Approbation"
III-1-5. Node "Contract-preparation"
III-1-6. Node "Prepare-contract"
III-1-7. Node "Formalize-disbursement"
III-1-8. Node "Sign-contract-join"
III-1-9. Node "Check-etablishment"
III-1-10. Node "Computer-approbation"
III-1-11. Node "Client-info"
III-2. Assignations des tâches


III. Modélisation (workflow) jBPM du processus métier

Il s'agit de réaliser le diagramme du Workflow, modéliser les tâches et leurs assignations.
On ressortira aussi la cartographie fonctionnelle associée au processus.


III-1. Diagramme du Workflow

La figure ci-dessous est le diagramme (Process design) du Workflow du cas d'étude approbation de crédit.

Figure 2 : Process design du Workflow d'approbation du crédit
Figure 2 : Process design du Workflow d'approbation du crédit


Dans la figure, 2 ci-dessus, on distingue plusieurs noeuds d'exécution du processus BPM. Nous allons les parcourir :


III-1-1. Node "Credit-receipt"

Il représente le noeud de réception de la demande du crédit du client.
Ce noeud possède une unique tâche réalisée par un agent du courrier. Cette tâche consiste à transmettre la demande au responsable du service du crédit.
Dans le cas où l'agent du courrier réceptionne la demande du client sous format papier, l'agent la numérise à travers une chaîne de capture. La demande numérisée est directement prise en compte dans le système de GED. L'agent du courrier initialise alors le Workflow sur la demande numérisée et réalise la présente tâche.

Le noeud "Credit-receipt" est un noeud de type "Start State", c'est à dire qu'il représente le début du Workflow.
L'entrée de ce noeud dans le fichier jPDL du Workflow est la suivante :
Figure 3: Node 'Credit-receipt' dans le fichier jPDL

	<start-state name="Credit-receipt">
		<task name="ac:dispatch-application" swimlane="initiator">
		</task>
		<transition to="Quottation" name="dispatch"></transition>
		<event type="node-leave">
           <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
              <script>
                 <variable name="ac_cocPool" access="write"/>
                 <expression>people.getGroup('GROUP_coc');</expression>
              </script>
           </action>		
           <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
              <script>
                 <variable name="ac_codirPool" access="write"/>
                 <expression>people.getGroup('GROUP_codir');</expression>
              </script>
           </action>
           <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
              <script>
                 <variable name="ac_dafPool" access="write"/>
                 <expression>people.getGroup('GROUP_daf');</expression>
              </script>
           </action>
           <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
              <script>
                 <variable name="ac_directionPool" access="write"/>
                 <expression>people.getGroup('GROUP_direction');</expression>
              </script>
           </action>
           <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
              <script>
                 <variable name="ac_financialServicePool" access="write"/>
                 <expression>people.getGroup('GROUP_financial-service');</expression>
              </script>
           </action>
           <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
              <script>
                 <variable name="ac_judicialServicePool" access="write"/>
                 <expression>people.getGroup('GROUP_judicial-service');</expression>
              </script>
           </action>		
		</event>

	</start-state>

Le moteur jBPM nous permet d'exécuter certaines actions suite à des évènements sur les noeuds comme l'entrée ou la sortie d'un noeud.
Dans le cas de la figure 3, une série d'actions seront exécutées dès que le jeton d'exécution quitte le noeud (<event type="node-leave">). La principale action qui doit être exécutée dès la sortie du noeud est l'Action Handler d'Alfresco AlfrescoJavaScript. Cette action permet l'exécution du code JavaScript (côté serveur grâce au moteur Rhino) présent dans le fichier jPDL du Workflow.

Nous configurons aussi certaines variables globales :
  -  ac_cocPool: représente le pool d'acteurs membres du comité d'octroi de crédit;
  -  ac_codirPool: représente le pool d'acteurs membres du comité de direction;
  -  ac_dafPool: représente le pool d'acteurs membres de la direction des affaires financières ;
  -  ac_directionPool: représente le pool d'acteur membres de la direction;
  -  ac_financialServicePool: représente le pool d'acteurs du service des finances;
  -  ac_judicialServicePool: représente le pool d'acteurs membres du service juridique.

Dans ce noeud, l'agent du courrier doit envoyer la demande de crédit au service du crédit : cet envoi est matérialisé par la transition nommée "dispatch".


III-1-2. Node "Quottation"

Noeud de cotation du dossier du crédit à un agent du crédit ou au gestionnaire du client.
Ce noeud comporte une tâche réalisée par le responsable du crédit. La tâche consiste à choisir l' agent du crédit qui sera en charge du dossier et de le lui envoyer.
La description de ce noeud dans le fichier jPDL du Workflow est la suivante :
Figure 4: Node 'Quottation' dans le fichier jPDL du workflow

	<task-node name="Quottation">
		<task name="ac:quottation" swimlane="loan-service">
			<event type="task-create">
				<!-- Set the due date and the priority of the task -->
				<script>
				   if (bpm_dueDate != void) taskInstance.dueDate = bpm_dueDate;
				   if (bpm_priority != void) taskInstance.priority = bpm_priority;
				</script>
			</event>
			<event type="task-assign">
			   <!-- Before the task is assign, send an email to the initiator -->
			   <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
				<script>
				  if(ac_notifyMe)
				  {
				    var mail = actions.create("mail");
				    mail.parameters.to = initiator.properties["cm:email"];
				    mail.parameters.subject = "Loan approbation process ";
				    mail.parameters.from = bpm_assignee.properties["cm:email"];
				    mail.parameters.text = "Loan application send successfully.";
				    mail.execute(bpm_package);
				 }
				</script>
			   </action>
			</event>								
		</task>
		<transition to="Contact-client" name="send"></transition>
	</task-node>

Dans le noeud de la figure 4, on positionne une date d'échéance (bpm_dueDate) et une priorité par défaut (bpm_priority) dès l'instanciation de la tâche (<event type="task-create"> ).

Dès que le Responsable de Crédit assigne un agent de crédit pour l'étude de dossier (<event type="task-assign"> ), une action est exécutée : grâce à JavaScript, un mail de notification va être envoyé au Responsable du crédit pour le confirmer l'assignation de la tâche à l'agent du crédit à qui il a quotté le dossier.
La transition nommée "send" permet de déplacer l'exécution du Workflow au noeud "Contact-client".


III-1-3. Noeud Contact-client

Noeud de contact avec le client. Ce noeud possède une tâche réalisée par l'agent en charge crédit. Celui-ci est invité à travers cette tâche à contacter le client. L'agent pose un certain nombre de questions au client. Sur la base des réponses du client, il crée (toujours dans cette tâche) une fiche interne de la demande de crédit du client. Il peut soit rejeter la demande si son filtrage est négatif ou envoyer la demande pour approbation au comité d'octroi. Ce choix est matérialisé par les deux transitions nommées "approbate" et "reject".
La description de ce noeud dans le fichier jPDL du Workflow est la suivante :
Figure 5: Noeud 'Contact-client' dans le fichier jPDL du workflow

<task-node name="Contact-client">
		<description>
			The agent in charge of credit contacts the customer, gives him a form
			(form of internal customer application) which contains at least thirty (30) questions.
			Following the customer's responses, the agent may make a 1st screening 
			before presenting the customer' case to the COC.
			At each stage of transition, date and signature must be entered on the
 			record for security measures (who did what and when).
		</description>
		<task name="ac:contact-client" swimlane="loan-agent">		
			<event type="task-end">
			    <!-- Remember agent actor -->
			   <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
				<script>
                			<variable name="ac_agent-actor" access="write" />
                			<expression>
                       		 	if (taskInstance.actorId != null)
                           			taskInstance.actorId;
                       		 	else
                           			person;
               	     		</expression>
				</script>
			    </action>
			</event>									
		</task>
		<transition to="Client-info" name="reject"></transition>
		<transition to="Approbation" name="approbate"></transition>		
	</task-node>

III-1-4. Node "Approbation"

Noeud d'approbation de la demande par le comité d'octroi de crédit. Ce noeud est composé d'une tâche réalisée par un pool d'acteurs (les membres du groupe représenté par la variable ac_cocPool).
Tous les membres de ce groupe reçoivent la même tâche. L'un d'eux doit s'approprier la tâche afin de modifier le système en enregistrant la décision du comité.
La décision du comité sur la demande peut être soit le rejet de la demande, soit l'approbation. Ce choix est matérialisé par les deux transitions nommées "reject" et "approve".
La description de ce noeud dans le fichier jPDL du Workflow est la suivante:
Figure 6: Noeud 'Approbation' dans le fichier jPDL du workflow

	<task-node name="Approbation">
    		<description>
			Each member of the COC receives an approval tack. One of the members
			must take the task to inform the state of the application decided by the committee.
			After reviewing, a judgment is given: application approved or 
			rejected. (reason of rejection).
		</description>
    
        	<task name="ac:approbation-coc" swimlane="coc">
 			<!-- Remember the member who own the task -->
            <event type="task-end">
               <action class="org.alfresco.repo.workflow.jbpm.AlfrescoJavaScript">
                  <script>
                     <variable name="ac_coc-member" access="write"/>
                     <expression>
                        if (taskInstance.actorId != null)
                           people.getPerson(taskInstance.actorId);
                        else
                           person;
                     </expression>
                  </script>
               </action>
            </event>
        
        </task>
		<transition to="Contract-preparation" name="approve"></transition>
		<transition to="Client-info" name="reject"></transition>
	</task-node>

III-1-5. Node "Contract-preparation"

Dans un Workflow jPDL, un Fork est utilisé lorsqu'on veut réaliser des tâches en simultané. La continuation de l'exécution du Workflow à un autre noeud ne se fera que si toutes les tâches en simultané sont achevées.
La description dans le fichier jPDL est la suivante :
Figure 7: Noeud 'Contract-preparation' dans le fichier jPDL du workflow

	<fork name="Contract-preparation">
	   <description>
			The report is forwarded to the judicial department that handles 
			the preparation of the contract stipulating the commitments
			of both parties with details on other key clauses in case the appropriation is
			approved. (Penalties, guarantees, etc ...).
	   </description>
	   <transition to="Prepare-contract" name="prepareContract"></transition>
	   <transition to="Formalize-disbursement"name="formalizeDisbursement"></transition>
	</fork>

Dans la figure 7, à travers les deux transitions nommées "prepareContract" et "formalizeDisbursement ", le moteur du Workflow va lancer simultanément les tâches des noeuds "Prepare-contract" et "Formalize-disbursement" qui permettront respectivement au service juridique de préparer le contrat et à la cellule en charge de formaliser le décaissement de formaliser ledit décaissement.


III-1-6. Node "Prepare-contract"

Noeud de préparation du contrat. Comporte une tâche réalisée par le service juridique. Le contrat est crée et ajouté au ressources du Workflow.
La description de ce noeud dans le fichier jPDL du Workflow est la suivante :
Figure 8: Noeud 'Prepare-contract' dans le fichier jPDL du workflow

	<task-node name="Prepare-contract">
		<task name="ac:prepare-contract" swimlane="judicial-service"/>
		<transition to="Sign-contract-join" name="signContractJoin1"></transition>
	</task-node>

III-1-7. Node "Formalize-disbursement"

Noeud de formalisation du décaissement. Comporte une tâche réalisée par le service en charge de formaliser les décaissements.
La description de ce noeud dans le fichier jPDL du Workflow est la suivante :
Figure 9: Noeud 'Formalize-disbursement' dans le fichier jPDL du workflow

	<task-node name="Formalize-disbursement">
		<task name="ac:formalize-disbursement" swimlane="financial-service"/>
		<transition to="Sign-contract-join" name="signContractJoin2"></transition>
	</task-node>
Une fois que ces deux tâches sont réalisées, l'exécution du Workflow peut continuer au noeud Join "Sign-contract-join".


III-1-8. Node "Sign-contract-join"

Dans un Workflow jPDL, un noeud Join permet de marquer un point d'attente de l'exécution de plusieurs tâches en parallèle. Le moteur attendra que tous les noeuds de même parent arrivant à ce noeud soient terminés. Ce noeud comporte une unique transition par laquelle l'exécution va continuer.
La description dans le fichier jPDL est la suivante :
Figure 10: Noeud 'Sign-contract-join' dans le fichier jPDL du workflow

	<join name="Sign-contract-join">
		<transition to="Sign-contract"></transition>
	</join>

Le noeud de signature du contrat comporte une tâche réalisée par le comité de direction. Un membre du comité de direction invite le client à signer le contrat. L'exécution est ensuite déplacée sur le noeud d'établissement des chèques.


III-1-9. Node "Check-etablishment"

Noeud d'établissement des chèques. Ce noeud comporte une tâche réalisée par le directeur des affaires financières. Les différents chèques établis sont scannés et importés comme ressources dans l'instance du Workflow (Le paragraphe IV-4-1 traite de la chaîne de dématérialisation de notre tutorial).
L'exécution est ensuite déplacée vers le noeud d'approbation informatique.
Figure 11: Noeud 'Check-establishment' dans le fichier jPDL du workflow

	<task-node name="Check-establishment">
		<description>
			Documents are forwarded to the Administrative and Finance directions
			for the release of funds (signing checks, Orders of transfers, etc ...).
			The Chief of Financial Department validates the amount to be granted,
			then he sends one or more checks.
			The Direction receives all documents and validates them.
		</description>
		<task name="ac:check-establishment-signature" swimlane="daf"></task>
		<transition to="Computer-approbation" name="computerApprobation"></transition>
	</task-node>

III-1-10. Node "Computer-approbation"

Noeud d'approbation informatique. Comporte une tâche d'approbation informatique réalisée par un membre du comité d'octroi du crédit. Celui-ci doit faire les dernières opérations afin de clore le dossier du client.
La description de ce noeud dans le fichier jPDL du Workflow est la suivante :
Figure 12: Noeud 'Computer-approbation' dans le fichier jPDL du workflow

	<task-node name="Computer-approbation">
		<task name="ac:computer-approbation" swimlane="coc"></task>
		<transition to="End" name="end"></transition>
	</task-node>

III-1-11. Node "Client-info"

Noeud d'information du client. Comporte une tâche réalisée par l'agent en charge du crédit. Cette tâche consiste à informer le client sur l'état de sa demande. L'information peut être par téléphone ou email.
La description de ce noeud dans le fichier jPDL du Workflow est la suivante :
Figure 13: Noeud 'Client-info' dans le fichier jPDL du workflow

	<task-node name="Client-info">
		<description>
			Applications not approved are returned to  the agent who inform the
			customer. In case of loan rejected, a letter of regret is prepared.
			The agent makes a consultation and informs the customer about the reason
			for the rejection of his request.
		</description>
		<task name="ac:inform-client" swimlane="loan-agent"></task>
		<transition to="Contact-client" name="resume"></transition>
		<transition to="End" name="clientInfoEnd"></transition>
	</task-node>

III-2. Assignations des tâches

Assigner une tâche c'est designer l'acteur ou le pool d'acteurs qui réaliseront cette tâche. Toutes les tâches sont assignées. Nous allons voir comment les tâches du cas d'étude approbation du crédit sont assignées.

Dans le langage jPDL, l'assignation des tâches se fait à partir des rôles déclarés à travers des éléments swimlane:
Figure 14 : déclaration du rôle 'initiator'

	<swimlane name="initiator"/>

La déclaration ci-dessus (figure 14) permet de créer un rôle "initiator" qui par défaut sera joué par l'initiateur du Workflow c'est à dire l'agent du courrier. Ainsi une tâche assignée à "initiator" sera envoyée à l'initiateur du Workflow.
Les rôles suivants ont été créés:

- Rôle 'initiator'
Déclaration dans le fichier jPDL :
Figure 14 : déclaration du rôle 'initiator'

	<swimlane name="initiator"/>
- Rôle 'loan-service'
Le responsable du service crédit est emmené à jouer ce rôle.
Déclaration dans le fichier jPDL :
Figure 15 : déclaration du rôle 'loan-service'

	<swimlane name="loan-service">
		<assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
			<actor>#{bpm_assignee.properties['cm:userName']}</actor>
		</assignment>
	</swimlane>

Une expression EL est utilisée pour injecter l'acteur jouant ce rôle. La variable globale "bpm_assignee" contient une valeur qui représente l'acteur à qui la tâche est assignée.
On pourrait se demander où est le responsable du service crédit dans "bpm_assignee" dans le schéma (figure 15). En fait, lors du passage du noeud "Credit-receipt" au noeud "Quottation", la variable de scope processus "bpm_assignee" existe déjà et à pour valeur l'utilisateur responsable du service du crédit sélectionné par l'agent du courrier au noeud "Credit-receipt".
Cette variable est créée à travers le content model du task "ac:dispatch-application" du noeud "Credit-receipt" (cf. paragraphe IV-2-1): 

<mandatory-aspects>			
	<aspect>bpm:assignee</aspect>
</mandatory-aspects>

Cette aspect permet d'ajouter une propriété "bpm_assignee" au model de la tâche et de ce fait le Client Web génèrera un composant UI dans la page de la tâche pour la sélection du user à attribuer à la propriété. Le comportement ajouté par l'aspect créée la variable de scope processus nommé "bpm_assignee" et la rend accessible à tout le contexte du processus. Ceci permet ainsi d'utiliser la variable dans le fichier jPDL pour l'assignation du loan-service.

- Rôle 'loan-agent'
L'agent de crédit qui va étudier le dossier est emmené à jouer ce rôle.
Déclaration dans le fichier jPDL :
Figure 16 : déclaration du rôle 'loan-agent'

	<swimlane name="loan-agent">
		<assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
			<actor>#{bpm_assignee.properties['cm:userName']}</actor>
		</assignment>
	</swimlane>

La valeur de la variable globale "bpm_assignee" a changé et contient cette fois l'acteur agent du crédit.

- Rôle 'coc'
Déclaration dans le fichier jPDL :
Figure 17 : déclaration du pool d'acteur 'COC'

<swimlane name="coc">
        <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
            <pooledactors>#{ac_cocPool}</pooledactors>
        </assignment>    
</swimlane>

Cette fois (figure 17) ça n'est plus un acteur unique qui doit jouer un rôle mais un pool d'acteurs, c'est à dire un ensemble d'acteurs qui recevront la même tâche et devront travailler en collaboration pour la réaliser.
La variable "ac_cocPool" est une variable globale qui a été initialisée dans le noeud de début du Workflow. L'injection de l'ensemble des acteurs se fait avec une expression EL.

- Rôle 'codir'
Déclaration dans le fichier jPDL :
Figure 18 : déclaration du pool d'acteur 'CODIR'

	<swimlane name="codir">
        <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
            <pooledactors>#{ac_codirPool}</pooledactors>
        </assignment>    
	</swimlane>
- Rôle 'daf'
Directeur des affaires financières.
Déclaration dans le fichier jPDL :
Figure 19 : déclaration du pool d'acteur 'DAF'

	<swimlane name="daf">
        <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
            <pooledactors>#{ac_dafPool}</pooledactors>
        </assignment>    
	</swimlane>
- Rôle 'direction'
Déclaration dans le fichier jPDL :
Figure 20 : déclaration du pool d'acteur 'direction

	<swimlane name="direction">
        <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
            <pooledactors>#{ac_directionPool}</pooledactors>
        </assignment>    
	</swimlane>
- Rôle 'financial-service'
Service financier.
Déclaration dans le fichier jPDL :
Figure 21: déclaration du pool d'acteur 'financial-service'

	<swimlane name="financial-service">
        <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
            <pooledactors>#{ac_financialServicePool}</pooledactors>
        </assignment>    
	</swimlane>
- Rôle 'judicial-service'
Service juridique.
Déclaration dans le fichier jPDL :
Figure 22 : déclaration du pool d'acteur 'judicial-service'

	<swimlane name="judicial-service">
        <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
            <pooledactors>#{ac_judicialServicePool}</pooledactors>
        </assignment>    
	</swimlane>