JBPM & Maven : un fichier pom.xml de Maven pour définir vos dépendances de projet JBPM

En réponse à plusieurs demandes sur l'intégration de JBPM avec Maven je poste cette entrée

En utilisant un fichier pom.xml de Maven pour définir vos dépendances de projet, vous pouvez laisser maven obtenir les dépendances pour vous. Ensuite, cela devient plus facile à integrer avec Hudson dans un processus de Build continue.

Le fichier pom.xml qui suit est un exemple qui pourrait être utilisé pour créer un nouveau projet Maven qui est capable d'exécuter un processus BPMN2.

<project xmlns="http://maven.apache.org/POM/4.0.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>org.jbpm</groupId>
 <artifactId>jbpm-maven-example</artifactId>
 <name>jBPM Maven Project</name>
 <version>1.0-SNAPSHOT</version>
 <repositories>
   <repository>
     <id>jboss-public-repository-group</id>
     <name>JBoss Public Maven Repository Group</name>
     <url>https://repository.jboss.org/nexus/content/groups/public/</url>
     <layout>default</layout>
     <releases>
       <enabled>true</enabled>
       <updatePolicy>never</updatePolicy>
     </releases>
     <snapshots>
       <enabled>false</enabled>
     </snapshots>
   </repository>
   <repository>
     <id>jboss-snapshot-repository-group</id>
     <name>JBoss SNAPSHOT Maven Repository Group</name>
     <url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
     <layout>default</layout>
     <releases>
       <enabled>false</enabled>
     </releases>
     <snapshots>
       <enabled>true</enabled>
       <updatePolicy>never</updatePolicy>
     </snapshots>
   </repository>
 </repositories>
 <dependencies>
   <dependency>
     <groupId>org.jbpm</groupId>
     <artifactId>jbpm-bpmn2</artifactId>
     <version>5.0.0</version>
   </dependency>
 </dependencies>
</project>

Alfresco présente Activiti BPMN 2 : 1er moteur BPMN 2.0 open source sous licence Apache

En avril, dernier, lorsqu’on a parlé, dans ce blog, du départ de deux membres importants quittent l’équipe JBPM, nous avons annoncé que Tom Baeyens et Joram Barrez promettent, sur le blog de Joram Barrez, le lancement imminent d’un nouveau Moteur BPM basé sur la norme BPMN 2.0 sous la licence apache.

Une partie de l’annonce était « We’re building a new BPM platform that’s architected for new IT requirements. It will be Apache licensed and it will run BPMN 2.0 natively ! »

C’est annoncé !!,

C’est sous les couleurs de Alfresco, le Leader de l’ECM open source, que les deux “mousquetaires du BPM” proposent ce nouveau moteur, nommé Activiti.

Activiti va rendre le Business Process Management (BPM) une commodité.

il a au moins la particularité d’être le 1er moteur BPM (et en plus BPMN 2.0) open source sous licence Apache.

Activiti un moteur BPM

La première version alpha d’Activiti intègre les fonctionnalités suivantes :

- Activiti Engine – Fichier JAR contenant la machine virtuelle de processus et l’implémentation du langage de processus BPMN ;

- Activiti Probe – Console d’administration système permettant de commander le moteur Activiti ;

- Activiti Explorer – Application utilisateur permettant de gérer facilement les listes de tâches et d’exécuter les tâches de processus ;

- Activiti Modeler – Outil de modélisation des processus BPMN 2.0 via un navigateur, basé sur Ajax, destiné aux analystes métier.

Selon Tom Baeyens, « Activiti va véritablement bouleverser le paysage BPM », explique Tom Baeyens. « Avec sa licence Apache et sa richesse fonctionnelle,

A l’instar de l’approche de Micorsoft avec WPF 4.0 chez les développeurs .Net, l’équipe d’Activiti, va essayer de déclencher une large adoption de la technologie BPM chez les développeurs Java.

Activiti est ainsi à même de s’imposer comme l’implémentation standard du BPM et du BPMN.

Remarquons l’utilisation du moteur de modélisation web SIGNAVIO, pour la modélisation.

Il est prévisible que ce moteur de BPM, Activiti deviendra le moteur de gestion des processus métier par défaut d’Alfresco.

bravo pour cette initiative, à la sauce Apache, une licence business frendly …

étape suivante : tester et mettre à l’épreuve…

site web

http://www.activiti.org/

JBPM 5 : une version majeure en préparation

L’équipe BPM de JBoss (RedHat) a annoncé le lancement du projet JBPM 5 : la prochaine génération de plateforme BPM.

La principale information, est que jBPM 5 sera basé sur l'expérience combinée de jBPM et de Drools Flow (ainsi que les projets en relation : RiftSaw et Overlord).

Un effort de capitaliser sur les avantages des deux solutions sera la principale direction du projet, si on considère que la compatibilité totale avec BPMN 2 est déjà acquise.

Aucune feuille de route n’a été présentée pour le moment.

JBPM 4 et BPMN 2.0: deux membres importants quittent l’équipe

Tom Baeyens (chef de projet JBPM chez RedHat) et Joram Barrez (développeur Leader JBPM chez RedHat) ont quitté le projet JBPM. Rappelons que Tom a rejoint JBoss en 2004. Joram a apporté son expertise dans des domaines comme la performance, l'intégration et le respect des normes.

Tom Baeyens et Joram Barrez annoncent, sur le blog de Joram Barrez, le lancement imminent d’un nouveau Moteur BPM basé sur la norme BPMN 2.0 sous la licence apache. Une partie de l’annonce « We’re building a new BPM platform that’s architected for new IT requirements. It will be Apache licensed and it will run BPMN 2.0 natively ! »

Peut on interpréter cela comme la poids de RedHat, qui ralentit le projet, d’un point de vue des « entrepreneurs de JBPM», et que la prochaine version de JBPM ne sera pas nativement BPMN 2.0 ?

Dans tous les cas, c’est une tendance de fond, les principaux projets open sources sont ou seront contrôlés par des entreprises qui fixeront les feuilles de routes (avec ou sans la communauté).

Espérons que cette nouvelle disposition de l’équipe JBPM, ne ralentisse pas le virage de JBPM 4 vers la norme BPMN 2.0, et notamment dans le volet outillage et monitoring.

Source : http://www.jorambarrez.be/blog/2010/03/29/alive-and-kicking/

----

Open source : le modèle du logiciel libre serait-il menacé par les grands fournisseurs de software

BPMN 2.0 & JBPM : la version 4.3 de JBPM est compatible BPMN 2.0

La démocratisation de BPMN (Business Process Modeling Notation) est en marche. Avant même la sortie officielle des spécifications de la version 2.0 de BPMN, la communauté open source innove. C’est l’information qui filtre du lancement de la nouvelle version 4.3 de JBPM, une partie de la spécification BPMN 2.0 est déjà implémentée.

L’équipe de JBOSS devance les autres et pense que l’année 2010 sera l’année de la consécration du langage de notation des processus métiers BPMN 2.0.

Cette initiative montre que lorsque les standards sont ouverts, la communauté open source peut prendre le leadership.

D’autres nouveautés de la version 4.3 de jBPM :

- Une meilleure intégration avec Spring

- Ajout de l’activité de type JMS

- Une meilleur intégration avec le moteur de règles métiers de Jboss : le fameux Drools.

- Ajout de la fonction count() pour toutes les requêtes dans l’API ProcessInstanceQuery (Interface dans le apckage org.jbpm.api ) de JBPM

o long count() : execute a count(*) query and returns number of results

-

Pour plus d’information sur JBPM : visiter l’excellent site http://www.jorambarrez.be et notamment

http://www.jorambarrez.be/blog/2009/12/04/jbpm-goes-bpmn/

Tutorial Mule ESB : pas à pas

Cet article présente une série de présentations et de tutoriels pour démystifier Mule ESB : http://net-progress.blogspot.com/)

1 les projets d’intégration avec ESB.

1.1 de la nécessité d’un projet d’intégration dans un S.I. (Système d’information).

1.2 Les types d’intégration.

1.3 Intégration par les données :.

1.4 Intégration par les API :.

1.5 Intégration par les processus.

1.6 Un ESB est service de l’intégration.

2 Mule ESB 2.x est il un ESB.

2.1 Ce qu’est un ESB.

2.2 Rôle d’un ESB.

2.3 Mule ESB est il un ESB.

2.4 La concurrence open source.

2.5 Autres usages possible pour Mule.

3 Tutorial Mule ESB : une introduction.

3.1 C’est quoi Mule.

3.2 qu’est ce qu’un service Mule.

3.3 Séparer la logique métier de la logique de routage.

4 Tutorial Mule ESB : les principales composantes.

4.1 Présentation.

4.2 Installer Mule et son IDE.

4.2.1 Installer Mule.

4.3 Installer l’IDE de Mule.

5 Tutorial Mule ESB : Créer un projet d’intégration avec Mule en utilisant l’IDE Eclipse.

5.1 Créer un projet Mule.

5.2 Créer une configuration Mule.

5.3 Lancer l’exécution du projet à partir d’Eclipse.

5.4 Sélectionner la configuration Mule.

6 Tutorial Mule ESB & Eclipse : déployer un projet d’intégration avec Eclipse.

6.1 Déployer le projet à partir d’Eclipse.

6.2 Exécuter le projet.

7 Tutorial Mule ESB : Une application simple, Echo sans altération de message.

7.1 Introduction.

7.2 Présentation générale du fichier de configuration de Mule.

7.3 Construction pas à pas d’un exemple simple :

8 Tutorial Mule ESB : Une seconde application simple, Echo avec modification du message

9 Tutorial Mule ESB & Spring Ioc: Utilisation des beans Spring avec Mule.

10 Tutorial Mule ESB : illustration des capacités de Mule.

10.1 Description :.

10.2 Le sujet :

10.3 Pour commencer :

10.4 Configuration de Mule.

10.5 Définir les transformateurs.

10.6 Définir le modèle.

10.7 Définir un service.

10.8 Définir les entrées du service.

10.9 Définir le composant du service.

10.10 Définir la sortie du composant.

10.11 Finaliser le projet.

10.12 Exécuter le projet.

10.13 Retour sur les transformations.

Tutorial Mule ESB : illustration des capacités de Mule

NB : cet article fait partie d’une série de présentation et de tutorials pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Dans l’exemple présenté dans cette partie, nous allons explorer les capacités d’un ESB : Protocol de transport, transformation et gestion des exceptions

Description :

L’exemple a pour objectif de répondre à une demande de résultat dans un examen pour un étudiant donnée. Les aspects suivants seront traités

1. Réception de l’invocation par deux méthodes (VM et http)

2. Développement et Utilisation de transformateurs spéciaux

3. Utilisation d’une stratégie de gestion des exceptions

4. Réponse synchrone par http et affichage directe dans la page web

Le sujet :

Il s’agit d’un service en ligne de suivi des résultats des examens nationaux.

Un utilisateur pourra trouver les résultats de ses examens à travers une interface web dans son portail favoris.

Ce portail communique avec le serveur de l’université via un protocole de son choix : Mule est capable de varier le protocole d’exposition d’un service indépendamment de son implémentation

Pour commencer :

Créer un projet Mule vide et définir le fichier de configuration : resultat-examen-http-config.xml

Les Pojo en relation avec le projet sont :

Etudiant (sous sa forme la plus simple, pour les besoins du tutorial)

1:  package com.oxia.att.mule.intro.beans;
2:  import java.io.Serializable;
3:  public class Etudiant implements Serializable {
4:       private static final long serialVersionUID = 7010138636008560022L;
5:       private String nom;
6:       private String universite;
7:  // getter & setter …
8:       public boolean isValid() {
9:            if (nom == null)
10:                 return false;
11:            // accépter seulement si le nom a plus de 2 caractère
12:            if (nom.length() > 1)
13:                 return true;
14:            return false;
15:       }
16:  }

ResultatExamen : objet contenant le résultat de l’étudiant (sous sa forme la plus simple, pour les besoins du tutorial)

1:  package com.oxia.att.mule.intro.beans;
2:  import java.io.Serializable;
3:  public class ResultatExamen implements Serializable {
4:       private static final long serialVersionUID = -3140370545357738491L;
5:       private StringBuffer resultat = new StringBuffer();
6:       public StringBuffer append(String str) {
7:            return resultat.append(str);
8:       }
9:       public StringBuffer append(StringBuffer sb) {
10:            return resultat.append(sb);
11:       }
12:       public String toString() {
13:            return resultat.toString();
14:       }
15:  }

Le projet se présente sous cette forme :

Configuration de Mule

Le prologue :

1:  <?xml version="1.0" encoding="UTF-8"?>

Fixer les namspaces à utiliser

1:  <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
2:       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:spring="http://www.springframework.org/schema/beans"
3:       xmlns:http="http://www.mulesource.org/schema/mule/http/2.2" xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2"
4:       xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"
5:       xsi:schemaLocation="
6:        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
7:        http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
8:        http://www.mulesource.org/schema/mule/http/2.2 http://www.mulesource.org/schema/mule/http/2.2/mule-http.xsd
9:        http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd
10:        http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd">

Définir les transformateurs

Définir les transformateurs à utiliser

1: <custom-transformer name="StringToEtudiant"
2:  class="com.oxia.att.mule.intro.transofrmer.StringToEtudiant" />
3: <custom-transformer name="EtudiantToResultatExamen"
4:    class="com.oxia.att.mule.intro.transofrmer.EtudiantToResultatExamen" />
5: <custom-transformer name="ResultatExamenToString"
6:    class="com.oxia.att.mule.intro.transofrmer.ResultatExamenToString"/>
7: <custom-transformer name="HttpRequestToEtudiant"
8:    class="com.oxia.att.mule.intro.transofrmer.HttpRequestToEtudiant" />
9: <custom-transformer name="ExceptionToString"
10:   class="com.oxia.att.mule.intro.transofrmer.ExceptionToString" />
11: <custom-transformer name="HttpRequestToParameter"
12:  class="org.mule.transport.servlet.transformers.HttpRequestToParameter" />
13: <custom-transformer name="ObjectToString"
14:  class="org.mule.transformer.simple.ObjectToString" />

Donnons ici un exemple de transformateur qui reste, rappelons le, un code spécifique à Mule.

Exemple de code source d’un transformateur spécifique développe dans le cadre de ce tutorial

1:  package com.oxia.att.mule.intro.transofrmer;
2:  import org.mule.api.transformer.TransformerException;
3:  import org.mule.transformer.AbstractTransformer;
4:  import com.oxia.att.mule.intro.beans.ResultatExamen;
5:  import com.oxia.att.mule.intro.beans.Etudiant;
6:  public class EtudiantToResultatExamen extends AbstractTransformer {
7:       public EtudiantToResultatExamen() {
8:            super();
9:            this.registerSourceType(Etudiant.class);
10:            this.setReturnClass(ResultatExamen.class);
11:       }
12:       public Object doTransform(Object src, String encoding)
13:                 throws TransformerException {
14:            ResultatExamen resultatExamen = new ResultatExamen();
15:            Etudiant etudiant = (Etudiant) src;
16:            resultatExamen.append("Le candidat : ");
17:            resultatExamen.append(etudiant.getNom());
18:            resultatExamen.append(" de L'universite : ");
19:            resultatExamen.append(etudiant.getUniversite());
20:            return resultatExamen;
21:       }
22:  }

Une classe de Transformation

· hérite de la classe AbstractTransformer

· et implémente la méthode doTransform(…).

Cette classe a accès au Payload du message et suppose qu’il est de type Etudiant

Il est préférable de rester indépendant du protocole de transport afin de réutiliser les transformations dans d’autres situations :

1:  Etudiant etudiant = (Etudiant) src;

Définir le modèle

1:  <model name="ResultatExamenSample">
2:  La définition des services
3:  </model>

Définir un service

Rappelons, que dans un service il ya 4 parties

<component />	Le composant
<outbound> </outbound>	Le point de sortie
<default-service-exception-strategy> </default-service-exception-strategy>	La gestion des exceptions
</service>

Définir les entrées du service

Dans le premier service nommé DonneesEtudiant, nous allons avoir deux points d’entrée :

· Un point d’entrée http

· Un point d’entrée vm

1:  <inbound>
2:       <inbound-endpoint address="http://localhost:8888"
3:            transformer-refs="HttpRequestToEtudiant" synchronous="true">
4:       </inbound-endpoint>
5:       <vm:inbound-endpoint path="etudiant"
6:            transformer-refs="StringToEtudiant" synchronous="true" />
7:  </inbound>

Pour appeler le service avec HTTP, lancer cette URL dans un navigateur

http://localhost:8888?nom=Khalil

pour faire appel à ce service avec la programmation, utiliser la classe MuleClient:

MuleClient client = new MuleClient();

client.send("vm://etudiant", "Khalil", null);

UMOMessage response = client.send("vm://etudiant", "Ross", null);

System.out.println("response = " + response.getPayload());

Définir le composant du service

Utilisons ici un appel direct à la classe de service (un Simple POJO)

1: <component class="com.oxia.att.mule.intro.service.VerifierCandidat" />

Définir la sortie du composant

Nous illustrons dans cette partie l’usage des filtres :

Les Filtres permettent de préciser les conditions qui doivent être remplies pour un message afin qu’il soit acheminé à un service. Il existe plusieurs types de filtres offerts par Mule que vous pouvez utiliser. Il est possible de créer vos propres filtres.

Nous utilisons ici un routeur spécial : le <filtering-router> : qui présente l’avantage de filtrer selon le contenu et dispatché vers le point de sortie approprié.

· Si le résultat est de type Etudiant alors tout va bien

· Si c’est une exception (ici de type com.oxia.att.mule.intro.exception.CandidatException) alors on passe en mode erreur

1:<outbound>
2:<filtering-router>
3:  <vm:outbound-endpoint path="getResultatExamen" synchronous="true" />
4:    <payload-type-filter 
5:     expectedType="com.oxia.att.mule.intro.beans.Etudiant" />
6:</filtering-router>
7:<filtering-router>
8:   <vm:outbound-endpoint path="userErrorHandler" synchronous="true" />
9:    <payload-type-filter 
10:      expectedType="com.oxia.att.mule.intro.exception.CandidatException" />
11: </filtering-router>
12:</outbound>

Et

1:  default-service-exception-strategy>
2:       <vm:outbound-endpoint path="systemErrorHandler" />
3:  </default-service-exception-strategy>

Finaliser le projet

Pour finaliser le projet, il reste à indiquer les destinations getResultatExamen, userErrorHandler et systemErrorHandler

Pour cela une solution est définir des nouveaux services :

1:  <service name="ResultatExamen">
2:       <inbound>
3:            <vm:inbound-endpoint path="getResultatExamen"
4:                 transformer-refs="EtudiantToResultatExamen"
5:                 responseTransformer-refs="ResultatExamenToString"
6:         synchronous="true" />
7:       </inbound>
8:       <component 
9:       class="com.oxia.att.mule.intro.service.ObtenirResultatExamen" />
10:  </service>
11:  <service name="UserErrorHandler">
12:       <inbound>
13:       <vm:inbound-endpoint path="userErrorHandler"
14:            responseTransformer-refs="ExceptionToString" synchronous="true"/>
15:       </inbound>
16:  </service>

Dans ce dernier service, nous utilisons le fameux routeur <pass-through-router>

1:  <service name="SystemErrorHandler">
2:    <inbound>
3:       <vm:inbound-endpoint path="systemErrorHandler" synchronous="true" />
4:    </inbound>
5:    <outbound>
6:       <pass-through-router>
7:            <stdio:outbound-endpoint system="ERR" />
8:       </pass-through-router>
9:    </outbound>
10:  </service>

Exécuter le projet

Une fois lancé il suffit d’utiliser une simple page HTML

1:  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
2:  <html xmlns="http://www.w3.org/1999/xhtml">
3:   <head>
4:    <title>Obtenir Résultat Examen</title>
5:   </head>
6:   <body>
7:    <form method="GET" action="http://localhost:8888">
8:     <input type="text" name="nom"/>
9:     <input type="submit" value="Demander le Résultat de l'Examen" />
10:    </form><br />
11:   </body>
12:  </html>

La réponse est alors la suivante

Le serveur indique que tout s’est bien passé

INFO 2009-07-12 00:08:53,890 [connector.http.0.receiver.2] org.mule.transport.vm.VMMessageDispatcher: Connected: endpoint.outbound.vm://getResultatExamen

Si on provoque une exception (il suffit d’envoyer un nom de 1 caractère)

Le résultat est toujours affiché ( la situation est maitrisée)

Le serveur indique qu’on est passé en mode exception :

<><><><><>

INFO 2009-07-12 00:12:24,000 [connector.http.0.receiver.2] org.mule.transport.vm.VMMessageDispatcher: Connected: endpoint.outbound.vm://userErrorHandler

Tutorial JBPM : BMP, Processus & JBPM

Voici quelques liens utiles pour débuter avec JBPM :

En français à partir du site :

• · BPM & Moteur de workflow : l’offre open source
• · La version 4 de JBPM prend le virage de BPMN
• · Graph Oriented Programming (GOP) avec JBPM
• · Comment modéliser un processus métier avec JBPM : exemple “gestion des entretiens”
• · Jbpm 4 Tutorial : JBPM 4 a simplifié son model de programmation et a confirmé l’orientation BPMN
• · Un peu de monitoring Métier (BAM) avec JBPM et SeeWhy (event-driven business intelligence )
• · Quelle est la différence entre JBPM et Intalio ?

En anglais liens très intéressants partir du site de Joram Barrez (jBPM core developer at JBoss/Red Hat ) http://www.jorambarrez.be/blog/about/

• · Part 1: modeling the process with BPMN
• · Part 2: coding the business process
• · Intermezzo: how does jBPM fit into my architecture?
• · Part 3: prototyping with the jBPM console
• · Part 4: the end application
• · Part 5: BI and BAM

Tutorial Mule ESB : Une seconde application simple, Echo avec modification du message

NB : cet article fait partie d’une série de présentation et de tutorial pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Reprenons l’exemple précédent (voir lien suivant ), pour y ajouter un élément nouveau :

Traiter le message obtenu au niveau du point d’entrée (<inbound>) avant de le transférer vers le point de sortie </outbound>

C’est l’occasion d’utiliser le tag XML component :

<component> </component>

Le service métier à invoquer

Avant de configurer le service « métier », il est temps de développer la classe Java qui sera responsable de traiter le message :

Il est très important de savoir que cette classe java est indépendante de Mule : il s’agit d’un simple POJO (on verra même comment l’injecter avec de l’Ioc et Spring)

La classe Java est la suivante : com.oxia.att.mule.intro.ComposantSimple

Avec Eclipse :

Préciser le package et le nom de la classe

Puis développer la classe :

Ceci est un exemple simple

1:  package com.oxia.att.mule.intro; 
2:  import java.util.UUID; 
3:  package com.oxia.att.mule.intro; 
4:  import java.util.UUID; 
5:  public class ComposantSimple { 
6:       private String prefix="Le préfix du message_"; 
7:       private String numero; 
8:       /* 
9:        * exemple simple de méthode métier qui  
10:        * exploite le message obtenu ( Mule est responsable de tout transformer ...) 
11:        * et retourne un nouveau message ( Mule est responsable de tout transformer ...) 
12:        *  
13:        */ 
14:       public String hello(String message) { 
15:            numero = "_"+ UUID.randomUUID().toString(); 
16:            System.out.println("le message originale est : " +message); 
17:            message = prefix + message + numero ; 
18:            System.out.println("le message en sortie est : " +message); 
19:            return  message ; 
20:       } 
21:       public void setPrefix(String prefix) { 
22:            this.prefix = prefix; 
23:       } 
24:  } 

Maintenant il suffit d’indiquer à Mule d’utiliser cette classe Java comme destination su message obtenu au niveau du INBOUD (utiliser une nouvelle configuration de Mule (echo-system-2-config.xml)

1:  <component class="com.oxia.att.mule.intro.ComposantSimple"/> 

Le projet se présente comme suit :

Exécuter le projet :

On constate que

• le message est « passé » au POJO sous format String
  

Mule a découvert (tout seul) la méthode à utiliser, grâce à son algorithme de résolution :

• deux candidata public void setPrefix(String prefix) et public String hello(String message),
• la méthode set public void setPrefix(String prefix) ne retourne rien alors que la méthode public String hello(String message), retourne un String : c’est une cible

En cas d’ambiguïté, il est possible d’indiquer la méthode dans la configuration du composant

mais ceci est un autre sujet

Formation SOA & Open Source par la pratique: Atelier de Mise en ouvre des architectures orienté service (SOA) avec des outils open source

J’anime, à Tunis, du 26 au 30 octobre prochain un Atelier pratique de formation sur la mise en ouvre des architectures orienté service (SOA) avec des outils open source.

Bien que SOA n’est pas une histoire d’outils, l’objectif de cet Atelier est de mettre en pratique, par les participants des concepts de base de la démarche SOA et de l’intégration d’application d’entreprise. Les participants, exploiteront mettront en ouvre des web services avec la démarche Contract-First, utilseront l’ESB Mule pour réaliser des intégrations avec ou sans web service et mettront en place un outil de gouvernance,

1.1 Objectif de l’Atelier

La complexité croissante des Systèmes d’Information et les opportunités technologiques rendent de plus en plus indispensable de disposer d’un cadre pour organiser, structurer et fédérer les travaux sur le Système d’Information et d’instaurer une interopérabilité naturelle dans les services afin de réduire le besoin d’intégration.

Ce workshop apporte un retour d’expérience des meilleures pratiques pour la mise en œuvre des architectures orientées services avec des outils open source.

L’objectif de ce workshop est de former les participants à la pratique des architectures orientés services. Les outils open source suivants seront utilisés :

1. Java 1.6
2. Eclispe IDE
3. Mule ESB
4. ActiveMQ (MOM)
5. Spring
6. Hibernate
7. Et d’autres outils de monitoring, de suivi, et de gestion d’environnements SOA …

1.2 Compétences à acquérir

A l'issue de ce séminaire, les participants seront en mesure de:

1. Comprendre les problèmes d’intégration d’applications en SI
2. Comprendre les fondements des architectures orientées services SOA
3. Capacité de mettre en ouvre des services web avec différentes méthodes
4. Capacité d’exploiter et de mettre en ouvre l’ESB Mule 2.2.1
5. Evaluer les étapes d’un projet de mise en ouvre par la pratiques d’une approche SOA

1.3 A qui s'adresse ce séminaire?

· Développeur Java

· Intégrateur SI

· IT manager

· Architectes d'applications

1.4 Niveau requis

Pour bénéficier pleinement de ce cours, les stagiaires doivent avoir :

• Une connaissance de Java.
• Une compréhension des enjeux des SI dans l’entreprise

1.5 Détails du programme

1.5.1 Introduction à l’Architecture d’Entreprise et à l’EAI (Entreprise Application Intégration

Présenter des problématiques d’intégration des applications d’Entreprise (EAI)

• Définition du SI
• Les motivations de l’Architecture de SI
• Nouvelles architectures informatiques
• Métaphore de la cité & Plan d’occupation des sols (POS)
• intégration des applications d’Entreprise (EAI)
• EAI & Architecture d’entreprise

1.5.2 Présentation de XML

• Architectures d’interopérabilité
• Présentation de XML
  • XML les objectifs de conception
  • Notion de base : balise et attributs
  • Pourquoi XML?
  • La notion de Schéma XML
• Formats d’échange, Interopérabilité et portabilité des données

1.5.3 SOA (Architecture Orientée Service) et EDA

Présenter la démarche SOA, et présenter des concepts et de la démarche SOA (architecture orientée services), des besoins en infrastructures et de la notion de maturité SOA

• Problématique de l’intégration en entreprise et intra-entreprises
• SOA : initialement un simple besoin d‘intégration
• SOA, différents points de vue
• Présentation du concept SOA
• La notion de service (au sens SOA)
• SOA s’applique à tous les niveaux de l’EAI
• Principes fondamentaux de l’architecture SOA

1.6 Rôle d’un ESB et présentation de Mule ESB

• Les concepts de Mule ESB et l’infrastructure nécessaire
• Un premier exemple avec MULE ESB
• Les différentes composantes de Mule
• Place de Mule ESB dans un SI

1.7 Présentation de Spring Ioc et Hibernate

• Les concepts Spring & de l’Ioc
• Mule ESB et Spring
• Introduction à Spring & Hibernate

1.8 Présentation des MOM

• Besoins & définitions :
  • Middleware Orienté Message : les clés de l'intégration grâce aux mécanismes asynchrones. Les fonctions principales d'un MOM : routage, intégrité transactionnelle, déclenchement de process.
• - L'opportunité de désolidariser les applications pour assurer la flexibilité d'une solution EAI. Acteurs et enjeux : IBM, BEA, TIBCO.
• La norme JMS de Java EE
  • La norme JMS
  • ActiveMQ un MOM open source

1.9 Mule d’un point de vue développements

• Intégration avec Spring
• L’IDE Eclipse
• La gestion des exceptions
• Etendre Mule
  • Les transformations,
  • Les Filtres
  • Les Routeurs
• Les Test unitaires
• Le transport dans Mule
• Les Web Services
  • Rappel sur SOAP
  • Contract Fist
  • La consommation
• Les transactions dans Mule
  • Transaction étendue XA
  • Garantie de délivrance des messages
  • Transaction base de données et MOM
• Gestion des codes sources dans un environnement multi développeurs
• Le log & les pistes d’audit
• La Sécurité
• Intégration automatique
• Les bests practices

1.10 Mule ESB d’un point de vue Analyste métier

• Définir les services : cycle de vie d’un service
• Spécifier les besoins
• Spécifier le contrat de service
• Spécifier les aspects métiers du SLA

1.11 Mule d’un point de vue Système

• Les différentes possibilités de déploiements de Mule
• EAI pattern
• Scheduling
• Choix du déploiement et conséquences
  • Sans Serveur d’application
  • Avec Serveur d’application
  • Hub & Spoke ou Network centric
  • Rôle du MOM
  • LDAP ou SSO
• Monitoring & supervision
  • Lien avec le système de supervision en place
• La gestion des SLA
• Intégration continue
• Les bests practices

1.12 Définition d’une architecture cible

• Liste des architectures de déploiement possibles
  • Comparaisons
• Développement de l’architecture cible
  • Règles d’architecture

1.13 Mise en place de la gouvernance

• Cycle de vie d’un service
• Zoom sur la phase d’identification des services : quelle approche
• Comité de gouvernance
• Cycle de vie des services
• Template de spécification des services
  • Spécifications fonctionnelle
  • SLA (Service Level Agreement)

Tutorial Mule ESB : Une application simple, Echo sans altération de message

NB : cet article fait partie d’une série de présentation et de tutoriaux pour démystifier Mule ESB : http://net-progress.blogspot.com/)

Introduction

L’application à développer est très simple, mais montre les premiers pas dans la création d’un projet d ‘intégration :

Nom du projet : Exercice_01_echo_System

Son objectif est limité : présenter une abstraction de la console de saisie IN et de sortie OUT

Pour commencer, créer un projet de type Mule (Exercice_01_echo_System) et un fichier de configuration de Mule (echo-system-config.xml)

Présentation générale du fichier de configuration de Mule

Le fichier de configuration de Mule est au format XML. L’IDE de Mule présente se base surl la version vision simplifie d’un éidteur XML de

Une configuration Mule, minimale est de ce type :

<?xml version="1.0" encoding="UTF-8"?> <mule xmlns=" … <model …>
<stdio:connector…/>	Les déclarations globales au niveau de la configuration
<service …>	Une déclaration d’au moins un service
<inbound> </inbound>	Au moins un point d’entrée, pour recevoir les messages Une abstraction du transport et des détails des protocoles
<component> </component>	Le service métier à invoquer
<outbound> </outbound>	Un point de sortie, pour envoyer des messages Une abstraction du transport et des détails des protocoles
</service>
</model> </mule>

Le lien est alors simple à faire avec cette vision de l’intégration

Construction pas à pas d’un exemple simple :

Utiliser une configuration de Mule : echo-system-1-config.xml.

La première partie du fichier XML est le prologue :

1:  <?xml version="1.0" encoding="UTF-8"?>  

La seconde partie est la définition des namespaces à utiliser par Mule

1:  <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"  
2:      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
3:      xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"  
4:    xsi:schemaLocation="  
5:      http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd  
6:      http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd">  

Ensuite on déclare le connecteur qui sera utilise par les points de contactes : ici on utilise le système d’entrée sorties classiques IN/OUT. Chez Mule la déclaration est basée sur le namespaces stdio.

1:  stdio:connector name="SystemStreamConnector"  
2:      promptMessage="Saisir les informations nécessaires: "  
3:      messageDelayTime="1000"/>  

Dans sa première version, le Service de l’application cible ne fait que deux choses :

1) recevoir sur le Système IN : des messages en texte

2) expédier ces messages vers le Système OUT

on a donc besoin de deux partie

1) <inbound>

a. Pour définir ce <inbound>, on utilise le namespaces du protocole de transport cible

<inbound> <stdio:inbound-endpoint system="IN"/> </inbound>

1) <outbound>

b. Pour définir ce < outbound >, on utilise le namespaces du protocole de transport cible : <stdio:outbound-endpoint system="OUT"/>

c. Mais il faut ajouter une indication sur le Routage du message en définissant le routeur à utiliser. Dans notre cas nous avons besoin simplement d’un routage systématique sans altération du message ni filtrage : c’est l’objectif du routeur de Mule dit <pass-through-router>

<outbound> <pass-through-router> <stdio:outbound-endpoint system="OUT"/> </pass-through-router> </outbound>

Ainsi la définition du service est la suivante

1:    <model name="echoSystemSimple">  
2:      <service name="echoService">  
3:        <inbound>  
4:          <stdio:inbound-endpoint system="IN"/>  
5:        </inbound>  
6:        <outbound>  
7:          <pass-through-router>  
8:            <stdio:outbound-endpoint system="OUT"/>  
9:          </pass-through-router>  
10:        </outbound>  
11:      </service>  
12:    </model>  

Le fichier de configuration devient :

1:  <?xml version="1.0" encoding="UTF-8"?>  
2:  <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"  
3:      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
4:      xmlns:stdio="http://www.mulesource.org/schema/mule/stdio/2.2"  
5:    xsi:schemaLocation="  
6:      http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd  
7:      http://www.mulesource.org/schema/mule/stdio/2.2 http://www.mulesource.org/schema/mule/stdio/2.2/mule-stdio.xsd">  
8:    <stdio:connector name="SystemStreamConnector"  
9:      promptMessage="Saisir les informations nécessaires: "  
10:      messageDelayTime="1000"/>  
11:    <model name="echoSystemSimple">  
12:      <service name="echoService">  
13:        <inbound>  
14:          <stdio:inbound-endpoint system="IN"/>  
15:        </inbound>  
16:        <outbound>  
17:          <pass-through-router>  
18:            <stdio:outbound-endpoint system="OUT"/>  
19:          </pass-through-router>  
20:        </outbound>  
21:      </service>  
22:    </model>  
23:  </mule>  

L’exécution du projet dans Mule est très simple :

Formation : Architecture SOA et intégration d’application d’entreprise, rôles des ESB et des MOM (Middleware Orienté Messages), quel programme et quels sujet traités dans un séminaire de 2 jours

J’anime le 21-22 octobre prochain un séminaire formation, à Tunis, sur le SOA (Architecture orienté messagerie), l’intégration des applications d’entreprise dans un système d’information, rôles des ESB et des MOM (Middleware Orienté Massages).

et pour la nième fois, je me pose la même question « quels thèmes aborder en 2 jours » quel programme?, quels messages ?

la réponse doit tenir compte qu’on est le 09/09/09, presque la fin de la première décennie du 2iemme siècle.

Pour répondre à cette question, même recette, fixer d’abords :

· Les objectifs

· les compétences cibles à acquérir par les participants

· A qui s’adresse

· Le niveau requis

Fixons d’abord les Objectifs

La complexité croissante des Systèmes d’Information et les opportunités technologiques rendent de plus en plus indispensable de disposer d’un cadre pour organiser, structurer et fédérer les travaux sur le Système d’Information et d’instaurer une interopérabilité naturelle dans les services afin de  réduire le besoin d’intégration.

Ainsi, on passe d'une informatique essentiellement composée d'applications à une informatique orientée services afin d'améliorer la réactivité et l’interopérabilité du système d'information.

Ce workshop apporte un retour d’expérience des meilleures pratiques pour la définition d'une architecture SOA ainsi que le choix d’un MOM autre technologies.

L’objectif de ce workshop est de former les participants aux choix des MOM (Middleware Orienté Messagerie) et à la compréhension des concepts EAI et SOA.

Il fournir des clés pour mieux appréhender la démarche d’intégration d’application dans un Systèmes d’Information :

· Objectifs,

· Enjeux,

· Approches,

· Bénéfices,

· Champs d’application

Quelles Compétences à acquérir

A l'issue de ce séminaire, les participants seront en mesure de:

· Comprendre les problèmes d’intégration d’applications en SI

· Comprendre les fondements des architectures orientées services SOA

· Comprendre les bases des MOM

· Apprendre la démarche de choix d’un MOM

· Evaluer les enjeux du choix d’un MOM dans un contexte SOA

A qui s'adresse ce séminaire?

· IT manager

· Architectes d'applications

· chefs de projet

· Analyste métier

· Assistant à la maîtrise d’ouvrage

· Urbaniste.

Niveau requis

Pour bénéficier pleinement de ce cours, les stagiaires doivent avoir :

· Une Connaissance générale en informatique.

· Une compréhension des enjeux des SI dans l’entreprise

Ainsi, en cette fin 2009, le programme du séminaire :

Introduction à l’Architecture d’Entreprise et à l’EAI (Entreprise Application Intégration

Présenter des problématiques d’intégration des applications  d’Entreprise (EAI)

· Définition du SI

· Les motivations de l’Architecture de SI

· Nouvelles architectures informatiques

· Métaphore de la cité & Plan d’occupation des sols (POS)

· intégration des applications  d’Entreprise (EAI)

· EAI & Architecture d’entreprise

Architecture des systèmes distribués, interopérabilité et standards

Présenter l'évolution des architectures de système d’information et définir les architectures n-tiers et le besoin d’interopérabilité

o Evolution des architectures informatiques

o Comparaison de l’architecture centralisée, client/serveur et n-tiers

o Applications distribuées : contraintes de Conception

o Applications distribuées :  l’Interopérabilité

o Cadre Commun d’interopérabilité :  préconisations

o Architectures d’interopérabilité

o Présentation de XML

-- XML les objectifs de conception

-- Notion de base : balise et attributs

-- Pourquoi XML?

-- La notion de Schéma XML

o Formats d’échange, Interopérabilité et portabilité des données

SOA (Architecture Orientée Service) et EDA

Présenter la démarche SOA, et présenter des concepts et de la démarche SOA (architecture orientée services), des besoins en infrastructures et de la notion de maturité SOA

o Problématique de l’intégration en entreprise et intra-entreprises 

o SOA : initialement un  simple besoin d‘intégration

o SOA, différents points de vue

o Présentation du concept SOA

o La notion de service (au sens SOA)

o Exemple de tendance du marché : Adoption de SOA dans le domaine des ERP

o SOA s’applique à tous les niveaux de l’EAI

o Principes fondamentaux de l’architecture SOA

o Cycle de vie d’un service

o Zoom sur la phase d’identification des services : quelle approche

MOM : Middleware Orienté Messagerie

Présenter les fonctions d'un MOM

o - Middleware Orienté Message : les clés de l'intégration grâce aux mécanismes asynchrones. Les fonctions principales d'un MOM : routage, intégrité transactionnelle, déclenchement de processus.

o - L'opportunité de désolidariser les applications pour assurer la flexibilité d'une solution EAI. Acteurs et enjeux : IBM, BEA, TIBCO.

o La norme JMS de Java EE

o Les offres du marché de l'EAI

-- Un marché très mouvant

-- - L'évolution des acteurs.

-- Typologie des offres existantes.

-- Les bénéfices escomptés et constatés.

-- - Les applications Extranet inter-entreprises : quels usages, quel cadre technique, quelles performances ?

-- Panorama du marché : offre commerciales et open source

SOA entre les concepts, la technique et les standards

Présenter les aspects techniques, les standards qui soutiennent le concept SOA

o Quels sont les éléments clé d’une architecture orientée services ?

o Services Web  : les spécifications XML de base

-- SOAP

-- WSDL

-- UDDI

-- BPEL

o Besoins d'interopérabilités : WS-I et Basic Profiles

o SOA : quelles infrastructures?

o EDA : Event Driven Architeucre

o ESB : un bus au service de SOA

o La relation entre SOA & EDA

o Notion de SLA et les besoins non fonctionnels

o Le besoin de supervision dans une architecture SOA

o La notion de maturité SOA

Choix et mise en œuvre

o Les critères de choix d’un MOM

o Une démarche spécifique et globale

o - L'organisation de l'équipe, le profil des différents intervenants.

o Ce qui change et ce qui reste par rapport à une approche classique.

o Le rôle de l'utilisateur. Les nouveautés de la phase de conception.

o La gestion des flux et des informations.

o L'administration de données.

o La migration des applications existantes pour les connecter au système EAI.

Synthèse

o - Enjeux, projection du marché et des acteurs.

o Principaux pièges à éviter et recommandations.

---------

NB

Pour s’inscrire au séminaire une adresse : info@oxia-group.com

jBPM 4.1 Released with a new BPM console and web based jPDL process designer

(http://net-progress.blogspot.com)

This JBossWorld, two prinicples announces: the launch of the GateIn Portal (merge of exo Portal & Jboss Protal) and the released of jBPM 4.1.

The download contain, the web based jPDL process designer, withc is the result of wollabration betwaenn Jboss, Signavio and Oryx.

Other things added, in the jBPM 4.1 release,

Tomcat support in the console (the BPM Conosle 1.1.2, has beean released at the end of August 2009)

Improved installer to handle tomcat and more configuration options ( we will try it, as soon as possible,

Extended coverage of Continuous Integration and reduced the execution time

Fix process variables of type hibernate-long-id/hibernate-string-id

Domain model integration

And a bunch of bug fixes

Now is time to try this release, the jBPM 4.1

-------------------

for information on GateIn Portal (merge of exo Portal & Jboss Protal) http://blog.exoplatform.org/2009/09/03/gatein-portal-released-the-first-deliverable-to-come-from-exo-and-jboss-collaboration/

Jbpm 4 Tutorial: JBPM 4, which is BPMN compliant, simplifies his programming model

Now that, JBPM, has passed the difficult age of childhood, and that it is a very popular BPM framework, his adopted father RedHat (JBoss owner) has decided to change everything: programming model and schema database.

Its goal: to simplify the programming model, to increase the number of adoptions and to reinforce the shift to the PVM (Processs Virtual Machine).

Programming model revised

This version 4 JBPM is a complete rewrite from version 3: while retaining the basic principles: open source, 100% Java, concept of process, storage of instances and definitions of process into the database, based on Hibernate, assisted by IDE.

Many users jbpm 3 will agree with me that certain APIs are difficult and that they needed to write complex queries Hibernate, leading to several problems.

With the mixture of concepts in JBPM 3 APIs, methods are scattered in classes JbpmContext, GraphSession or TaskManager.

The JBPM 4’s team has rationalized all BPM concepts, around the API ProcessEngine.

Any use of JBPM starts by acquiring the services desired from ProcessEngine: the central node of BPM by RedHat.

Use the API as needed

RepositoryService: allows to manage static data processes: deployment, activation / deactivation request ExecutionService: exposes runtime execution operations (for process instances): start executing process instances, manage variables, retrieve instances, etc. TaskService: it is the modeling of human interaction: everything to manage tasks: create, search, assign, complete..

Two other APIs have made their appearances:

• HistoryService: In JBPM 4 there is a clear separation between the runtime and data archiving. This service provides statistical measurements and calculations performed by the engine. This API has no relation with the runtime: it discusses the history and times past. Through this service the historical data (instances completed, work performed) can be searched and presented a statistical study Later.

• ManagementService: This API is intended for tools to manage processes telque famous JBPM console.

Database Schema simplified

Hibernate mapping is as follows

1:            <mapping resource="jbpm.repository.hbm.xml" /> 
2:            <mapping resource="jbpm.execution.hbm.xml" /> 
3:            <mapping resource="jbpm.history.hbm.xml" /> 
4:            <mapping resource="jbpm.task.hbm.xml" /> 
5:            <mapping resource="jbpm.identity.hbm.xml" /> 

A first test of the new version of JBPM: Version 4 JBPM

It is a simple example of a process containing two steps: one to display a message and another to launch a backup

JBPM 4 uses the notation BPMN 2.0

The XML version of this process definition:

1:  <?xml version="1.0" encoding="UTF-8"?> 
2:  <process name="seconde_hello_de_OXIA" xmlns="http://jbpm.org/4.0/jpdl"> 
3:       <start g="24,72,80,40"> 
4:            <transition to="afficherMessage"/> 
5:       </start> 
6:       <java class="com.oxia.att.jbpm4.exemple.AfficherMessage" g="120,68,138,56" method="afficherMessage" name="afficherMessage"> 
7:            <transition to="lancerBackup"/> 
8:       </java> 
9:       <end g="165,267,80,40" name="fin"/> 
10:    <state name="lancerBackup" g="143,147,92,52"> 
11:     <transition name="to fin" to="fin" g="-30,-18"/> 
12:    </state> 
13:  </process> 

The java class for Handling the message (very very simple ) :

1:  package com.oxia.att.jbpm4.exemple; 
2:  public class AfficherMessage { 
3:       public void afficherMessage() { 
4:            System.out.println("****** début de passage par un Etat"); 
5:            System.out.println("  Bonjour de OXIA!"); 
6:            System.out.println("****** fin de passage par un Etat "); 
7:       } 
8:  } 

To test this process in a Java project (very basic steps )

1:  public static void main(String[] args) { 
2:            // get the ProcessEngine instance  
3:            ProcessEngine processEngine = new Configuration().setResource("oxia.att.jbpm.cfg.xml").buildProcessEngine(); 
4:            // get one instance of the RepositoryService  
5:            RepositoryService repositoryService = processEngine.getRepositoryService(); 
6:            // Deploy the process definition du processus  
7:            repositoryService.createDeployment().addResourceFromClasspath("com/oxia/att/jbpm4/exemple/first_Jbpm_Sample.jpdl.xml").deploy(); 
8:            // get one instance of the ExecutionService  
9:            ExecutionService executionService = processEngine.getExecutionService(); 
10:            ProcessInstance processinstance = executionService.startProcessInstanceByKey("hello_de_OXIA"); 
11:             System.out.println(     processinstance.getId()); 
12:             System.out.println(     processinstance.getState()); 
13:       } 

The Result:

1:  ****** début de passage par un Etat 
2:    Bonjour de OXIA! 
3:  ****** fin de passage par un Etat  
4:  hello_de_OXIA.6 
5:  ended 

Conclusion

RedHat has restructured JBPM 4 around a simplified API and a clear pattern of effective database.

Reste à vérifier les annonces concernant l’amélioration des performances : grâce au nouveau schéma de base de données, la récriture des classes de bases de Job executor et activities et l’amélioration de la gestion de la concurrence.

It remains to check the listings for improving performance: thanks to the new schema database, the rewriting the basic classes of Job executor and activities and improving concurrency management.

(fr)

Autre sujets

1. Un peu de monitoring Métier (BAM) avec JBPM et SeeWhy (event-driven business intelligence )

2. Comment modéliser un processus métier avec JBPM : exemple “gestion des entretiens”

3. Quelle est la différence entre JBPM et Intalio ?

4. Graph Oriented Programming (GOP) avec JBPM

5. BPM & Moteur de workflow : l’offre open source

6. La version 4 de JBPM prend le virage de BPMN

7. Jbpm 4 Tutorial : JBPM 4 a simplifié son model de programmation et a confirmé l’orientation BPMN