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


 

IV. Implémentation de la solution dans Alfresco
IV-1. Modélisation des types de contenu ('Content Type model')
IV-1-1. Exemple de modélisation (Content Type model) de la Fiche de demande de crédit
IV-2. Modélisation des tâches du Workflow (Task Content Model)
IV-2-1. Exemple de modélisation (Task Content Model) de la tâche "dispatch-application"
IV-3. Implémentation du management des tâches dans la plateforme Alfresco
IV-3-1. Configuration du Client Web pour l'affichage des tâches
IV-3-2. Internationalisation I18N
IV-3-3. Réalisation d'un dashlet pour l'affichage des tâches relatives aux crédits dans le tableau de bord des utilisateurs
IV-4. Implémentation des fonctionnalités réalisées au sein du Workflow
IV-4-1. Implémentation de la fonctionnalité de Numérisation et de l'Archivage
IV-4-2. Implémentation de la fonctionnalité de création des fiches et des rapports
IV-4-3. Implémentation de la création d'un garant
IV-4-4. Implémentation de la création d'une garantie
IV-4-5. Implémentation de la création d'un document d'identification
IV-4-6. Implémentation de la création d'un contrat


IV. Implémentation de la solution dans Alfresco

La solution à été implémentée avec Alfresco. Alfresco fournit un mécanisme conceptuel et des APIs pour la réalisation du BPM sous forme d'une application web J2EE.
Le diagramme d'activités préconisé par le Centre de Compétence Alfresco/jBPM de Koossery Technology pour l'implémentation d'un workflow se résume au tableau ci-dessous:

Figure 23 : Diagramme d'activités de l'implémentation d'un Workflow préconisé par le Centre de Compétence Alfresco/jBPM de Koossery Technology
Figure 23 : Diagramme d'activités de l'implémentation d'un Workflow préconisé par le Centre de Compétence Alfresco/jBPM de Koossery Technology

Nous allons appliquer ce diagramme d'activités sur le cas d'étude du Workflow d'approbation du crédit.


IV-1. Modélisation des types de contenu ('Content Type model')

Ci-dessous le schéma du modèle d'entité de l'application :

Figure 24 : Data model de la demande de crédit
Figure 24 : Data model de la demande de crédit

Le content type model de chaque entité du schéma ci-dessus (figure 24) doit être écrit à l'aide du dictionnaire de données Alfresco. Le paragraphe IV-1-1 montre le content model de l'entité "creditRecordApplication" (Fiche de demande de crédit).


IV-1-1. Exemple de modélisation (Content Type model) de la Fiche de demande de crédit

Figure 25 : Content Model de la fiche de demande de crédit

<!-- Credit Application Record -->
		<type name="creditApprobation:creditRecordApplication">
			<title>Credit application record</title>
			<parent>cm:folder</parent>			
			<properties>
				<property name="creditApprobation:creditNumber">
					<title>Credit number</title>
					<type>d:text</type>
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:creditProduct">
					<title>Credit product</title>
					<type>d:text</type>			
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:applicationDate">
					<title>Application date</title>
					<type>d:date</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:amount">
					<title>Amount</title>
					<type>d:float</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:annualInterestRate">
					<title>Annual interest rate</title>
					<type>d:float</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:nbOfInstallmentPayment">
					<title>Number of Installment Payment</title>
					<type>d:long</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:installmentType">
					<title>Installment type</title>
					<type>d:text</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:interestCalculationMethod">
					<title>Interest Calculation Method</title>
					<type>d:text</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:lastMaturityCapital">
					<title>Last maturity capital</title>
					<type>d:float</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:creditLine">
					<title>Credit line</title>
					<type>d:text</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:agent">
					<title>Agent</title>
					<type>d:text</type>					
					<mandatory>true</mandatory>
				</property>
				<property name="creditApprobation:interestCalculationByDay">
					<title>interest calculation by day</title>
					<type>d:boolean</type>					
					<mandatory>false</mandatory>
				</property>
				<property name="creditApprobation:agreedPrepaymentOfInterest">
					<title>Agreed sum for prepayment of interest</title>
					<type>d:boolean</type>					
					<mandatory>false</mandatory>
				</property>
				<property name="creditApprobation:deductInterestAtOutlay">
					<title>Deduct interest at outlay</title>
					<type>d:boolean</type>					
					<mandatory>false</mandatory>
				</property>
				<property name="creditApprobation:interestDuringTheGracePeriod">
					<title>Interest during the grace period</title>
					<type>d:boolean</type>					
					<mandatory>false</mandatory>
				</property>
				<property name="creditApprobation:stagger">
					<title>To stagger</title>
					<type>d:boolean</type>					
					<mandatory>false</mandatory>
				</property>
			</properties>
			<associations>
				<child-association name="creditApprobation:installments">
					<target>
						<class>creditApprobation:installment</class>
						<mandatory>false</mandatory>
						<many>true</many>
					</target>
				</child-association>
				<child-association name="creditApprobation:guarantors">
					<target>
						<class>creditApprobation:guarantor</class>
						<mandatory>false</mandatory>
						<many>true</many>
					</target>
				</child-association>
				<child-association name="creditApprobation:collaterals">
					<target>
						<class>creditApprobation:collateral</class>
						<mandatory>false</mandatory>
						<many>true</many>
					</target>
				</child-association>
				<child-association name="creditApprobation:creditAppClient">
					<target>
						<class>creditApprobation:client</class>
						<mandatory>false</mandatory>
						<many>false</many>
					</target>
				</child-association>

			</associations>
		</type>

IV-2. Modélisation des tâches du Workflow (Task Content Model)

Au paragraphe III-1 nous avons vu le design jBPM du processus.

Chaque tâche ou noeud de ce BPM design sera modélisé avec le dictionnaire de données Alfresco.

Le paragraphe IV-2-1 montre la modélisation de la tâche "dispatch application" réalisée par l'agent du courrier et consistant à envoyer la demande de crédit numérisée du client au responsable du crédit. Ce modèle est utilisé par le Client Web de la plateforme Alfresco pour la construction de la vue de présentation de la tâche.


IV-2-1. Exemple de modélisation (Task Content Model) de la tâche "dispatch-application"

Les tâches sont définies dans le modèle comme type de contenu: en effet les entités tâches sont manipulées dans le JCR exactement comme tout autre type de contenu.
Figure 26 : Content model de la tâche 'dispatch-application' 

		<type name="ac:dispatch-application">
			<parent>bpm:startTask</parent>
			
			<properties>
				<property name="ac:notifyMe">
					<type>d:boolean</type>
					<default>false</default>
				</property>
			</properties>
			
			<mandatory-aspects>
				<aspect>bpm:assignee</aspect>
			</mandatory-aspects>
			
			<!-- Custom aspects may be added to collect any arbitrary 
				number of people / groups. -->
		</type>

Comme on peut le voir (figure 26), ce modèle hérite du modèle "bpm:startTask" qui est le modèle de base des tâches d'initiation des worklflows BPM.
Cette tâche est la première tâche qui doit être réalisée lors que le Workflow est initialisé.
Le modèle défini une propriété ("notifyMe") de type booléen. Cette propriété sera affichée à l'interface utilisateur sous forme de case à cocher et permettra de notifier par email l'agent du courrier de l'envoi de la demande de crédit au responsable de crédit.


IV-3. Implémentation du management des tâches dans la plateforme Alfresco

Une fois le modèle des tâches réalisé, il faut effectuer un certain nombre d'opérations afin que les tâches puissent être accessibles dans le tableau de bord des utilisateurs. Ces opérations sont dans l'ordre :
  -  configuration du client web pour l'affichage des tâches
  -  réalisation des dashlet relatives au tableau de bord. Un dashlet est un composant UI Alfresco qui permet d'afficher des informations dans une zone du tableau de bord des utilisateurs


IV-3-1. Configuration du Client Web pour l'affichage des tâches

La configuration du client web (l'application Web de la plateforme Alfresco) permet de préciser comment vont être affichés les composants UI pour la saisie des données. La configuration du client web se fait dans le fichier "web-client-config-custom.xml". La configuration du client web pour l'affichage de la vue de la tache de type "dispatch-application" est la suivante :
Figure 27 : Configuration du Client Web de la tâche ac:dispatch-application

	<config evaluator="node-type" condition="ac:dispatch-application" replace="true">
		<property-sheet>
			<separator name="sep1" display-label-id="general"
							component-generator="HeaderSeparatorGenerator" />
			<show-property name="bpm:description" component-generator="TextAreaGenerator" />
			<show-property name="bpm:priority" />
			<show-property name="bpm:dueDate" />
			<show-property name="ac:notifyMe" />
			<separator name="sep2" display-label-id="responsable_service_credit"
							component-generator="HeaderSeparatorGenerator" />
			<show-association name="bpm:assignee"/>
		</property-sheet>
	</config>

IV-3-2. Internationalisation I18N

L'internationalisation permet d'afficher la vue de la tâche dans la langue du l'utilisateur. La configuration de l'internationalisation relative à la tâche consiste à définir le bundle I18N des propriétés de la tâche définies dans le content model. En prenant l'exemple de la tâche d'initialisation du Workflow (la tâche "ac:dispatch-application"), une entrée doit être définie pour la propriété "notifyMe" et une autre pour l'aspect "bpm:assignee".
La figure 28 montre les entrées de ces deux éléments dans le bundle I18N.
Figure 28 : I18N de la tâche ac:dispatch-application

ac_workflowmodel.type.ac_dispatch-application.title=Acheminer une demande de crédit vers le service du crédit.
ac_workflowmodel.type.ac_dispatch-application.description=Acheminer une demande de crédit vers le service du crédit.

...
# Associations

ac_workflowmodel.association.ac_assignee.title=Agent en charge du crédit
ac_workflowmodel.association.ac_assignee.description=Agent en charge du crédit

Dans notre cas d'étude, nous avons défini la ressource bundle d'internationalisation du Workflow dans le fichier de propriétés : "approbationcreditworkflow-model.properties".


IV-3-3. Réalisation d'un dashlet pour l'affichage des tâches relatives aux crédits dans le tableau de bord des utilisateurs

Un dashlet est un composant UI Alfresco qui permet d'afficher des informations dans une zone du tableau de bord des utilisateurs.
La réalisation du dashlet est classique et nécessite des configurations XML et du code java. Nous avons réalisé un dashlet Alfresco pour afficher les tâches en attente de traitement par les utilisateurs dans leur tableau de bord.
La figure 29 montre l'affichage des tâches d'un utilisateur dans la dashlet des tâches de demande de crédit.

Figure 29 : Dashlet des tâches de demande de crédit
Figure 29 : Dashlet des tâches de demande de crédit

Cette figure montre un travail à faire "Quotter dossier demande crédit" dans le dashlet "Demande(s) de crédit en attente de traitement".
Créer un dashlet, c'est :
  -  le configurer dans le fichier "web-client-config-custom.xml"
  -  définir la page jsf du dashlet
  -  définir le backed-bean de la page jsf ci-dessus
  -  définir la dashlet dans la liste des dashlet à afficher par défaut

- 1 . Le configurer dans le fichier "web-client-config-custom.xml":
Figure 30 : Configuration du dashlet des tâches de demande de crédit

<dashlet 	id="loan-application-to-threat" 
			label-id="my_loan_to_treat_title" 
			description-id="my_tasks_todo_desc"
  			jsp="/jsp/extension/workflow/custom-tasks-todo-dashlet.jsp" 
			allow-narrow="false" />

Dans cette configuration (figure 30), "my_loan_to_treat_title" représente l'entrée I18N du label de dashlet qui est affiché à l'interface utilisateur (dans notre cas de figure, il s'agit du label "Demande(s) de crédit en attente de traitement").
La JSP du dashlet est la JSP custom-tasks-todo-dashlet.jsp.

- 2 . Définir la page jsf du dashlet:
La JSP de notre cas d'étude est la JSP "custom-tasks-todo-dashlet.jsp". Cette JSP permet de lister les tâches assignées à l'utilisateur connecté.

- 3 . Définir le Backed-Bean :
Le Backed Bean est le managed Bean de la dashlet. C'est ce Bean qui est référencé dans la JSP du dashlet à travers les expressions EL.

- 4 . Définir la dashlet dans la liste des dashlets à afficher par défaut lorsque les utilisateurs se connectent:
La liste par default des dashlets constitue les dashlets qui vont être affichées dans l'ordre défini lorsque l'utilisateur se connecte. Dans notre cas d'étude, la liste est la suivante :
Figure 31 : La liste des dashlets à afficher par défaut

<default-dashlets>
            <dashlet id="loan-application-to-threat" />
            <dashlet id="tasks-todo" />
            <dashlet id="pooled-tasks" />
            <dashlet id="myspaces-webscript" />
</default-dashlets>

Cette liste place la dashlet des demandes de crédit en tête, puis la dashlet de base du noyau Alfresco (qui affichera les tâches autres que celle relatives au crédit), puis les tâches du Pot Commun de l'utilisateur et en fin le composant web Script AJAX qui affiche l'arborescence des dossiers du repository.


IV-4. Implémentation des fonctionnalités réalisées au sein du Workflow

Les principales fonctions sont :

  -  Numérisation et archivage de la demande manuscrite du crédit
  -  Création de la fiche interne de demande de crédit
  -  Création d'un garant
  -  Création d'une garantie
  -  Création d'un document d'identification
  -  Création du contrat

Le Workflow doit s'interfacer avec le système d'information de l'entreprise notamment pour invoquer certains services existants ou à créer.

Cet interfaçage peut être réalisé via divers moyens : les web services, ou carrément un ESB (Mule ESB) en particulier dans le cadre de l'orchestration de processus hétérogènes.
L'interfaçage avec le SI est en dehors de l'objet de ce document.
Dans les paragraphes qui suivent, nous verrons brièvement comment chaque fonctionnalité a été implémentée.


IV-4-1. Implémentation de la fonctionnalité de Numérisation et de l'Archivage

Une chaîne de numérisation est une infrastructure logicielle et matérielle mise en oeuvre pour automatiser la chaîne "Scanner - OCR - Indexage - Archivage".
Le scanner produit une image du document. La reconnaissance de caractère est effectuée sur l'image afin de générer un document Texte ou PDF. Pour faciliter les recherches, l'indexage est également fait. De nos jours, presque tous les scanners réalisent l'OCR et produisent des documents textes (Word, RTF) et des documents au format PDF. Néanmoins, il reste impossible de réaliser des traitements tels que le dimensionnement d'image, les corrections, la lecture automatique de document (LAD), etc..

Pour adresser les traitements complexes sur le document numérisé, Koossery Technology utilise deux technologies propriétaires: Kofax et eCopy.

Pour des solutions des chaînes simples, Koossery Technology met en oeuvre la chaîne ci-dessous:
Figure 32 : chaîne de numérisation simple

<Scanner OCR - Bibliothèque Tiger OCR (Optionnelle) - CIFS - Extraction de métadonnées - 
							- Indexage - GED />

La bibliothèque Tiger OCR est une librairie JAR qui permet de réaliser de l'OCR dans une application JAVA sur une zone donnée de l'image. Nous utilisons cette librairie pour réaliser la reconnaissance de caractère sur des Chèques Bancaire, des factures etc..
Pour notre cas d'étude, nous avons monté la chaîne de numérisation simple permettant de numériser les demandes manuscrites des clients et de les intégrer automatiquement et directement dans un espace du service du courrier de la GED.
La chaîne prend en compte l'extraction de métadonnées et l'indexage automatique.


IV-4-2. Implémentation de la fonctionnalité de création des fiches et des rapports

La fiche de demande de crédit est un gros formulaire de saisie de données sectionné en étapes. Les informations d'une fiche de demande de crédit sont saisies à travers un Wizards Alfresco.

Un Wizard est un composant UI qui permet de saisir des informations en étapes. Nous avons réalisé la saisie des fiches de demande de crédit en ce servant du mécanisme conceptuel des Wizards d'Alfresco.

Créer un Wizard Alfresco c'est faire des configurations XML et écrire du code JAVA. La configuration XML concerne la configuration du Client Web (l'application Web) pour l'affichage des étapes du Wizard et l'écriture du code consiste à coder le Backed-Bean (Managed Bean) du Wizard.

La réalisation des wizard Alfresco fera l'objet d'une publication ultérieure.
Nous allons néanmoins brièvement voir comment développer un Wizard Alfresco à travers l'exemple de la fiche de demande de crédit.
Voici les étapes suivies pour créer le Wizard de la fiche de demande de crédit :

  -  configuration du wizard dans le client web
  -  écrire les pages jsf des différentes étapes d'attribution du crédit
  -  mise en place des bundles d'internationalisation i18n
  -  définition du backed-bean du wizard

- 1 : Configuration du Wizard dans le Client web (web-client-config-custom.xml)
Figure 33 : Configuration du Wizard de la fiche de demande de crédit

<config>
      <wizards>
         <wizard name="createCreditRecordApplication" 
         	managed-bean="CreateCreditRecordAppWizard"
         	title-id="create_credit_record_app_content_title" 
         	description-id="create_credit_record_app_content_desc"
         	icon="/images/icons/new_content_large.gif">
         	<step name="partie1" title-id="credit_write_part1"
         						description-id="create_credit_record_app_step1_desc">
         		<page path="/jsp/extension/content/create-credit-record-app-wizard/part1.jsp"
         			title-id="create_credit_record_app_content_step1_title"
         			description-id="create_credit_record_app_content_step1_desc"
         			instruction-id="default_instruction" />
         	</step>
         	<step name="partie2" title-id="credit_write_part2"
         			description-id="create_credit_record_app_step2_desc">
         		<page path="/jsp/extension/content/create-credit-record-app-wizard/part2.jsp"
         			title-id="create_credit_record_app_content_step2_title"
         			description-id="create_credit_record_app_content_step2_desc"
         			instruction-id="default_instruction" />
         	</step>
         	<step name="partie3" title-id="credit_write_part3" <br/>
         			description-id="create_credit_record_app_step3_desc">
         		<page path="/jsp/extension/content/create-credit-record-app-wizard/part3.jsp"
         			title-id="create_credit_record_app_content_step3_title"
         			description-id="create_credit_record_app_content_step3_desc"
         			instruction-id="default_instruction" />
         	</step>
         </wizard>
      </wizards>
</config>

Nous pouvons remarquer que ce Wizard est composé de 3 étapes (partie1, partie2 et partie3). Chaque étape est une vue JSF (les éléments page) qui peut contenir d'autres Wizards ou des dialogs Alfresco. Nous verrons ce que c'est qu'un dialog Alfresco et brièvement comment le réaliser.
Le nom du Bean Managé du Wizard est "CreateCreditRecordAppWizard" et il est configuré dans le ficher "faces-config-custom.xml". Ce même Bean est utilisé comme Bean Managed des vues des étapes (step) du Wizard.

- 2 : Définition des pages jsf des étapes
L'enchaînement des pages du Wizard est réalisé par le Wizard Framework du noyau de la plateforme Alfresco. Celui-ci utilise la configuration de la figure30 pour savoir quelle vue d'étape il faut afficher. Dans notre cas, nous avons 3 JSP pour les trois étapes : part1.jsp, part2.jsp et part3.jsp.

- 3 : Définition de l'I18N du Wizard
Il s'agit de définir les entrées "title-id" et "description-id" du Wizard dans le bundle.

- 4 : Création du Bean Managé du Wizard
C'est la dernière opération. Il s'agit d'écrire le code java du Bean Managé du Wizard. Le Bean managé d'un Wizard est classique. Toutes les méthodes correspondants aux actions "suivant" , "précédent", "modifier les labels des boutons", "générer de nouveaux boutons", "enregistrer les données saisies", etc.. doivent être implémentées.


IV-4-3. Implémentation de la création d'un garant

Un garant est une personne physique qui se porte garant pour un crédit. L'entité garant est un type de contenu défini dans le modèle. Les garants sont choisis ou créés lors de la création de la fiche de demande de crédit. Nous avons réalisé la création d'un garant grâce au Framework Conceptuel Dialog d'Alfresco. La réalisation des Dialogs Alfresco fera l'objet d'une publication ultérieure. Néanmoins, nous allons présenter brièvement un petit exemple.

Créer un Dialog Alfresco c'est faire des configurations XML et écrire du code JAVA. La configuration XML concerne la configuration du Client Web pour l'affichage du dialog et l'écriture du code JAVA concerne l'écriture du Bean managé du dialog. Voici les étapes suivies pour créer le Dialog de création des garants :

  -  configuration du Dialog dans le client web
  -  écrire les pages jsf des différentes étapes d'attribution du crédit
  -  mise en place des bundles d'internationalisation i18n
  -  définition du backed-bean du wizard

- 1 : Configuration du Dialog dans le Client web (web-client-config-custom.xml)
Figure 34 : Configuration du Client Web du Dialog de création des garants

<dialog name="create_guarantor_dialog" 
			page="/jsp/extension/content/create-guarantor-dialog.jsp" 
			managed-bean="CreateGuarantorDialog"
			icon="/images/extension/icons/new_person.gif" 
			title-id="create_guarantor_dialog_title" 
			description-id="create_guarantor_description_dialog">                
</dialog>

Les éléments constitutifs du Dialog Alfresco sont : la JSP du dialog (dans notre cas il s'agit de la JSP create-guarantor-dialog.jsp), le Bean managé (dans notre cas il s'agit du Bean CreateGuarantorDialog), l'icône (dans notre cas il s'agit de l'image new_person.gif), du titre et de la description.

- 2 : Définition de la JSP du Dialog
Il s'agit d'écrire la page JSP create-guarantor-dialog.jsp. Les balises (tags librairies) JSF sont utilisées pour la construction de la JSP. Les Expressions EL sont utilisées pour le lien avec le Bean Managé.

- 3 : Définition de l'I18N du Dialog
L'internationalisation du dialog se réduit aux entrées "title-id" et "description-id" de la configuration du dialog.

- 4 :Création du Bean Managé du Dialog
C'est la dernière opération. Il s'agit d'écrire le code java du Bean Managé du Dialog. Le Bean managé d'un Dialog est classique. Certaines méthodes doivent être implémentées pour les actions "annuler" et "Ok", "modifier les labels des boutons", "générer de nouveaux boutons", "enregistrer les données saisies", etc..


IV-4-4. Implémentation de la création d'une garantie

Une garantie est aussi un type de contenu configuré dans le content model. La création des garanties se fait également à partir du Framework Dialog d'Alfresco. Bien vouloir ce reporter à la section (paragraphe IV-4-3) d'implémentation de la création d'un garant pour les détails techniques.


IV-4-5. Implémentation de la création d'un document d'identification

Un document d'identification est aussi un type de contenu configuré dans le content modèle. La création des documents d'identification se fait également à partir du Framework Dialog d'Alfresco. Bien vouloir ce reporter à la section (paragraphe IV-4-3) d'implémentation de la création d'un garant pour les détails techniques.


IV-4-6. Implémentation de la création d'un contrat

Un contrat est défini dans notre application comme un type de contenu. La différence de ce modèle de création avec les autres est que, le contrat n'est pas saisi mais plutôt créé par interfaçage avec le Système d'Information de l'établissement de crédit.

L'interfaçage de l'application ECM/BPM d'approbation de crédit avec le SI de l'établissement de crédit est réalisé via l'esb Mule ESB.

L'aspect interfaçage avec le Système d'Information de l'établissement de crédit est en dehors de l'objet de ce document.