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


précédentsommairesuivant

III. Le workflow jBPM et sa transcription en modèle Alfresco (Task Model)

Il s'agit de :

  • réaliser le diagramme du workflow jBPM ;
  • modéliser les tâches et leurs assignations ;
  • ressortir la cartographie fonctionnelle associée au processus ;
  • traduire tous les nœuds du workflow jBPM dans le modèle Alfresco (Task Model).

III-A. Diagramme du workflow jBPM

Le diagramme de workflow jBPM ci-dessous a été fait avec Eclipse jPDL Graphical Designer.

Figure 1: Process design du workflow d'approbation du  crédit
Figure 1: Process design du workflow d'approbation du crédit

III-A-1. Nœuds du Processus jBPM

  • Start

Notre processus jBPM commence par un nœud de type start-state.

Figure 2: Définition Noeud Start
Sélectionnez
<start-state name="Start">
        <task name="wfcm:start" swimlane="initiator"></task>
        <transition to="CreditForm" name="trCreditForm"></transition>
</start-state>

Une tâche de nom 'wfcm:start' est définie au niveau de ce nœud. L'initiator est l'utilisateur qui démarre le workflow. La transition trCrediForm permet d'aller sur le nœud CreditForm.

  • CreditForm

C'est au niveau de ce nœud que sont faites les différentes saisies en vue de constituer le dossier de crédit.

Figure 3: Définition du noeud CreditForm
Sélectionnez
<task-node name="CreditForm">
    <task name="wfcm:creditForm" swimlane="initiator"></task>    
    <event type="node-enter">
        <action name="CreditFormActionHandler" 
            class="com.koossery.workflow...handler..CreditFormActionHandler">
        </action>        
    </event>        
    <transition to="Simulation" name="trSimulation"></transition>
</task-node>

Une tâche de nom 'wcfm:creditForm' est définie ici. C'est pendant l'exécution de cette tâche qu'est enregistré le formulaire avec ses pièces jointes. C'est toujours l'initiator qui agit sur cette tâche. Nous définissons un ActionHandler (cette notion sera expliquée plus tard: cf V-4V-4) CreditFormActionHandler pour récupérer les informations sur le nœud. Ces informations seront utilisées pour obtenir la position d'un dossier de crédit dans le workflow pendant la recherche. La transition trSimulation nous mène au nœud Simulation.

  • Simulation

Au niveau de ce nœud, nous avons défini l'action à exécuter pour simuler un dossier. Cette simulation permettra de dire si un dossier est RED (Rouge) ou GREEN (Vert).

Figure 4: Définition du noeud Simulation
Sélectionnez
<node name="Simulation">        
    <event type="node-enter">                        
        <action name="SimulationActionHandler" 
            class="com.koossery...workflow...handler...SimulationActionHandler">
        </action>
    </event>
    <transition to="ResultSimulation" name="trResultSimulation2"></transition>
</node>

Contrairement aux nœuds précédents qui sont tous de type 'task-node', on remarque que le nœud Simulation est simplement de type 'node': aucune tâche n'est définie ici. Le seul élément que nous avons défini est l'ActionHandler SimulationActionHandler: c'est lui qui exécute l'opération de simulation et retourne l'état du dossier de crédit (RED ou GREEN). Cet ActionHandler est exécuté à l'entrée du Node (event type = node-enter).

La transition trResultSimulation nous mène sur le nœud ResultSimulation.

  • ResultSimulation

Ce nœud permet de visualiser l'état du dossier de crédit passé en simulation.

Figure 5: Définition du noeud ResultSimulation
Sélectionnez
<task-node name="ResultSimulation">
    <task name="wfcm:resultSimulation" swimlane="initiator"></task>
    <event type="node-enter">
        <action name="ResultSimulationActionHandler" 
        class="com.koossery...workflow...handler...ResultSimulationActionHandler">
        </action>
    </event>
    <event type="node-leave">
        <action name="ResultSimulationActionHandler" 
        class="com.koossery...workflow...handler...ResultSimulationActionHandler">
        </action>
    </event>
        
    <transition to="ApprovalCommitte" name="trApprovalCommitte"></transition>
    <transition to="CreditForm" name="trCreditForm2"></transition>
    <transition to="End" name="trEnd"></transition>
</task-node>

Une tâche de nom wfcm:resultSimulation est définie ici. C'est l'initiator qui agit sur cette tâche. Cette tâche comporte deux variables qui sont: wfcm_statusDocument (variable sur l'état du document) et wcfm_piecesNumber (variable sur le nombre de pièces jointes). L'ActionHandler ResultSimulationActionHandler y a été défini. Il permet d'avoir des informations sur le nœud courant et met à jour la variable wcfm_piecesNumber.

La transition trApprovalCommitee nous mène au nœud ApprovalCommitte.

  • ApprovalCommitte

C'est le nœud de validation de la demande de crédit par le Comité d'Octroi de Crédit.

Figure 6: Noeud ApprovalCommitte
Sélectionnez
<task-node name="ApprovalCommitte">
    <task name="wfcm:approvalCommittee" swimlane="ApprovalMember"></task>
    <event type="node-enter">
      <action name="ChoixTransitionActionHandler" 
        class="com.koossery...workflow...handler...ChoixTransitionActionHandler" >
      </action>
    </event>
    <event type="node-leave">
      <action name="ChoixTransitionActionHandler" 
        class="com.koossery...workflow...handler...ChoixTransitionActionHandler" >
      </action>
    </event>
    <transition to="End" name="trEnd2"></transition>
    <transition to="forkApprovalCommitte" name="trFork"></transition>
</task-node>

Une tâche est définie ici : wfcm:approvalCommitte. Cette tâche comporte deux variables : wfcm_statusDocument (variable sur l'état du document) et wcfm_piecesNumber (variable sur le nombre de pièces jointes). Il faut être un utilisateur du groupe ApprovalMember pour pouvoir exécuter cette tâche. Nous avons défini un ActionHandler ApprovalCommitteActionHandler à l'entrée du nœud pour obtenir certaines informations nécessaires pour la recherche.

Lorsque le dossier est approuvé, le workflow continue par la transition forkApprovalCommitte et celle-ci nous mène vers le fork. Dans le cas contraire, le workflow se termine et un mail est envoyé au client pour lui signaler le rejet de son dossier.

  • Fork

Dans un workflow jPDL, un Fork est utilisé lorsqu'on veut réaliser des tâches en parallèle. La continuation de l'exécution du workflow au-delà du fork n'est possible que si les tâches effectuées en parallèle sont toutes achevées.

Figure 7: Noeud Fork
Sélectionnez
    <fork name="forkApprovalCommitte">
        <transition to="LegalService" name="trLegalService"></transition>
        <transition to="FinancialService" name="trFinancialService"></transition>
    </fork>

Les tâches qui seront effectuées en parallèle sont faites dans les task-node LegalService et FinancialService.

  • LegalService

C'est le nœud d'élaboration du contrat stipulant les engagements des deux parties. Ce contrat s'élabore sur la base des données provenant du dossier de crédit. La procédure d'élaboration consiste à générer un contrat pré rempli et à le réajuster par la suite.

Figure 8: Noeud LegalService
Sélectionnez
<task-node name="LegalService">
    <task name="wfcm:prepareContrat" swimlane="LegalMember"></task>
    <event type="node-enter">            
          <action name="LegalServiceActionHandler" 
          class="com.koossery...workflow...handler...LegalServiceActionHandler">
          </action>
    </event>
    <transition to="joinApprovalCommitte" name="trJoinLegalService"></transition>
</task-node>

Une tâche est définie au niveau de ce nœud: wfcm:prepareContrat. Cette tâche est assignée au groupe LegalMember. Nous avons défini un ActionHandler LegalServiceActionHandler pour la génération du contrat. Ce handler utilise le framework Jasper Report. Il permet aussi de recueillir des informations nécessaires à la recherche d'un dossier de crédit. La transition trJoinLegalService nous mène sur le nœud joinApprovalCommitte.

  • FinancialService
Figure 9: Noeud FinancialService
Sélectionnez
<task-node name="FinancialService">
    <task name="wfcm:prepareOutlay" swimlane="FinancialMember"></task>
    <event type="node-enter">     
          <action name="FinancialServiceActionHandler" 
          class="com.koossery...workflow...handler...FinancialServiceActionHandler">
          </action>
    </event>
    <transition to="joinApprovalCommitte" name="trJoinFinancialService"></transition>
</task-node>

Une tâche est définie au niveau de ce nœud : wfcm:prepareOutlay. Cette tâche est assignée au groupe FinancialMember. À l'entrée du nœud, le handler FinancialServiceActionHandler est appelé pour obtenir des informations importantes pour la recherche. La transition trJoinFinancialService nous mène au nœud joinApprovalCommitte.

  • Join

C'est lui qui marque la fin de réalisation des tâches simultanées précédemment citées dans notre workflow jBPM.

Figure 10: Noeud Join
Sélectionnez
    <join name="joinApprovalCommitte">
        <transition to="CreditContract"></transition>
    </join>

La transition trCreditContrat nous mène sur le nœud CreditContrat.

  • CreditContract

À ce niveau la direction administrative et financière contacte le client et les deux parties signent le contrat.

Figure 11: Noeud CreditContrat
Sélectionnez
<task-node name="CreditContract">
    <task name="wfcm:signContract" 
        swimlane="AdministrativeFinancialManagement"></task>
    <event type="node-enter">
        <action name="CreditContractActionHandler" 
          class="com.koossery...workflow...handler...DCreditContractActionHandler">
        </action>
    </event>
    <transition to="Archiving" name="trArchivingNode"></transition>
</task-node>

Ce nœud contient la tâche: wfcm:creditContrat. Cette tâche consiste à joindre le contrat signé et scanné comme pièce jointe au dossier de crédit. Cette tâche est assignée au groupe AdministrativeFinancialManagement. Nous avons défini un ActionHandler: CreditContratStateActionHandler. La transition trArchiving nous mène au nœud Archiving.

  • Archiving

C'est ici que le dossier de crédit est archivé.

Figure 12: Noeud Archiving
Sélectionnez
<task-node name="Archiving">
    <task name="wfcm:archiving" swimlane="AdministrativeFinancialManagement"></task>
    <event type="node-enter">
        <action name="ArchivingActionHandler" 
        class="com.koossery...workflow...handler...ArchivingActionHandler"></action>
    </event>
    <transition to="Payment" name="trPayment"></transition>
</task-node>

L'archivage est géré par le module record management de Alfresco. Ce module sera vu dans les prochaines itérations de cet article. Après l'archivage, on passe au nœud de Paiement.

  • Paiement

Le paiement consiste à remettre au client le crédit demandé.

Figure 13: Noeud Payement
Sélectionnez
<task-node name="Payment">
    <task name="wfcm:payment" swimlane="AdministrativeFinancialManagement"></task>
    <event type="node-enter">
        <action name="PaymentActionHandler" 
        class="com.koossery...workflow...handler...PaymentActionHandler"></action>
    </event>
    <transition to="End" name="trEnd3"></transition>
</task-node>

Lorsque le paiement est effectué, le workflow est terminé; ce qui nous conduit au nœud end-state.

  • End

Ce nœud marque la fin du workflow.

Figure 14: Noeud End
Sélectionnez
<end-state name="End"></end-state>

À l'entrée de ce nœud, on définit un ActionHandler EndActionhandler qui permettra de savoir à partir de la recherche si un dossier de crédit se trouve à la fin du workflow.

III-B. Assignation des tâches

Assigner une tâche c'est designer l'acteur ou le pool d'acteurs qui a le droit de réaliser ladite tâche. Dans le langage jPDL, l'assignation des tâches se fait à partir des rôles déclarés à travers l'élément swimlane.

Dans le cas du worflow crédit, les tâches sont assignées à un pool. Même l'initiator appartient à un pool bien précis. Ci-dessous quelques pools d'acteurs que nous avons définis dans notre workflow crédit.

  • AdviserCustomer

Ce pool est chargé de démarrer le workflow. C'est le pool auquel appartient le conseiller client ou encore l'acteur (initiator). Nous n'avons pas défini ce pool dans le process définition du workflow.

  • ApprovalMember
 
Sélectionnez
<swimlane name="ApprovalMember">
    <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
           <pooledactors>#{people.getGroup('GROUP_ApprovalMember')}</pooledactors>
    </assignment>    
</swimlane>

Pool d'acteurs faisant partie du comité d'octroi de crédit. Les acteurs de ce pool ont les autorisations pour intervenir au niveau de la tâche 'wfcm:approvalCommittee' se trouvant dans le nœud ApprovalCommitte.

  • LegalMember
 
Sélectionnez
< swimlane name="LegalMember">
    <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">    
        <pooledactors>#{people.getGroup('GROUP_LegalMember')}</pooledactors>
    </assignment>
</ swimlane >

Pool d'acteurs faisant partie du service juridique. Les acteurs de ce pool ont les autorisations pour intervenir au niveau de la tâche 'wfcm:prepareContrat' se trouvant dans le nœud LegalService.

  • FinancialMember
 
Sélectionnez
<swimlane name="FinancialMember">
      <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
           <pooledactors>#{people.getGroup('GROUP_FinancialMember')}</pooledactors>
      </assignment>    
</swimlane>

Pool d'acteurs faisant partie du service financier. Les acteurs de ce pool ont les autorisations pour intervenir au niveau de la tâche 'wfcm:prepareOutlay' se trouvant dans le nœud FinancialService.

  • AdministrativeFinancialManagement
 
Sélectionnez
<swimlane name="AdministrativeFinancialManagement">
      <assignment class="org.alfresco.repo.workflow.jbpm.AlfrescoAssignment">
           <pooledactors>#{people.getGroup('GROUP_AdministrativeFinancialManagement)}
            </pooledactors>
      </assignment>    
</swimlane>

Ce pool a les autorisations pour intervenir au niveau des tâches 'wfcm:creditContract', 'wfcm:archiving' et 'wfcm:payment' se trouvant dans les nœuds CreditContract, Archiving et Payment.

III-C. Transcription du workflow jBPM en Task Model Alfresco

Pour chaque tâche d'un task-node défini dans le workflow jBPM, on écrit sa modélisation dans Alfresco à l'aide du dictionnaire Alfresco. Nous avons les éléments suivants.

  • Les imports
 
Sélectionnez
<imports>
    <import uri="http://www.alfresco.org/model/dictionary/1.0" prefix="d"/>
    <import uri="http://www.alfresco.org/model/bpm/1.0" prefix="bpm"/>
</imports>
  • Le namespace
 
Sélectionnez
<namespaces>
          <namespace uri="http://www.koossery-tech.com/model/workflow/credit/1.0" 
                     prefix="wfcm"/>
</namespaces>

Ci-dessous les types correspondants aux différentes tâches du workflow :

  • wcfm :start
 
Sélectionnez
<type name="wfcm:start">
      <parent>bpm:startTask</parent>  
      <!-- this overrrides is used to remove the actions in the start workflow -->        
      <overrides>
       <property name="bpm:packageActionGroup">
           <default>void</default>
          </property>
       <property name="bpm:packageItemActionGroup">
               <default>void</default>
         </property>
      </overrides>        
</type>

Nous pouvons remarquer que ce type hérite du type de base 'bpm:startTask'. 'overrides' est utilisé pour définir des actions à afficher au niveau de l'interface utilisateur d'une tâche: les actions définies remplacent celles mises par défaut dans Alfresco. Dans notre cas nous avons déclaré deux types de groupe d'actions :

  • bpm:packageActionGroup : groupe d'actions définies sur les ressources. Dans notre cas, la valeur est void ;
  • bpm:packageItemActionGroup : groupe d'actions définies sur une ressource de la tâche correspondante. Dans notre cas, la valeur est void.

La valeur void est utilisée lorsqu'on ne définit aucune action dans le groupe d'action. Dans notre cas la tâche wfcm:start n'aura donc aucune action de groupe et aucune action sur une ressource.

La notion de groupe d'actions est traitée en profondeur plus tard : cf V-3V-3.

  • wfcm:creditForm
 
Sélectionnez
<type name="wfcm:creditForm">
    <parent>bpm:workflowTask</parent>
    <overrides>
        <property name="bpm:packageActionGroup">
            <default>add_credit_record_actions</default>
        </property>
        <property name="bpm:packageItemActionGroup">
            <default>edit_piece_content</default>
        </property>
    </overrides>          
</type>

Ce type hérite du type de base bpm:workflowTask.

La propriété 'bpm:packageActionGroup' a pour valeur le groupe d'actions 'add_credit_record_actions'. Ce groupe d'actions contient les actions permettant de créer un nouveau dossier de crédit. La propriété 'bpm:packageItemActionGroup' a pour valeur le groupe d'actions 'edit_piece_content'. Ce groupe d'actions contient les actions permettant d'éditer les métas-données des pièces jointes qui ont été introduites dans le dossier.

  • wcfm:resultSimulation
 
Sélectionnez
<type name="wfcm:resultSimulation">
    <parent>bpm:workflowTask</parent>
    <properties>
        <property name="wfcm:statusDocument">
            <type>d:text</type>
            <default>RED</default>                
        </property>
        <property name="wfcm:piecesNumber">
            <type>d:long</type>
            <default>0</default>
        </property>
        <property name="wfcm:annotation">
            <type>d:text</type>
        </property>                
    </properties>     
    <overrides>
        <property name="bpm:packageItemActionGroup">
            <default>edit_piece_content</default>
        </property>
    </overrides>               
</type>

Ce type hérite aussi du type de base 'bpm:workflowTask'. On définit les propriétés :

  • wfcm:statusDocument : cette propriété représente le statut du document RED ou GREEN ;
  • wcfm:piecesNumber : cette propriété représente le nombre de pièces jointes ;
  • wcfm:annotation : cette propriété est de type 'text' et contient le texte que le Conseiller client saisit en annotation lorsque le statut du document est RED.
  • wcfm:approvalCommittee
 
Sélectionnez
<type name="wfcm:approvalCommittee">
    <parent>wfcm:resultSimulation</parent>
    <overrides>
        <property name="bpm:packageItemActionGroup">
            <default>view_piece_content</default>
        </property>
    </overrides>               
</type>

Ce type hérite du type wcfm:resultSimulation et donc on hérite des mêmes propriétés que wcfm:resultSimulation.

  • wcfm:prepareContrat
 
Sélectionnez
<type name="wfcm:prepareContrat">
    <parent>bpm:workflowTask</parent>
    <overrides>
        <property name="bpm:packageItemActionGroup">
            <default>view_piece_content</default>
        </property>
    </overrides>
</type>

Ce type hérite du type de base bpm:workflowTask. Le groupe d'actions 'view_piece_content' a été défini pour afficher les métas-données d'une pièce jointe. Les métadonnées d'une pièce jointe ne seront visibles qu'en lecture seule.

  • wcfm:prepareOutlay
 
Sélectionnez
<type name="wfcm:prepareOutlay">
    <parent>bpm:workflowTask</parent>
    <overrides>
        <property name="bpm:packageItemActionGroup">
            <default>view_piece_content</default>
        </property>
    </overrides>
</type>
  • wcfm:creditContract
 
Sélectionnez
<type name="wfcm:creditContract">
    <parent>bpm:workflowTask</parent>            
</type>
  • wcfm:archiving
 
Sélectionnez
<type name="wfcm:archiving">
    <parent>bpm:workflowTask</parent>
    <overrides>
        <property name="bpm:packageItemActionGroup">
            <default>edit_achiving_item_actions</default>
        </property>
    </overrides> 
</type>
  • wcfm:payment
 
Sélectionnez
<type name="wfcm:payment">
    <parent>bpm:workflowTask</parent>
    <overrides>
        <property name="bpm:packageItemActionGroup">
            <default>view_credit_record_item_actions</default>
        </property>
    </overrides>
</type>

Le groupe d'action 'view_credit_record_item_actions' a été défini pour afficher en lecture seule le dossier de crédit archivé.


précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+