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

• Start

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

<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.

<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).

<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.

<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.

<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.

    <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.

<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

<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.

    <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.

<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é.

<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é.

<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.

<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.