IdentifiantMot de passe
Loading...
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'implmentation d'un workflow avanc

Date de publication : 12 mai 2009


III. Modlisation (workflow) jBPM du processus mtier
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 tches


III. Modlisation (workflow) jBPM du processus mtier

Il s'agit de raliser le diagramme du Workflow, modliser les tches et leurs assignations.
On ressortira aussi la cartographie fonctionnelle associe au processus.


III-1. Diagramme du Workflow

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

Figure 2 : Process design du Workflow d'approbation du  crdit
Figure 2 : Process design du Workflow d'approbation du crdit


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


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

Il reprsente le noeud de rception de la demande du crdit du client.
Ce noeud possde une unique tche ralise par un agent du courrier. Cette tche consiste transmettre la demande au responsable du service du crdit.
Dans le cas o l'agent du courrier rceptionne la demande du client sous format papier, l'agent la numrise travers une chane de capture. La demande numrise est directement prise en compte dans le systme de GED. L'agent du courrier initialise alors le Workflow sur la demande numrise et ralise la prsente tche.

Le noeud "Credit-receipt" est un noeud de type "Start State", c'est dire qu'il reprsente le dbut du Workflow.
L'entre 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'excuter certaines actions suite des vnements sur les noeuds comme l'entre ou la sortie d'un noeud.
Dans le cas de la figure 3, une srie d'actions seront excutes ds que le jeton d'excution quitte le noeud (<event type="node-leave">). La principale action qui doit tre excute ds la sortie du noeud est l'Action Handler d'Alfresco AlfrescoJavaScript. Cette action permet l'excution du code JavaScript (ct serveur grce au moteur Rhino) prsent dans le fichier jPDL du Workflow.

Nous configurons aussi certaines variables globales :
-ac_cocPool: reprsente le pool d'acteurs membres du comit d'octroi de crdit;
-ac_codirPool: reprsente le pool d'acteurs membres du comit de direction;
-ac_dafPool: reprsente le pool d'acteurs membres de la direction des affaires financires ;
-ac_directionPool: reprsente le pool d'acteur membres de la direction;
-ac_financialServicePool: reprsente le pool d'acteurs du service des finances;
-ac_judicialServicePool: reprsente le pool d'acteurs membres du service juridique.

Dans ce noeud, l'agent du courrier doit envoyer la demande de crdit au service du crdit : cet envoi est matrialis par la transition nomme "dispatch".


III-1-2. Node "Quottation"

Noeud de cotation du dossier du crdit un agent du crdit ou au gestionnaire du client.
Ce noeud comporte une tche ralise par le responsable du crdit. La tche consiste choisir l' agent du crdit 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'chance (bpm_dueDate) et une priorit par dfaut (bpm_priority) ds l'instanciation de la tche (<event type="task-create"> ).

Ds que le Responsable de Crdit assigne un agent de crdit pour l'tude de dossier (<event type="task-assign"> ), une action est excute : grce JavaScript, un mail de notification va tre envoy au Responsable du crdit pour le confirmer l'assignation de la tche l'agent du crdit qui il a quott le dossier.
La transition nomme "send" permet de dplacer l'excution du Workflow au noeud "Contact-client".


III-1-3. Noeud Contact-client

Noeud de contact avec le client. Ce noeud possde une tche ralise par l'agent en charge crdit. Celui-ci est invit travers cette tche contacter le client. L'agent pose un certain nombre de questions au client. Sur la base des rponses du client, il cre (toujours dans cette tche) une fiche interne de la demande de crdit du client. Il peut soit rejeter la demande si son filtrage est ngatif ou envoyer la demande pour approbation au comit d'octroi. Ce choix est matrialis par les deux transitions nommes "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 crdit. Ce noeud est compos d'une tche ralise par un pool d'acteurs (les membres du groupe reprsent par la variable ac_cocPool).
Tous les membres de ce groupe reoivent la mme tche. L'un d'eux doit s'approprier la tche afin de modifier le systme en enregistrant la dcision du comit.
La dcision du comit sur la demande peut tre soit le rejet de la demande, soit l'approbation. Ce choix est matrialis par les deux transitions nommes "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 raliser des tches en simultan. La continuation de l'excution du Workflow un autre noeud ne se fera que si toutes les tches en simultan sont acheves.
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 nommes "prepareContract" et "formalizeDisbursement ", le moteur du Workflow va lancer simultanment les tches des noeuds "Prepare-contract" et "Formalize-disbursement" qui permettront respectivement au service juridique de prparer le contrat et la cellule en charge de formaliser le dcaissement de formaliser ledit dcaissement.


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

Noeud de prparation du contrat. Comporte une tche ralise par le service juridique. Le contrat est cre 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 dcaissement. Comporte une tche ralise par le service en charge de formaliser les dcaissements.
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 tches sont ralises, l'excution 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'excution de plusieurs tches en parallle. Le moteur attendra que tous les noeuds de mme parent arrivant ce noeud soient termins. Ce noeud comporte une unique transition par laquelle l'excution 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 tche ralise par le comit de direction. Un membre du comit de direction invite le client signer le contrat. L'excution est ensuite dplace sur le noeud d'tablissement des chques.


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

Noeud d'tablissement des chques. Ce noeud comporte une tche ralise par le directeur des affaires financires. Les diffrents chques tablis sont scanns et imports comme ressources dans l'instance du Workflow (Le paragraphe IV-4-1 traite de la chane de dmatrialisation de notre tutorial).
L'excution est ensuite dplace 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 tche d'approbation informatique ralise par un membre du comit d'octroi du crdit. Celui-ci doit faire les dernires oprations 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 tche ralise par l'agent en charge du crdit. Cette tche consiste informer le client sur l'tat de sa demande. L'information peut tre par tlphone 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 tches

Assigner une tche c'est designer l'acteur ou le pool d'acteurs qui raliseront cette tche. Toutes les tches sont assignes. Nous allons voir comment les tches du cas d'tude approbation du crdit sont assignes.

Dans le langage jPDL, l'assignation des tches se fait partir des rles dclars travers des lments swimlane:
Figure 14 : dclaration du rle 'initiator'

	<swimlane name="initiator"/>

La dclaration ci-dessus (figure 14) permet de crer un rle "initiator" qui par dfaut sera jou par l'initiateur du Workflow c'est dire l'agent du courrier. Ainsi une tche assigne "initiator" sera envoye l'initiateur du Workflow.
Les rles suivants ont t crs:

- Rle 'initiator'
Dclaration dans le fichier jPDL :
Figure 14 : dclaration du rle 'initiator'

	<swimlane name="initiator"/>
- Rle 'loan-service'
Le responsable du service crdit est emmen jouer ce rle.
Dclaration dans le fichier jPDL :
Figure 15 : dclaration du rle '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 utilise pour injecter l'acteur jouant ce rle. La variable globale "bpm_assignee" contient une valeur qui reprsente l'acteur qui la tche est assigne.
On pourrait se demander o est le responsable du service crdit dans "bpm_assignee" dans le schma (figure 15). En fait, lors du passage du noeud "Credit-receipt" au noeud "Quottation", la variable de scope processus "bpm_assignee" existe dj et pour valeur l'utilisateur responsable du service du crdit slectionn par l'agent du courrier au noeud "Credit-receipt".
Cette variable est cre 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 proprit "bpm_assignee" au model de la tche et de ce fait le Client Web gnrera un composant UI dans la page de la tche pour la slection du user attribuer la proprit. Le comportement ajout par l'aspect cre 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.

- Rle 'loan-agent'
L'agent de crdit qui va tudier le dossier est emmen jouer ce rle.
Dclaration dans le fichier jPDL :
Figure 16 : dclaration du rle '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 crdit.

- Rle 'coc'
Dclaration dans le fichier jPDL :
Figure 17 : dclaration 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 rle mais un pool d'acteurs, c'est dire un ensemble d'acteurs qui recevront la mme tche et devront travailler en collaboration pour la raliser.
La variable "ac_cocPool" est une variable globale qui a t initialise dans le noeud de dbut du Workflow. L'injection de l'ensemble des acteurs se fait avec une expression EL.

- Rle 'codir'
Dclaration dans le fichier jPDL :
Figure 18 : dclaration du pool d'acteur 'CODIR'

	<swimlane name="codir">
        <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
            <pooledactors>#{ac_codirPool}</pooledactors>
        </assignment>    
	</swimlane>
- Rle 'daf'
Directeur des affaires financires.
Dclaration dans le fichier jPDL :
Figure 19 : dclaration du pool d'acteur 'DAF'

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

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

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

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