JBoss jBPM est un moteur de gestion du processus métier pour tout environement Java SE ou EE. jBPM vous permet de vous représenter un processus métier ou une intéraction utilisateur comme un graphe de noeud représentant les états d'attente, les décisions, les tâches, les pages web, etc. Le graphe est défini en utilisant un simple et facile à lire dialecte XML appelé jPDL, et peut être édité et visualisé graphiquement en utilisant un plugin d'Eclipse. jPDL est un language extensible et il est adapté pour une grande variété de problème, depuis la définition de l'enchainement de page d'une application web jusqu'à la gestion des traditionnels enchainement de tâches, tout cela dans un esprit d'orchestration des services dans un environnement SOA.

Les applications Seam utilise jBPM pour deux types de problèmes différents:

Ne vous laisser pas embrouillés par ces deux choses ! Elle fonctionne à des niveaux ou de granularité très différents. L'enchainement de page , de conversation et des tâches toutes ce réfèrent à une seule intéraction avec un seul utilisateur. Un processus métier s'étends sur plusieurs tâches. En outre, les deux applications de jBPM sont totalement ortogonales. Vous pouvez les utiliser ensemble ou indépendamment ou pas du tout.

Vous n'avez pas besoin de connaitre jDPL pour utiliser Seam. Si vous êtes parfaitement heureux de définir l'enchainement de page en utilisant JSF ou les règles de navigation de Seam, et si votre application est plus à connatation données qu'à connotation processus, vous n'avez probablement pas besoin de jBPM. Mais nous allons trouver que penser l'interaction utilisateur en terme de représentation graphique bien définie nous aide à construire des applications plus robustes.

8.1. L'enchainement de page dans Seam

Il y a deux façon de définir un enchainement de page dans Seam:

• Utiliser les règles de navigation de JSF ou de Seam - le modèle de navigation sans état

• Utiliser le jPDL - le modèle de navigation avec état

De très simple applications n'ont seulement besoin que du modèle de navigation sans état. Des applications très complexes auront besoins des deux modèles à des endroits différents. Chaque modèle a ses forces et ses faiblesses!

8.1.1. Les deux modèles de navigation

Le modèle sans état défini une relation depuis un groupe de résultat nomé et la logique d'un évènement directement dans la page résultat de la vue. Les règles de navigation sont entièrement inconnues des autres états inclus dans l'application à part de la page qui a été la source de l'évènement. Cela signifie que les méthodes d'écoute de l'action doivent parfois prendre la décicsion à propos de l'enchainement de page, alors qu'elles n'ont accès qu'à l'état courrant de l'application.

Voici un exemple de définition d'un enchainement de page en utilisant les règles de navigation de JSF:

<navigation-rule>

    <from-view-id

>/numberGuess.jsp</from-view-id>

        

    <navigation-case>

        <from-outcome

>guess</from-outcome>

        <to-view-id

>/numberGuess.jsp</to-view-id>

        <redirect/>

    </navigation-case>



    <navigation-case>

        <from-outcome

>win</from-outcome>

        <to-view-id

>/win.jsp</to-view-id>

        <redirect/>

    </navigation-case>

        

    <navigation-case>

        <from-outcome

>lose</from-outcome>

        <to-view-id

>/lose.jsp</to-view-id>

        <redirect/>

    </navigation-case>



</navigation-rule

>

Voici un exemple de définition d'un enchainement de page en utilisant les règles de navigation de Seam:

<page view-id="/numberGuess.jsp">

        

    <navigation>

        <rule if-outcome="guess">

            <redirect view-id="/numberGuess.jsp"/>

        </rule>

        <rule if-outcome="win">

            <redirect view-id="/win.jsp"/>

        </rule>

        <rule if-outcome="lose">

            <redirect view-id="/lose.jsp"/>

        </rule>

    </navigation>



</page

>

Si vous trouvez que les règles de navigation beaucoup trop verbeuses, vous pouvez retourner l'identifiant de la vue directement depuis la méthode d'écouteur d'action:

public String guess() {

    if (guess==randomNumber) return "/win.jsp";

    if (++guessCount==maxGuesses) return "/lose.jsp";

    return null;

}

Notez que cela résulte dans une redirection. Vous pouvez même spécifier les paramètres à utiliser pour la redirection:

public String search() {

    return "/searchResults.jsp?searchPattern=#{searchAction.searchPattern}";

}

Le modèle avec état défini un groupe de transition entre un groupe d'état de l'application logique et nomé. Dans ce modèle, il est possible d'exprimer l'enchainement des interactions utilisateur entièrement dans une définition d'enchainement de page en jPDL et écrire les méthode d'écouteur d'action qui sont complètement ignare du flot d'interaction.

Voici un exemple de définition du flot de page en utilisant jPDL:

<pageflow-definition name="numberGuess">

    

   <start-page name="displayGuess" view-id="/numberGuess.jsp">

      <redirect/>

      <transition name="guess" to="evaluateGuess">

              <action expression="#{numberGuess.guess}" />

      </transition>

   </start-page>

   

   <decision name="evaluateGuess" expression="#{numberGuess.correctGuess}">

      <transition name="true" to="win"/>

      <transition name="false" to="evaluateRemainingGuesses"/>

   </decision>

   

   <decision name="evaluateRemainingGuesses" expression="#{numberGuess.lastGuess}">

      <transition name="true" to="lose"/>

      <transition name="false" to="displayGuess"/>

   </decision>

   

   <page name="win" view-id="/win.jsp">

      <redirect/>

      <end-conversation />

   </page>

   

   <page name="lose" view-id="/lose.jsp">

      <redirect/>

      <end-conversation />

   </page>

   

</pageflow-definition

>

Il y a deux choses que nous pouvons noter immédiatement ici:

• Les règles de navigation JSF/Seam sont beaucoup plus simples. (Néanmoins, cela masque le fait que le code Java sous-entendu est plus complexe.)

• Le jPDL rend les interactions utilisateurs immédiatement compréhensible, sans qu'il soit même nécéssaire de lire le code JSP ou Java.

En plus, le modèle à état est plus constraint. Pour chaque état logique (chaque étape dans l'enchainement de page), il y a un contrainte sur un groupe de transition possible vers les autres états. Le modèle sans état est un modèle ad hoc qui est efficace pour la navigation relativement sans contrainte, libre de formulaire quand l'utilisateur décide là ou il/elle veux aller ensuite, pas l'application.

La distinction entre navigation avec/sans état est assez similaire à la traditionnel vue de l'intération avec/sans modèle. Maintenant, les applications de Seam ne sont pas en général modale au sens strict de ce mot - en fait, éviter la fonctionnalité modal de l'application est une des raisons principale pour avoir les conversations! Malgré tout, les applications Seam peuvent être, et souvent le sont, modale au niveau de conversation particulière. Il est bien connu que la fonctionnalité modale est quelquechose à éviter autant que possible; il est très difficile de prédire dans quel ordre vos utilisateurs vont vouloir faire les choses! Ainsi, il n'y a pas de doutes que le modèle avec état a sa place.

Le plus grand contraste entre les deux modèles est la fonction du bouton-précédent.

8.1.2. Seam et le bouton précédent

Quand les règles de navigation JSF et Seam sont utilisées, Seam laisse l'utilisateur naviger librement avec les boutons précédent, suivant et rafraichir. Il est de la responsabilité de l'application de s'assurer que l'état conversationnel reste en interne consistant quand cela arrive. L'experience avec la combinaisond'application web comme Struts ou WebWork - qui ne supporte pas le modèle conversationnel - et les modèles de composants sans état comme les beans de session sans état EJB ou le serveur d'application Spring a appris à beaucoup de développers qu'il est presque impossible de le faire! Ainsi, notre expérience est que c'est dans le contexte de Seam qu'il y a un modèle conversaionnel bien définie, soutenu par les beans de de sessions avec état, il est actuellement presque prêt. Habituellement, il est presque aussi simple de combiner l'utilisation no-conversation-view-id avec la vérification de null au démarrage des méthodes d'écouteur d'action. Nous considerons le support de la navigation libre de formulaire presque aussi souhaitable.

Dans ce cas, la déclaration de no-conversation-view-id va dans pages.xml. Il indique a Seam de rediriger vers une page différente si une requête originaire d'une page rendue pendant une conversation et que cette conversation n'existe plus:

<page view-id="/checkout.xhtml" 

        no-conversation-view-id="/main.xhtml"/>

D'un autre côté, dans le modèle avec état, le bouton "précédent" est interprété comme un retour de transition non-définie vers l'état précédent. Depuis que le modèle avec état se renforce comme un groupe définie de transition depuis l'état courrant, le bouton "précédent" est par défaut interdit dans le modèle avec état! Seam de manière transparent détecte l'utilisation du bouton précédent et bloque toute tentative de réaliser une action depuis une page précédente "périmée" et redirige simplement l'utilisateur vers la page "courante" (et affiche un message faces). Que vous considériez comme une fonctionnalité ou une limitation le modèle sans état cela dépend de votre point de vue: comme un développeur d'application, c'est une fonctionnalité, comme un utilisateur, cela peut être frustrant. Vous pouvez activer la navigation avec le bouton "précédent" depuis un noeud de page particulier en indiquant back="enabled".

<page name="checkout" 

        view-id="/checkout.xhtml" 

        back="enabled">

    <redirect/>

    <transition to="checkout"/>

    <transition name="complete" to="complete"/>

</page

>

Cela autorise le bouton "précédent" depuis l'état checkout vers tout état précédent!

Note

Si une page est définie pour rediriger après une transition, il n'est pas possible d'utiliser le bouton précédent pour retourner à la page même quand le bouton précédent est sur une page plus tard dans l'enchainement. La raison est que parce que Seam stocke les informations à propos de l'enchainement de page dans l'étendue page donc le bouton précédent doit résulter dans une requête POST pour que l'information soit restorée (autrement dit, une requête Faces). Une redirection fournie ce type de liaison.

Bien sûr, nous avons toujours besoin de définir ce qu'il arrive si une requête originiaire d'une page rendue pendant l'enchainement de page, et la conversation ave l'enchainement de page n'existe plus. Dans ce cas, la déclaration no-conversation-view-id va dans la définition d'enchainement de page:

<page name="checkout" 

        view-id="/checkout.xhtml" 

        back="enabled" 

        no-conversation-view-id="/main.xhtml">

    <redirect/>

    <transition to="checkout"/>

    <transition name="complete" to="complete"/>

</page

>

En pratique, les deux modèles de navigation ont leur spécificité et vous allez rapidement apprendre à les reconnaitre quand vous préférerez un modèle plutôt que l'autre.

<bpm:jbpm />

<bpm:jbpm>

    <bpm:pageflow-definitions>

        <value

>pageflow.jpdl.xml</value>

    </bpm:pageflow-definitions>

</bpm:jbpm

>

@Begin(pageflow="numberguess")

public void begin() { ... }

<page>

        <begin-conversation pageflow="numberguess"/>

    </page

>

<pageflow-definition name="viewEditDocument">



    <start-state name="start">

        <transition name="documentFound" to="displayDocument"/>

        <transition name="documentNotFound" to="notFound"/>

    </start-state>

    

    <page name="displayDocument" view-id="/document.jsp">

        <transition name="edit" to="editDocument"/>

        <transition name="done" to="main"/>

    </page>

    

    ...

    

    <page name="notFound" view-id="/404.jsp">

        <end-conversation/>

    </page>

    

</pageflow-definition

>

<page name="displayGuess" view-id="/numberGuess.jsp">

    <redirect/>

    <transition name="guess" to="evaluateGuess">

        <action expression="#{numberGuess.guess}" />

    </transition>

</page

>

<h:commandButton type="submit" value="Guess" action="guess"/>

<h:commandButton type="submit" value="Guess"/>

<page name="displayGuess" view-id="/numberGuess.jsp">

    <redirect/>

    <transition to="evaluateGuess">

        <action expression="#{numberGuess.guess}" />

    </transition>

</page

>

<h:commandButton type="submit" value="Guess" action="#{numberGuess.guess}"/>

<page name="displayGuess" view-id="/numberGuess.jsp">

    <transition name="correctGuess" to="win"/>

    <transition name="incorrectGuess" to="evaluateGuess"/>

</page

>

<decision name="evaluateGuess" expression="#{numberGuess.correctGuess}">

    <transition name="true" to="win"/>

    <transition name="false" to="evaluateRemainingGuesses"/>

</decision

>

<page name="win" view-id="/win.jsp">

    <redirect/>

    <end-conversation/>

</page

>

<page name="win" view-id="/win.jsp">

    <redirect/>

    <end-task transition="success"/>

</page

>

<process-state name="cheat">

    <sub-process name="cheat"/>

    <transition to="displayGuess"/>

</process-state

>

8.3. La gestion des processus métier dans Seam

Un processus métier est un groupe de tâche bien définis qui doivent être réaliser par des utilisateurs ou des systèmes logiciels en accord avec des règles bien définies à propos de qui peut réaliser une tâche, et quand elle devrait être réalisée. L'intégration de JBPM dans Seam rend facile d'afficher la liste des tâches des utilisateurs et les laisser gérer leurs tâches. Seam permet aussi à l'application stocker l'état associé avec le processus métier dans le contexte BUSINESS_PROCESS et avoir cet état qui soit persistant via les variables du jBPM.

Une simple définition de processus métier ressemble assez à la définition de l'enchainement de page (Un Seul Genre de Truc), exception sauf qu'au lieu d'un noeud <page> , nous avons des noeuds <task-node>. Dans un procéssus métier à exécution longue, les état d'atente sont là où le système est en attente qu'un utilisateur se connecte pour réaliser une tâche.

<process-definition name="todo">

   

   <start-state name="start">

      <transition to="todo"/>

   </start-state>

   

   <task-node name="todo">

      <task name="todo" description="#{todoList.description}">

         <assignment actor-id="#{actor.id}"/>

      </task>

      <transition to="done"/>

   </task-node>

   

   <end-state name="done"/>

   

</process-definition

>

Il est parfaitement possible que nous ayons à la fois des définition de processus métier en jPDL et des définitions d'enchainements de pages en jPDL dans le même projet. Et donc, la relation entre les deux est qu'un seul <task> dans un processus métier correspond à l'ensemble d'un enchainement de page <pageflow-definition>

<bpm:jbpm>

    <bpm:process-definitions>

        <value

>todo.jpdl.xml</value>

    </bpm:process-definitions>

</bpm:jbpm

>

@In Actor actor;


public String login() {

    ...

    actor.setId( user.getUserName() );

    actor.getGroupActorIds().addAll( user.getGroupNames() );

    ...

}

@CreateProcess(definition="todo")

public void createTodo() { ... }

<page>

    <create-process definition="todo" />

</page

>

<task name="todo" description="#{todoList.description}">

    <assignment actor-id="#{actor.id}"/>

</task

>

<task name="todo" description="#{todoList.description}">

    <assignment pooled-actors="employees"/>

</task

>

<h:dataTable value="#{pooledTaskInstanceList}" var="task">

    <h:column>

        <f:facet name="header"

>Description</f:facet>

        <h:outputText value="#{task.description}"/>

    </h:column>

    <h:column>

        <s:link action="#{pooledTask.assignToCurrentActor}" value="Assign" taskInstance="#{task}"/>

    </h:column

>                    

</h:dataTable

>

<h:commandLink action="#{pooledTask.assignToCurrentActor}"

> 

    <f:param name="taskId" value="#{task.id}"/>

</h:commandLink

>

<h:dataTable value="#{taskInstanceListForType['todo']}" var="task">

    <h:column>

        <f:facet name="header"

>Description</f:facet>

        <h:outputText value="#{task.description}"/>

    </h:column>

    <h:column>

        <s:link action="#{todoList.start}" value="Start Work" taskInstance="#{task}"/>

    </h:column

>                    

</h:dataTable

>

@StartTask

public String start() { ... }

<page>

    <start-task />

</page

>

@EndTask(transition="completed")

public String completed() { ... }

<page>

    <end-task transition="completed" />

</page

>