Exemple - Treewalk pour ELOas

Une fonction de navigation dans l'arborescence est disponible pour le traitement des documents dans les services d'automation ELO. Non seulement des sections de recherche peuvent être traitées, mais aussi des structures d'arborescence intégrales.

Introduction

Normalement, ELOas effectue une recherche de champ d'indexation, afin de déterminer la liste des documents à traiter. En alternative, il est possible d'exécuter également un tree walk. Ce treewalk vous permet parcourir des branches d'archive ou l'archive intégrale. Chaque entrée est parcourue deux fois: une fois lors de l'entrée, ensuite, toutes les sous-entrées sont parcourues, puis, lors de la sortie.

Exemple: il existe une armoire avec les classeurs 1 et 2. Le classeur 1 contient le registre 1.1. Il en découle le déroulement suivant:

Armoire (entrer)
Classeur 1 (entrer)
Registre 1.1 (entrer)
Registre 1.1 (quitter)
Classeur 1 (quitter)
Classeur 2 (entrer)
Classeur 2 (quitter)
Armoire (quitter)

Un script peut vérifier à l'appui des variables EM_TREE_STATE si le ruleset est appelé dans la branche croissante (entrée) ou encore dans la branche décroissante (sortie). Celui contient 0 lors de l'entrée et 1 lors de la sortie. L'enregistrement se fait seulement lors de la sortie. Les modifications qui sont exécutées lors de l'entrée restent telles quelles jusqu'à la sortie, même si d'autres objets ont été traités entre-temps.

Pour initier un treewalk, il suffit d'entrer la valeur "TREEWALK" dans le nom de groupe de l'index de recherche, et en tant que terme de recherche, le numéro du noeud de démarrage. Attention! Sur le noeud de démarrage, aucune règle n'est appelée. Cette règle n'est exécutée que pour les sous-entrées.

Exemple

L'exemple d'application suivant parcourt une branche d'archive et place un identificateur interne (TrackID) dans tous les objets du type de masque 6 (Track Item). Le classeur de démarrage possède l'ID 3352.

Dans cet exemple, nous n'avons pas prévu de traitement des erreurs, c'est pourquoi la règle correspondante est vide.

<ruleset>
    <base>
        <name>Create TrackId</name>
        <search>
            <name>"TREEWALK"</name>
            <value>3352</value>
            <mask>6</mask>
            <max>200</max>
        </search>
        <interval>10M</interval>
    </base>
<rule>
    <name>CreateId</name>
    <script>
        if ((EM_TREE_STATE == 1) &amp;&amp; (EM_ACT_SORD.getMask() == 6)) {
            // nur TrackItems bearbeiten
            //cnt.createCounter("ETSTrackId", 10000);
            if (ETS_TICK == "") {
                log.debug("Create new TrackId: " + NAME);
                ETS_TICK = cnt.getTrackId("ETSTrackId", "V");
                EM_WRITE_CHANGED = true;
            }
        }
    </script>
</rule>
<rule>
    <name>Global Error Rule</name>
    <condition>OnError</condition>
    <script>
    </script>
</rule>
</ruleset>

La partie intéressante du ruleset se trouve dans la section de script, voici une liste individuelle:

if ((EM_TREE_STATE == 1) && (EM_ACT_SORD.getMask() == 6)) {

Le script doit seulement être exécuté lors de la sortie (EM_TREE_STATE == 1) et seulement sur les objets du type TrackItem (EM_ACT_SORD.getMask() == 6).

// modifier seulement TrackItems
//cnt.createCounter("ETSTrackId", 10000);

L'exemple utilise un counter qui doit être créé ultérieurement, par exemple par la commande nommée ci-dessous. Il peut seulement être créé une fois, sinon, le Track ID est ré-initialisé à chaque fois.

if (ETS_TICK == "") {

S'il n'existe pas encore de Track ID (en d'autres termes, si le champs de métadonnées ETS_TICK est vide), alors il s'agit d'en créer un.

log.debug("Create new TrackId: " + NAME)
ETS_TICK = cnt.getTrackId("ETSTrackId", "V")

Pour créer des tracks ID, il existe une méthode très pratique dans le module counter cnt: getTrackId(<CounterName>, <Prefix> ). Cette méthode prend une nouvelle valeur counter et la complète avec le préfixe et une somme de contrôle. Dans notre exemple, la valeur Counter 10001 devient le Track ID V10001C2.

EM_WRITE_CHANGED = true

L'objet doit seulement être enregistré si un nouveau ID de traçage a été créé.

}
}

Le ruleset est exécuté toutes les 10 minutes et parcourt l'intégralité du classeur Track Item. Toutes les entrées sans track ID sont complétées automatiquement, peu importe avec quel client elles ont été créées.

Variables de Runtime Environment

Si le ruleset est exécuté, il existe de nombreuses variables en plus de la valeur EM_TREE_STATUS qui peuvent être prises en compte.

Nom	Contenu
EM_TREE_STATUS	Définit si le ruleset est exécuté dans la branche croissante (0) ou décroissante (1).
EM_ACT_SORD	Contient l'objet SORD avec les données d'objet actuelles.
EM_PARENT_SORD	Contient l'objet SORD avec les données du noeud parent. Ces données peuvent être modifiées par principe. Il faut veiller à ce que ces modifications soient enregistrées. A ces fins, la modification doit être reconnue dans la branche décroissante, et le drapeau EM\_WRITE\_CHANGED doit être placé sur true.
EM_ROOT_SORD	Contient l'objet SORD avec le noeud de démarrage. Etant donné que le ruleset n'est pas appliqué sur cette entrée, un enregistrement manuel doit être effectué lors de modifications. Cela peut se faire par exemple en plaçant la variable EM_SAVE_TREE_ROOT.
EM_INDEX_LOADED	A l'opposé d'un traitement après une recherche, l'on ne peut pas s'assurer qu'un objet SORD chargé possède un masque bien précis dans le tree walk. En principe, chaque masque peut apparaître. Les variables d'indexation prédéfinies peuvent seulement être créées et remplies à partir des champs de métadonnées pour les masques qui ont été authentifiés dans la définition sous <mask>et sous <masks>. Dans ce cas, la variable EM_INDEX_LOADED est placée sur true. S'il existe un masque inconnu, l'accès aux champs de métadonnées est seulement possible par le biais de l'objet EM_ACT_SORD, EM_INDEX_LOADED a le statut false.
	Remarque: si les variables d'indexation sont remplies, l'on ne doit pas modifier directement les champs de métadonnées dans EM_ACT_SORD. Ces modifications sont perdues avant l'enregistrement, quand les variables d'indexation sont écrites.
EM_TREE_LEVEL	Cette variable permet de voir à quel niveau du tree walk l'on se trouve. Les sous-entrées du noeud de démarrage se trouvent au niveau 0 (les règles ne sont pas appelées pour le noeud de démarrage).
EM_TREE_MAX_LEVEL	L'on peut déterminer la profondeur maximale par le biais de cette règle. Les sous-entrées encore plus profondes sont ignorées. Normalement, la valeur est 32. S'il doit être modifié, il peut être placé sur la valeur souhaitée avant le traitement dans la routine onstart.
EM_SAVE_TREE_ROOT	Aucune règle n'est appelée pour le noeud de démarrage du treewalk. Si celui-ci a été modifié par l'accès EM_TREE_ROOT ou EM_PARENT_SORD, un enregistrement de ces modifications doit être authentifié par le placement des variables EM_SAVE_TREE_ROOT.
	<onend>var result = …var oldstate = …EM_SAVE_TREE_ROOT = result != oldstate;log.debug("now save root: " + EM_SAVE_TREE_ROOT);</onend>
EM_TREE_EVAL_CHILDREN	Si le logiciel remarque qu'une sous-section est exclue du traitement, la variable EM_TREE_CHILDREN est placée sur false. Cette valeur est évaluée seulement pour la branche croissante (il serait trop tard pour la branche décroissante, étant donné que la sous-section a déjà été passée) et il est initialisé avec true pour chaque objet (le comportement standard est que l'intégralité de la sous-section est passée).
EM_TREE_ABORT_WALK	Si une passation doit être complètement annulée, l'on peut placer le drapeau EM_TREE_ABORT_WALK à n'importe quel moment. Dans ce cas, aucune autre sous-entrée n'est passée. Les autres entrées du même niveau, qui n'ont pas encore été traitées, restent ainsi. L'on peut placer ce flag afin d'annuler le travail après une erreur grave.
	Remarque : dans la routine onstart, les contrôles de runtime peuvent être exécutés afin de vérifier si le treewalk peut être effectué. Sinon, vous pouvez interrompre le runtime par le biais de ce drapeau.