Utilitaires › Opérateur Appel Java › Paramètres d'entrée › Code

Code

Répertorier les chemins d'accès JAR externes ?

Sélectionnez la case à cocher pour spécifier la liste des chemins d'accès aux fichiers JAR externes requis dans le champ Chemins de fichiers JAR externes en tant qu'expression.

Décochez la case pour spécifier les chemins d'accès aux fichiers JAR externes requis en tant qu'expression, c'est-à-dire en tant que variable d'ensemble de données dans le champ Fichiers JAR externes en tant qu'expression.

Cette case à cocher est sélectionnée par défaut.

Fichiers JAR externes

Spécifie la liste des chemins d'accès aux fichiers JAR externes requis par le code de méthode principale de l'opérateur, le cas échéant.

L'opérateur Appel Java charge les fichiers JAR répertoriés dans ce champ. Tous les fichiers JAR de cette liste sont disponibles dans le code Java exécuté par l'opérateur. Les classes définies dans les fichiers JAR au niveau de l'opérateur remplacent les mêmes classes spécifiées dans les fichiers JAR au niveau de la catégorie de l'opérateur.

Pour chaque paramètre, vous pouvez :

• Entrez le chemin complet d'un fichier JAR qui réside sur l'hôte sur lequel l'agent CA Process Automation (mappé au point de contact) est exécuté. Le chemin complet est spécifié comme suit :
  • Commence par /
  • Par \\
  • Ou par ^.:.* (une expression régulière qui commence par un caractère suivi par deux-points, puis le reste de la chaîne)
• Entrer le chemin d'accès à un fichier JAR téléchargeable via HTTP. Vérifiez que le chemin d'accès HTTP ne requiert aucune authentification et qu'il ne passe pas par un proxy HTTP. Le chemin d'accès au fichier JAR doit commencer par http:// ou https://.
• Toute autre chemin d'accès est considéré comme un chemin d'accès relatif à un fichier JAR qui a été chargé dans les ressources d'utilisateur CA Process Automation. CA Process Automation ajoute le chemin d'accès au fichier JAR au chemin d'accès du répertoire Ressources d'utilisateur CA Process Automation de l'agent mappé au point de contact, qui exécute l'opérateur.

  Ne commencez pas le chemin d'accès relatif au fichier JAR par :

  • /
  • \\

  Dans le cas contraire, CA Process Automation suppose que le chemin d'accès au fichier JAR est un chemin complet.

Les ressources de CA Process Automation, y compris les ressources d'utilisateur, sont reflétées dans l'intervalle de mise en miroir de l'agent. Vérifiez que les fichiers JAR chargés dans les ressources d'utilisateur sont déjà mis en miroir avant de les utiliser dans l'opérateur Appel Java.

Fichiers de classe

En plus des fichiers JAR externes, vous pouvez charger les fichiers .class de la manière suivante :

• Pour les fichiers .class dans un package sans nom, entrez un chemin d'accès qui finit par le répertoire contenant ces fichiers.

  Par exemple, si MyAccount.java n'appartient pas à un package et que MyAccount.class se trouve dans :

  C:\java\tests\MyAccount.class

  définissez l'opérateur de telle manière qu'il utilise le chemin d'accès suivant :

  C:\\java\\tests

• Pour les fichiers .class dans un package nommé, entrez un chemin d'accès qui finit par le répertoire contenant le package racine. Le package racine est le premier package dans le nom de package complet.

  Par exemple, si MyAccount.java appartient à un package com.ca.tech et que MyAccount.class se trouve dans : C:\java\othertests\com\ca\tech\MyAccount.class,

  définissez l'opérateur de telle manière qu'il utilise le chemin d'accès suivant :

  C:\\java\\othertests

Si vous spécifiez le chemin d'accès à un répertoire pour charger des fichiers .class, entrez-le comme chemin complet. Vous pouvez également l'entrer comme chemin d'accès relatif à des ressources d'utilisateur CA Process Automation. Ne l'entrez pas comme chemin d'accès HTTP.

Spécifiez le chemin d'accès à un répertoire pour charger les fichiers .class, et non les fichiers JAR. Contrairement aux fichiers .class, chaque fichier JAR requiert un chemin d'accès distinct qui finit par le fichier JAR, et non par le répertoire où il réside.

Fichiers JAR externes en tant qu'expression

Spécifie la variable d'ensemble de données de chaîne indexée qui contient la liste de chemins d'accès aux fichiers JAR externes requis par le code de méthode principale de l'opérateur, le cas échéant.

Entrer la méthode principale requise ?

Cochez la case pour entrer le code Java dans le champ Méthode principale requise.

Décochez la case pour entrer le code Java en tant que variable d'ensemble de données dans le champ Méthode principale requise en tant qu'expression.

Cette case à cocher est sélectionnée par défaut.

Méthode principale requise

Spécifie le code Java de la méthode principale. Vous pouvez cliquer sur Parcourir pour localiser un fichier contenant le code. La méthode principale consiste en plusieurs instructions et expressions Java normales. Vous devez initialiser et utiliser des objets définis dans le kit de développement logiciel Java ou dans les fichiers JAR externes.

Remarque : CA Process Automation analyse le code et vérifie sa structure lorsque vous cliquez sur OK. Un message d'erreur s'affiche si une erreur est trouvée dans la structure du code.

Consultez la section Code Java dans l'opérateur Appel Java.

Méthode principale requise en tant qu'expression

Spécifie la variable d'ensemble de données qui contient le contenu de la méthode principale. La méthode principale consiste en plusieurs instructions et expressions Java normales. Vous devez initialiser et utiliser des objets définis dans le kit de développement logiciel Java ou dans les fichiers JAR externes. Aucune validation structurale n'est effectuée.

Consultez la section Code Java dans l'opérateur Appel Java.

Définir le chargeur de classes de contexte ?

Définissez ce champ sur une valeur différente de celle par défaut si la méthode principale ou les fichiers JAR externes dépendent du chargeur de classes de contexte Java pour charger les classes. Définissez le chargeur de classes de contexte Java sur le chargeur de classes de l'opérateur ou le chargeur de classes de module pour éviter une exception ClassCastException.

L'opérateur Appel Java utilise une chaîne de chargeurs de classes pour charger des classes pendant l'exécution du code Java. Cette chaîne a été conçue comme suit (parmi d'autres chargeurs de classes) :

1. Chargeur de classes d'opérateur : chargeur de classes qui charge les classes fournies au niveau de l'opérateur
2. Chargeur de classes de module : chargeur de classes qui charge les classes fournies au niveau du module
3. Chargeur de classes de contexte
4. Expression Java standard Class.ForName

L'opérateur consulte chaque chargeur de classes avant de passer au suivant (si la classe n'a pas été trouvée).

Cette chaîne fonctionne pour autant que le code que vous exécutez n'utilise pas explicitement son propre chargeur de classes pour charger une classe. Dans ce cas, les journaux affichent une exception ClassCastException.

Exemple :

la classe MyChildXMLParser étend la classe MyParentXMLParser. Le fragment de code suivant répertorié crée MyParentXMLParser à l'aide d'un sous-objet Java. Ce sous-objet charge et crée en réalité MyChildXMLParser, qui est alors intégré à un objet MyParentXMLParser :

public MyParentXMLParser() {
        super((MyParentXMLParser)ObjectFactory.createObject("com.ca.parser.MyChildXMLParser"));
          ....
     }

Dans cet exemple :

• La méthode ObjectFactory.createObject() invoque en fait son propre chargeur de classes pour charger la classe MyChildXMLParser. Ce comportement est typique des sous-objets Java, dans la mesure où ils utilisent soit le chargeur de classe système, soit (s'il existe) un chargeur de classes de contexte pour charger la classe (au lieu d'utiliser le chargeur de classes utilisé par le programme exécutant).
• La classe MyParentXMLParser est chargée par le chargeur de classes de l'opérateur Appel Java (comme sélectionné à l'aide de la chaîne précédente.)
• La syntaxe  ((MyParentXMLParser)ObjectFactory.createObject) renvoie une exception ClassCastException. Bien que MyChildXMLParser s'étende sur MyParentXMLParser, les deux classes ont été chargées par différents chargeurs de classes. En conséquence, ils sont complètement différents.

Pour résoudre ce problème, définissez le chargeur de classes de contexte sur l'un des deux chargeurs suivants :

• 1 : Chargeur de classes d'opérateur : si le fichier JAR qui contient des classes MyChildXMLParser et MyParentXMLParser est fourni dans les propriétés de l'opérateur.
• 2 : Chargeur de classes de module : si le fichier JAR qui contient des classes MyChildXMLParser et MyParentXMLParser est fourni dans les propriétés du module.

Remarque : L'option 0 : valeur par défaut est utilisée dans tous les autres cas où votre code Java ne charge pas explicitement de classes à l'aide de son propre chargeur de classes. Cette option est la valeur par défaut de ce champ.

En définissant le chargeur de classes de contexte sur le chargeur de classes de l'opérateur Appel Java, les sous-objets Java qui sont invoqués par le code de l'utilisateur sont obligés d'utiliser le chargeur de classes de l'opérateur Appel Java. Cette action supprime l'exception ClassCastException.