Créer un trigger en java

Je viens de passer quelques heures a essayer de faire un trigger qui fait quelques vérifications lors de la création d'objets de type Document.
Je crée donc un "eService Trigger Program parameters" (que je nomme TypeDocumentCreateCheck) dans lequel j'indique l'eService Program Name (AA_DocumentRelatedTrigger), l'eService Sequence Number (que je définis a 1 puisque c'est le seul trigger qui est appelé avant la création d'un Document) ainsi que la policy que je définis a eService Trigger Program policy. Je le promote ensuite en Active.

J'indique ensuite sur le thick client, dans l'onglet Triggers du type Document, d'appeller emxTriggerManager (le Manager de Triggers) avec le paramètre TypeDocumentCreateCheck lors de l'evenement "create".

Je crée ensuite un objet de type Program que je nomme AA_DocumentRelatedTrigger, de type MQL, et j'écris le code suivant :

Code:

tcl;
eval {
return 1
}

Le return 1 bloque donc la création de Document. Si je fais un return 0 je peux de nouveau créer des Document. Mon trigger est donc bien appellé et tout a l'air de fonctionner normalement.

Je prefererai par contre écrire ce program en java. Je change donc le type du Program et je replace mon précédent code par :

Code:

import matrix.db.*;
 
public class ${CLASSNAME}
{
 
 
    public ${CLASSNAME}(Context ctx,String[] args)
    {

    }

    public int mxMain(Context ctx,String[] args)
    {
        return 0;
    }

}

Par défaut emxTriggerManager devrait appeller la méthode mxMain. Je vais donc tester la création de Document, mais la dans le thin client j'obtient un popup qui me dit "System error:#5000001: Check trigger blocked event" bien que mxMain retourne 0. J'avoue ne pas avoir telement trouvé d'infos sur l'obligation (ou pas) d'indiquer les parametres (ctx et args) dans l'eService Trigger Program parameters, mais d'après ce que je vois dans d'autres triggers ca n'a pas l'air obligatoire. Lorsque j'essaye de créer un Document directement en MQL j'obtiens :

Code:

Error: #1900068: add business object failed
System Error: #5000001: java.lang.NoClassDefFoundError: com/matrixone/apps/domain/util/FrameworkException

Enfin je ne comprend pas ce qui ne va pas. Quelqu'un aurait il une idée ?

Merci !

Bon finalement c'est un probleme de classpath sur ma machine ainsi que sur le serveur.
J'ai copié le contenu de MATRIXHOME/java/lib et MATRIXHOME/java/properties qui sont sur le serveur, sur ma machine et du coup ca marche avec le thick client.

Sur le serveur, la librairie concerné est bien dans mon WEB-INF/lib mais elle n'a pas l'air d'etre prise en compte, alors que si je la met dans TOMCAT_HOME/lib ou bien dans WEB-INF/classes ca marche (nous utilisons la version 5.5 de Tomcat)

Je viens de remettre les librairies la ou elles étaient, je redémarre tomcat, et la ..... ca marche .....
Bon l'essentiel c'est que ca marche mais j'avoue que je ne comprend pas ce qui a pu se passer

Bon par contre tant que j'y suis, quelqu'un saurait comment je peux choisir le contenu de la popup qui s'affiche lorsque le trigger refuse la création de l'objet ? Quand je throw une exception elle s'affiche dans la popup a la suite de quelques "System Error" etc, ce qui n'est pas tres joli.

Bon weekend !

Heu...

J'ai plusieurs questions :

• Pourquoi as-tu un "check trigger block event" alors que tu es sur un trigger d'action?
  Ce message est normalement réservé aux triggers de check afin de renvoyer à l'utilisateur un message du type :

  Attention il manque qqch

  ou bien

  Je crois que toutes les conditions de sont pas bonnes

  .
  
• Pourquoi ne pas utiliser l'attribut "eService Method Name" du type "eService Trigger Program Parameters" qui te permet d'aller directement dans une méthode que tu crées pour ton traitement?
  
• Pour les librairies, il faut prendre en compte le fonctionnement de ton RMI, peux-tu me donner un peu plus d'informations sur son exécution, stp?

Tiens, je te joins un exemple de programme JPO, qui lance une vérification bidon :

Code:

/*
* **********************************************************
* ** EN TETE DU JPO
* **********************************************************
*/

import matrix.db.*;
import matrix.util.*;
import java.io.*;
import java.util.*;
import java.text.*;
import com.matrixone.apps.domain.util.*;
import com.matrixone.apps.domain.*;

public class ${CLASSNAME}
{

   /**
    * Constructor.
    */
   public ${CLASSNAME}  (Context context, String args[]) throws Exception {
   }

   /**
    * Main.
    */
   public int mxMain(Context context, String args[]) throws Exception {
   return 0;
   }

   /**
    * methodeFaireVerification.
    *
    * @parametre context L'objet <code>Context</code> eMatrix
    * @parametre args contient :
    * @        - l'identifiant de l'objet
    * @        - le nom de l'objet
    * @lance Exception si l'operation est en erreur
    * @retourne 0 si le nom est faux
    * @             1 si le nom est bon
    */
   public int methodeFaireVerification(Context context, String args[]) throws Exception {
   
      // Code d'erreur
      int iRetour = 0;

      //Recupere les informations
      String sObjectId = args[0];
      String sName = args[1];

      DomainObject dob = DomainObject.newInstance(context, sObjectId);
      String sNomObjet = dob.getInfo(context, SELECT_NAME);
      if (sName != null && !"".equals(sName) && !sNomObjet.equals(sName) ) {
         String sMsg = i18nNow.getI18nString("emxFramework.Msg.Error.Nom", "emxFrameworkStringResource", context.getSession().getLanguage());
         sMsg = sMsg +" "+sNomObjet+".";
         error(context, sMsg);
         iRetour = 1;
      }
      return iRetour;
   }

   public static void error(Context context, String sMsg) throws Exception {
      MQLCommand mqlCommand = new MQLCommand();
      mqlCommand.executeCommand(context, "error \\""+sMsg+"\\"");
   }

   public static void notice(Context context, String sMsg) throws Exception {
      MQLCommand mqlCommand = new MQLCommand();
      mqlCommand.executeCommand(context, "notice \\""+sMsg+"\\"");
   }
}

Pourquoi as-tu un "check trigger block event" alors que tu es sur un trigger d'action?

Hum j'ai pas dit que j'avais un trigger d'action, c'est bien un trigger de check.

Pourquoi ne pas utiliser l'attribut "eService Method Name" du type "eService Trigger Program Parameters" qui te permet d'aller directement dans une méthode que tu crées pour ton traitement?

J'ai fait exprès de ne pas l'utiliser pour être sur que mon problème ne venait pas du prototype de ma méthode ou bien de l'appel lui-même. Mais sinon oui je compte bien me servir de "eService Method Name".

Pour les librairies, il faut prendre en compte le fonctionnement de ton RMI, peux-tu me donner un peu plus d'informations sur son exécution, stp?

Comment ca ? Le trigger va en réalité chercher s'il existe un Document ayant le même nom que celui qui va être créé. Si c'est le cas, j'interdit la création du Document et j'affiche un message d'erreur. Le .jar dont j'avais besoin était uniquement domain.jar qui fait parti il me semble des librairies de base de matrix.

Merci encore pour ton aide !

Hum j'ai pas dit que j'avais un trigger d'action, c'est bien un trigger de check.

Désolé, j'ai mal lu.

Comment ca ? Le trigger va en réalité chercher s'il existe un Document ayant le même nom que celui qui va être créé. Si c'est le cas, j'interdit la création du Document et j'affiche un message d'erreur. Le .jar dont j'avais besoin était uniquement domain.jar qui fait parti il me semble des librairies de base de matrix.

Il me semble que matrix empêche, en standard, ce genre de cas. En effet, le TNR est une clef et elle doit valider l'unicité de l'objet. Donc à la création d'un objet, il vérifie que le TNR n'est pas déjà pris (et ça même avec des objectId différents). Il me semble que ce contrôle fait partie des AEF et qu'à ce titre tous les modules (EC, InfoCentral, ProductCentral, ...) y sont soumis. Si tu as un souci de ce coté là, je te conseille de voir avec Dassault car, il s'agit d'un bug.

Pour les librairies, il faut prendre en compte le fonctionnement de ton RMI, peux-tu me donner un peu plus d'informations sur son exécution, stp?

Pour ce point, je ne parlais plus de ton trigger mais de ton problème de jar. Pour vérifier l'accès aux librairies, il faut vérifier le ematrix.ini, le mode de lancement du RMI et l'application qui va compiler et utiliser les programmes (JPO = RMI, JSP = Serveur Web).
Peux-tu me donner un peu plus d'info, sur le lancement de tes applications, stp?

Il me semble que matrix empêche, en standard, ce genre de cas. En effet, le TNR est une clef et elle doit valider l'unicité de l'objet. Donc à la création d'un objet, il vérifie que le TNR n'est pas déjà pris (et ça même avec des objectId différents). Il me semble que ce contrôle fait partie des AEF et qu'à ce titre tous les modules (EC, InfoCentral, ProductCentral, ...) y sont soumis. Si tu as un souci de ce coté là, je te conseille de voir avec Dassault car, il s'agit d'un bug.

Oui en effet mais il est neanmoins possible de créer un nouveau document, ayant le meme nom qu'un document existant, et ayant une autre révisions mais n'étant pas lié a l'ancienne révision de ce document. (Mon probleme est par contre que lors d'un Revise mon trigger sera appelé de la meme facon).

Pour ce point, je ne parlais plus de ton trigger mais de ton problème de jar. Pour vérifier l'accès aux librairies, il faut vérifier le ematrix.ini, le mode de lancement du RMI et l'application qui va compiler et utiliser les programmes (JPO = RMI, JSP = Serveur Web).

oui oui mais c'est bon tout ca marche bien maintenant

Oui en effet mais il est neanmoins possible de créer un nouveau document, ayant le meme nom qu'un document existant, et ayant une autre révisions mais n'étant pas lié a l'ancienne révision de ce document. (Mon probleme est par contre que lors d'un Revise mon trigger sera appelé de la meme facon).

Lors de l'exécution de tes triggers, tu as les variables RPE (Runtime Program Environment). - tu peux les connaître en lançant une commande MQL (list env) dans ton trigger.
Ces variables ne sont pas les mêmes suivant les actions que tu réalises et tu peux donc t'en servir pour différentier les cas de traitements.
De plus, lors d'une révision, le nouvel objet est chaîner à la révision précédente, tu as donc tous les éléments pour vérifier qu'il ne s'agit pas d'un objet isolé.

Mais j'ai une autre question, pourquoi ne bloques tu pas la liberté de choix de la révision?

Lors de l'exécution de tes triggers, tu as les variables RPE (Runtime Program Environment). - tu peux les connaître en lançant une commande MQL (list env) dans ton trigger.

Génial je vais regarder ça

De plus, lors d'une révision, le nouvel objet est chaîner à la révision précédente, tu as donc tous les éléments pour vérifier qu'il ne s'agit pas d'un objet isolé.

Ah ok, je pensais en fait que la connexion avec l'ancienne révision se faisait qu'après la création du nouveau Document. Mais d'ailleurs il y a une chose dont je ne suis pas sûr : les connexions entre les différentes révisions ne sont pas faites avec des relations classiques si ? Parce que je ne les voit pas dans le navigator.

Mais j'ai une autre question, pourquoi ne bloques tu pas la liberté de choix de la révision?

En fait on va migrer un tas d'infos qui existe dans l'entreprise depuis longtemps. Je ne connais pas la raison mais il se trouve que certains documents ne commencent pas a la révision A et ont des numéros de révisions non consécutifs.

Petite autre question : par défaut Matrix ajoute un numéro a la suite du nom définis par l'utilisateur lors de la création d'un Document dans le thin client. Genre, si je veux créer le Document "Test", Matrix va le créer avec le nom "Test-867653543". Il m'est par contre possible d'aller re-modifier le nom ensuite pour supprimer ces chiffres. As tu une idée de pourquoi Matrix rajoute ces numéros ? et surtout de comment désactiver ce renommage automatique ? On pourrait croire que Matrix rajoute ces numéros afin de garder des noms de Document uniques, mais comme de toute manière une vérification de l'unicité du T-N-R est fait à la création de tout objet, cette unicité est déjà préserver, donc je comprend pas tellement l'intéret.

Merci !

Ah ok, je pensais en fait que la connexion avec l'ancienne révision se faisait qu'après la création du nouveau Document. Mais d'ailleurs il y a une chose dont je ne suis pas sûr : les connexions entre les différentes révisions ne sont pas faites avec des relations classiques si ? Parce que je ne les voit pas dans le navigator.

Je ne sais pas t'expliquer comment elle est construite mais ça n'a rien à vori avec les relation de base.

Pour voirs les révisions c'est soit en client lourd et web avec la commande "Revision", soit en mql avec :

Code:

<MQL>print bus Document TOTO A select revisions ;
businessobject Document TOTO A
    revisions = A
    revisions = B
    revisions = C

En fait on va migrer un tas d'infos qui existe dans l'entreprise depuis longtemps. Je ne connais pas la raison mais il se trouve que certains documents ne commencent pas a la révision A et ont des numéros de révisions non consécutifs.

Dans le cas où tu ne le saurais pas, matrix permet de chaîner des objets en révision même s'ils ne se suivent pas.
Cela est très intéressant lorsque tu migres, car tu traites d'abord la création à partir de tes fichiers sources et ensuite tu chaines ce que tu as besoin.
Exemple :
Je créé l'objet Document TEST_REVISE A
Je créé l'objet Document TEST_REVISE F
Je lie les deux objets en révisions
En mql cela donne :

Code:

add bus Document TEST_REVISE A policy "Document";
add bus Document TEST_REVISE F policy "Document";
revise businessobject Document TEST_REVISE A bus Document TEST_REVISE F;
print bus Document TEST_REVISE A select revisions ;
businessobject Document TEST_REVISE A
    revisions = A
    revisions = F

Attention : Il faut que l'objet à réviser (dans mon exemple le A) soit révisable ; qu'il soit le dernier de la chaîne et que l'état du CV le permette. Dans l'exemple TOTO, il faudrait utiliser la révision C.

Tu peux aussi réviser des objets directement dans la révision qu'il te faut avec la commande :

Code:

revise businessobject Document TEST_REVISEA A to F

Par contre, tu dois avoir créer le premier objet de la chaîne.

A savoir sur toutes ces informations sur les révisions que :
[list][*]Tu ne peux créer que des révisions qui respectent la chaîne de révision (la séquence, exemple [A-Z]) définit sur la policy,
[*]Lors de l'utilisation de la commande, le sens de la révision va de A vers F car on révise sur la révision A. (dans l'exemple, j'aurais pu mettre la F avant en inversant les objets)

hum je viens de me rendre compte que l'heritage des triggers pour un type n'a l'air de se faire uniquement si on ne redéfinis pas de trigger pour les types enfants, pour les memes évenements.
Par exemple:
- je définis un trigger de check T1 pour le type DOCUMENTS qui doit s'executer lorque l'évenement create survient
- je définis le type MyDocument, qui hérite de DOCUMENTS et qui définis également un trigger de check T2 pour l'évenement create
- je crée un objet de type MyDocument
=> Seul le trigger T1 est executé (ce qui me pose pas mal de soucis)

Est il possible de définir un trigger pour un type et etre sur que tous ses sous types hériteront et executeront ce trigger lorque l'évenement spécifié surviendera ?

Je pense que tu as fait une coquille :

=> Seul le trigger T1 est executé (ce qui me pose pas mal de soucis)

Tu voulais dire T2, non?

Dans ENOVIA, les triggers sont directement hérité dans la mesure où tu n'ajoutes pas un trigger sur le même événement dans le type fils.
Dans ton cas, comme tu as créé un trigger T2 sur l'événement create, le trigger T1 n'est plus utilisé.

Tu n'as qu'une seule solution ajouter le programme de T1, dans la définition de T2.

• Soit en utilisant le trigger manager avec un seul objet "eService Trigger Program Parameters" du même nom mais une révision différente pour T1 et T2 (exemple : le trigger standard "PolicyInboxTaskStateAssignedPromoteAction")
  
• Soit en passant au trigger manager le noms des deux objets "eService Trigger Program Parameters" correspondant à T1 et T2 (il faut des noms sans espaces, car le séparateur est le caractère espace (exemple sur la policy "ECO (Standard)" et l'état "Design Work" où tu as "PolicyECOStandardStateDesignWorkPromoteAction PolicyECOStandardPromoteDemoteAction")
  .

Tu voulais dire T2, non?

Oui en effet.

Merci rudbg, je ne vais donc pas pouvoir utiliser de trigger pour mon probleme. C'est dommage que l'héritage (ici des triggers, mais meme en général) soit aussi approximatif sur Matrix :/