Une des principales bonnes pratiques de conception d’un processus est son découpage en sous ensemble simple.  Il s’agit du niveau de granularité du processus ce qui permet entre autre de :

• Transformer un problème complexe en sous ensemble simple

=> Amélioration de la maintenabilité

• Réaliser des tests de non régression sur un sous ensemble et non sur sa globalité.

=> Amélioration de la qualité

• Faciliter l’identification d’un incident, par exemple dans Enterprise Manager

=> Amélioration de son exploitabilité

Nous allons appliquer ce principe dans le cadre des transformations XSLT au sein d’Oracle SOA Suite.

Nous utiliserons comme exemple un processus BPEL  qui a pour objectif de renvoyer une liste de personnes selon différents  critères de recherche. Une personne est considérée comme trouvée si :

1. Le nom et prénom renseignés et ceux retournés par le service de recherche correspondent

2. Le prénom et la date de naissance renseignés et ceux retournés par le service de recherche correspondent

3. Le nom, la date de naissance et la première lettre du prénom renseignés et ceux retournés par le service de recherche correspondent

Solution 1 –Solution globale et entièrement graphique

La réalisation graphique en un seul traitement de cet exemple donne le résultat suivant:

Dans ce cas simple le résultat reste encore lisible mais difficilement modifiable et source d’erreur humaine (Syndrome du nœud de liens en spaghettis)
En cas d’évolution d’une des trois règles l’ensemble doit être testé à nouveau avant livraison, ce qui engendre un surcoût.
Le code XSLT généré quant à lui est trop complexe pour une lecture humaine aisée.

<xsl:for-each select="$ResultatRechercheSelonCriteres/ns1:RechercheSelonCriteres">
<xsl:if test="(((ns1:PersonneTrouvee/pers:Nom = /ns0:FormatEntree/ns0:PersonneAValider/pers:Nom) and (ns1:PersonneTrouvee/pers:Prenom = /ns0:FormatEntree/ns0:PersonneAValider/pers:Prenom)) or ((ns1:PersonneTrouvee/pers:Prenom = /ns0:FormatEntree/ns0:PersonneAValider/pers:Prenom) and (ns1:PersonneTrouvee/pers:DateNaissance = /ns0:FormatEntree/ns0:PersonneAValider/pers:DateNaissance))) or (((ns1:PersonneTrouvee/pers:Nom = /ns0:FormatEntree/ns0:PersonneAValider/pers:Nom) and (ns1:PersonneTrouvee/pers:DateNaissance = /ns0:FormatEntree/ns0:PersonneAValider/pers:DateNaissance)) and contains(ns1:PersonneTrouvee/pers:Prenom,substring(ns1:PersonneTrouvee/pers:Prenom,1,1)))">

Solution 2 – Mise en place de template

Une autre solution est de séparer chaque règle fonctionnelle dans une sous fonction ou template. Pour cela nous allons créer un template correspondant à chaque règle métier
Pour chaque template il faut définir

• Son nom, par exemple « RegleMetier01 »

• Les différents variables d’entrées. Dans notre exemple les noms et prénoms à comparer.

• Le traitement à effectuer. Dans notre exemple la comparaison des noms et prénoms dans un test de type «when / otherwise ». En fonction du résultat sera renvoyer 0 ou 1 pour trouvé

<xsl:template name="RegleMetier01">
  <xsl:param name="PrenomEntree"/>
    <xsl:param name="NomResultatRecherche"/>
    <xsl:param name="PrenomResultatRecherche"/>
    <xsl:choose>
     <xsl:when test="$NomEntree = $NomResultatRecherche and $PrenomEntree = $PrenomResultatRecherche">1</xsl:when>
     <xsl:otherwise>0</xsl:<xsl:template name="RegleMetier01">
    <xsl:param name="NomEntree"/>
    otherwise>
    </xsl:choose>
 </xsl:template>

Le test effectué pour chaque règle est facilement lisible et modifiable sans risque de régression.
De plus chaque template créé est directement utilisable dans l’éditeur graphique

Chaque template est utilisable comme n’importe quelle fonction standard. Dans notre exemple nous retrouvons les entrées précédemment définies

Pour compléter notre exemple nous pouvons créer un template qui va exécuter l’ensemble des règles fonctionnelles et renvoyer le résultat sous forme de score. (0 pour non trouvé) La représentation graphique est la suivante

Les avantages de cette solution sont les suivants :

• Un découpage structuré par template pour chaque règle métier. Il est très facile de comprendre la logique de développement à partir de la lecture d’une spécification fonctionnelle et d’en faire évoluer une seule

• Une approche KISS (Keep it Simple, Stupid) visant la simplicité de chaque opération