• Start

Notre processus jBPM commence par un noeud 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 noeud. L'initiator est l'utilisateur qui démarre le workflow. La transition trCrediForm permet d'aller sur le noeud CreditForm.

• CreditForm

C'est au niveau de ce noeud 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 noeud. 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 noeud Simulation.

• Simulation

Au niveau de ce noeud 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 noeuds précédents qui sont tous de type 'task-node', on remarque que le noeud 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 noeud ResultSimulation.

• ResultSimulation

Ce noeud 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 noeud courant et met à jour la variable wcfm_piecesNumber.

La transition trApprovalCommitee nous mène au noeud ApprovalCommitte.

• ApprovalCommitte

C'est le noeud 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 noeud 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 noeud 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 noeud: 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 noeud 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 noeud : wfcm:prepareOutlay. Cette tâche est assignée au groupe FinancialMember. A l'entrée du noeud, le handler FinancialServiceActionHandler est appelé pour obtenir des informations importantes pour la recherche. La transition trJoinFinancialService nous mène au noeud 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 noeud CreditContrat.

• CreditContract

A 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 noeud 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 noeud 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 noeud de Payment.

• Payment

Le payement 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 payement est effectué, le workflow est terminé; ce qui nous conduit au noeud end-state.

• End

Ce noeud marque la fin du workflow.

<end-state name="End"></end-state>

A l'entrée de ce noeud 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.