Démarrage manuel d'un ruleset

Normalement, ELOas exécute les rulesets définis dans des intervalles définis. Il existe également des processus qui sont si "volumineux" qu'ils ne peuvent pas être exécutés dans des intervalles courts, mais qui doivent être actifs rapidement après certaines modifications. Il existe la possibilité d'exécuter un ruleset manuellement par un URL (ou par script).

L'exécution de la règle par le biais d'une commande "HTTP-GET" ou "HTTP-RUN" est sécurisée par défaut dans ELOas 20 avec un ticket. Afin que la règle ELOas soit exécutée, un ticket valide doit être ajouté à l'URL ELOas correspondante.

http://localhost:9060/ELOas/actions?cmd=get&name=test&ticket=935666A2E27D8AB642C4C40AFAEAE2B9

La vérification de ticket interne peut être désactivée par le biais d'un nouveau paramètre de configuration ELOas du nom checkTicket.

Illustr. : config.xml

Attention

L'utilisation de ELOas avec une vérification de ticket désactivée au mode proxy présente un risque en termes de sécurité du système. Surtout, si le serveur d'indexation ELO est disponible sur Internet.

Exemple

L'exemple suivant montre comment l'on peut appeler un ruleset depuis un script client, qui pourra modifier certains objets.

Attention : étant donné que l'appel se fait par le biais d'un accès http, chaque utilisateur peut déclencher cette action avec un navigateur ou avec la commande d'un script. Vous devez donc vous assurer que la fonction ne puisse pas être exécutée à mauvais escient (par exemple par le contrôle du numéro utilisateur ou par une directive interne fixe de l'objet ID).

Tout d'abord, il s'agit de prendre en considération le ruleset utilisé. En entrant un intervalle de 0 minutes (<interval>0H</interval>), ce ruleset est défini manuellement. L'appel n'est donc pas cyclique, il attend la réception d'une URL bien précise.

<ruleset>
    <base>
        <name>Expand Name</name>
        <search>
            <name>"OBJIDS"</name>
            <value></value>
            <mask>2</mask>
            <max>200</max>
        </search>
        <interval>0H</interval>
    </base>
<rule>
    <name>Expand Name</name>
    <condition></condition>
    <script>
        log.debug("Param1: " + EM_PARAM1);
        log.debug("UserId: " + EM_USERID);
        NAME = "Freigegeben: " + NAME;
        EM_WRITE_CHANGED = true;
    </script>
</rule>
<rule>
    <name>Global Error Rule</name>
    <condition>OnError</condition>
    <script></script>
</rule>
</ruleset>

La partie intéressante se trouve dans la section des scripts.

<script>
    log.debug("Param1: " + EM_PARAM1);
    log.debug("UserId: " + EM_USERID);

L'appel peut donner jusqu'à trois paramètres. Ceux-ci peuvent être demandés par les variables EM_PARAM1, EM_PARAM2 et EM_PARAM3. Par ailleurs, le script peut donner le ticket de l'authentification actuelle pour la nouvelle authentification. Dans ce cas, la variable EM_USERID est remplie avec le numéro de l'utilisateur authentifié. S'il n'y a pas d'authentification, le numéro utilisateur est occupé avec -1. Dans le premier paramètre, l'on peut transmettre un ou deux identificateurs d'objets, ceux-ci écrasent alors la valeur Search provenant de la définition des rulesets. Dans ce cas, le nom du champ des métadonnées doit être "OBJIDS".

NAME = "Approuvé: " + NAME;

Dans notre exemple, le texte "autorisé" est placé devant la désignation des objets sélectionnés. Mais il est également possible d'effectuer d'autres modifications de l'objet SORD.

EM_WRITE_CHANGED = true;

Etant donné que l'objet a été modifié, il doit également être enregistré.

</script>

Activation du ruleset

Une fois ELOas démarré, ce ruleset est également démarré, mais il n'est pas encore actif. Il attend un déclencheur externe (visible au texte "trigger" dans le champ Next run).

Illustr. : page de statut ELOas

Le déclenchement peut être fait par l'appel d'une URL, ou encore depuis le client Windows par une commande de script (à partir de la version de client 7.00.056):

SendELOasRequest( <nom du serveur>, <numéro du port>, <nom de service>, <avec ticket>, <nom du ruleset>, <paramètre 1>, <paramètre 2>, <paramètre 3)

La commande SendELOasRequest effectue un appel asynchrone avec run. Ce ruleset est affiché dans la console d'administration ELO, non pas sous Direct, mais sous Règles.

Nom de serveur	Nom ou adresse IP du serveur ELOas.
Numéro de port	Numéro de port du serveur ELOas. Normalement, 8080, port http standard.
Nom de service	Nom de service du serveur ELOas. Dans une installation standard, il se compose du préfixe as- et du nom d'archive (par exemple as-ELO). Il faut absolument faire attention aux minuscules et majuscules, sinon, le serveur Tomcat annonce une erreur.
Avec ticket	0: ne pas envoyer les informations d'authentification
	1: envoyer le ticket actuel en tant qu'information d'authentification. Dans ce cas, ELOas vérifie le ticket et détermine le numéro utilisateur à partir de celui-ci. Cette information est mise à disposition au ruleset. Dans le ruleset, l'on peut décider si l'action est exécutée, et dans quelle mesure.
	actuellement, les informations d'authentification ne peuvent pas être évaluées lors de l'authentification SSO. Ce ne sera plus le cas dans la prochaine version du serveur d'indexation.
Nom du ruleset	Nom du ruleset à exécuter. Seuls les rulesets déclenchés peuvent être appelés. L'appel est ignoré pour les rulesets commandés par intervalle.
Parameter1	premier paramètre. Ce paramètre est utilisé comme terme de recherche pour l'exécution de ruleset , à condition qu'il ne soit pas vide.
Parameter2, Parameter3	autres paramètres en option Ceux-ci peuvent être demandés par le ruleset et diriger l'exécution.

Le script d'exemple complet pour un appel peut ressembler à ceci. Il appelle le ruleset Expand Name pour les objets avec l'ID d'objet 7944 et 7945.

Set Elo=CreateObject("Elo.Professional")
MsgBox Elo.SendELOasRequest("localhost", 8084, "/ELOmover/as" , 1, "Expand Name", "7944,7945", "TestParam2", "")

Le ruleset peut être déclenché par l'appel d'une URL depuis d'autres applications:

http://localhost:8084/ELOmover/as?cmd=run&name=Expand%20Name&param1=7944,7945&param2=TestParam2

Remarque

Dans ce cas, nous ne pouvons pas donner d'informations d'authentification. Vous pouvez vous assurer dans votre ruleset que les données ne sont pas utilisées à mauvais escient.

Autres remarques

Déclenchement asynchrone du ruleset

Si un ruleset est déclenché par une adresse URL ou un appel de script, ELOas l'exécute de façon asynchrone. Si alors un autre ruleset est actif actuellement, l'exécution de script n'est pas retardée jusqu'à ce que ELOas soit disponible. Au lieu de cela, la commande d'activation est placée dans une file d'attente et effectuée à la prochaine occasion.

Cela a deux conséquences: le script client ne peut pas être sûr que l'opération a été exécutée si la commande a été traitée. Si c'est important pour le déroulement ultérieur du script, cela doit être vérifié dans le script en lui-même, puis intégré dans une file d'attente. Attention! Il se pourrait que ELOas effectue en ce moment même d'autres actions importantes. En général, un script ne devrait pas attendre la clôture d'une action ELOas.

Par ailleurs, il se pourrait qu'un utilisateur impatient active plusieurs fois le déclenchement. Dans ce cas, le ruleset est exécuté plusieurs fois. Il devrait donc être configuré de manière à ce que ce déclenchement ne cause pas d'erreurs, par exemple lors d'une vérification de l'objet et de l'exécution qui s'est répétée.

Une autre conséquence découlant de l'exécution asynchrone: les erreurs apparues lors du traitement du ruleset ne peuvent pas être notées par le biais de l'appel.

Déclenchement synchrone du ruleset

Le ruleset est exécuté directement lors du déclenchement synchronisé et peut également rendre un résultat. Le déclenchement synchronisé est surtout utilisé par le processus ELO (créateur de formulaires). Lors de l'appel, cmd=get est requis au lieu de cmd=run. Par ailleurs, les rulesets pour l'appel synchronisé ne doivent pas se trouver dans le classeur Rules, mais dans le classeur Direct. Les rulesets synchrones sont exécutés dans un propre thread indépendamment des rulests asynchrones.

Vérification des autorisations

Lors de l'appel à partir du client Windows, le ticket client de l'authentification peut également être transféré en option. Dans ce cas, ELOas peut vérifier l'authentification et déterminer l'utilisateur actuel. En cas d'actions critiques, une vérification quant à un utilisateur autorisé devrait être faite dans le ruleset, et si l'authentification manque, l'exécution devrait être interrompue.

Un déclenchement anonyme peut être acceptable dans certains cas. Par exemple parce qu'un objet défini est traité. Dans ce cas, l'on doit veiller à ce que l'ID d'objet ne peut pas être modifié par l'appel. Cela peut se faire simplement dans l'événement onstart, la valeur est placée par EM_SEARCHVALUE dans le script. Dans ce cas, ce n'est pas le paramètre, mais la valeur pré-réglée du script ruleset qui est utilisée.

Ordre d'exécution

Un ruleset déclenché manuellement s'enclave normalement dans l'ordre d'exécution des rulesets. Si plusieurs déclencheurs existent pour un ruleset, tout d'abord, tous les déclencheurs sont exécutées, avant que le prochain ruleset soit traité.