Altova MapForce 2025 Enterprise Edition

Importer des bibliothèques Java et .NET personnalisées

Accueil Préc Haut Suivant

Cette section explique comment importer les fichiers de classe Java compilés et les assemblies .NET DLL (y compris les assemblies .NET 4.0) dans MapForce. Si les bibliothèques importées contiennent des fonctions qui utilisent des types de données de base en tant que paramètres et retournent des types simples, ces fonctions apparaissent dans la fenêtre Bibliothèques, et peuvent être utilisées dans des mappages comme dans tout autre fonction disponible dans MapForce. La sortie de mappage des fonctions importées Java et .NET peuvent être consultées dans le volet Sortie et les fonctions sont disponibles dans le code généré. Pour en savoir plus sur comment importer les bibliothèques personnalisées, voir les exemples fournis dans Importer Classe Java personnalisée et Importer un .NET DLL Assembly personnalisé.

 

Important :

 

Afin d'importer des fonctions Java ou .NET, vous avez besoin de classes Java compilées (.class) ou des fichiers .NET.dll assembly. L'importation de fichiers .jar files ou .dll qui ne sont pas un .NET assembly n'est pas pris en charge.

 

Les fichiers .NET assembly sont pris en charge lorsque le langage de mappage est défini sur C#. Les .NET assemblies peuvent être écris dans des langages .NET différents de C# (par exemple, C++.NET ou VB.NET), s'ils utilisent uniquement des types de données de base depuis le System Assembly en tant que paramètres et types de retour. Pour les détails, voir Prise en charge de la fonction .NET.

 

Si vous voulez utiliser des fonctions .NET personnalisées dans l’aperçu de sortie built-in (dans le volet Sortie), ces fonctions doivent être compilées pour .NET Framework 4.x ou .NET Standard 2.0.

 

Des fichiers de classes Java compilées .class) sont prises en charge lorsque le langage de mappage est défini sur Java. Java Runtime Environment 7 ou plus récent doit être installé sur votre ordinateur. Seuls des types et membres spécifiques sont pris en charge (voir Prise en charge de la fonction Java).

 

Vous ne pouvez pas définir le langage de mappage sur C++ si le mappage utilise .class ou des assemblies .NET DLL importés.

 

Vous ne pouvez pas définir le langage de mappage sur XSLT si le mappage utilise des .class Java importées ou des assemblies .NET DLL importés (une fonction XSLT personnalisée qui agit en tant qu'un adaptateur devra être rédigée).

 

L'importation de fonctions provenant de DLL C++ natifs est limitée et nécessite une approche particulière. Pour plus d'informations, voir Référencer les bibliothèques Java, C# et C++ manuellement.

 

Toutes les fonctions appelées depuis un mappage MapForce doivent retourner la même valeur à chaque fois que la fonction est appelée avec les même paramètres d'entrée. L'ordre exact et le nombre de fois qu'une fonction est appelée par MapForce ne sont pas définis.

 

Dans le cas de Java, les fichiers de classe importés et leurs packages n’ont pas besoin d’être ajoutés à la variable CLASSPATH puisque le moteur d’exécution Built-In et le code Java généré ajouteront automatiquement des packages importés respectivement au classpath du moteur Java ou à Ant. Néanmoins, toute dépendance des fichiers de classe importés et des packages ne seront pas gérés automatiquement. C'est pourquoi, si des fichiers de classe Java importés ou des packages dépendent d'autres fichiers de classe, assurez-vous d'ajouter les répertoires de parent de tous les packages dépendants de la variable d'environnement CLASSPATH.

 

Prise en charge de la fonction Java

Les classes de niveau supérieur, les classes membre statiques et les classes de membre non-statiques sont prises en charge :

 

new <classname>(<arg1>, <arg2>, ...)

<object>.new <member-class>(<arg1>, <arg2>, ...)

 

Les fonctions membre et les fonctions statiques sont prises en charge :

 

<function>(<arg1>, <arg2>, ...)

<object>.<method>(<arg1>, ...)

 

Les connexions prises en charge entre Schéma XML et les types Java :

 

Type Schéma

Type Java

xs:string

String

xs:byte

byte

xs:short

short

xs:int

int

xs:long

long

xs:boolean

booléenne

xs:float

float

xs:double

double

xs:decimal

java.math.BigDecimal

xs:integer

java.math.BigInteger

 

Des connexions dans les deux sens sont possibles. D’autres types Java (y compris les types array) ne sont pas pris en charge. Les méthodes pour utiliser de tels paramètres ou des valeurs de retour seront ignorées. Les types d'objet sont pris en charge en appelant leur constructeur, ou en tant que valeur de retour d'une méthode. Ils peuvent être mappés à d'autres méthodes Java. Il n'est pas possible de manipuler l'objet en utilisant MapForce.

 

Prise en charge de la fonction .NET

Les classes de niveau supérieur et les classes membre sont prises en charge :

 

new <classname>(<arg1>, <arg2>, ...)

 

Les fonctions membre et les fonctions statiques sont prises en charge :

 

<function>(<arg1>, <arg2>, ...)

<object>.<method>(<arg1>, ...)

 

Les connexions prises en charge entre Schéma XML et les types .NET/C# :

 

Type Schéma

Type .NET

Type C#

xs:string

System.String

string

xs:byte

System.SByte

sbyte

xs:short

System.Int16

short

xs:int

System.Int32

int

xs:long

System.Int64

long

xs:unsignedByte

System.Byte

byte

xs:unsignedShort

System.UInt16

ushort

xs:unsignedInt

System.UInt32

uint

xs:unsignedLong

System.UInt64

ulong

xs:boolean

System.Boolean

bool

xs:float

System.Single

float

xs:double

System.Double

double

xs:decimal

System.Decimal

decimal

 

Des connexions dans les deux sens sont possibles. Les autres types .NET/C# (y compris les types array) ne sont pas pris en charge. Les méthodes pour utiliser de tels paramètres ou des valeurs de retour seront ignorées. Les types d'objet sont pris en charge en appelant leur constructeur, ou en tant que valeur de retour d'une méthode. Ils peuvent être mappés à d'autres méthodes .NET. Il n'est pas possible de manipuler l'objet en utilisant MapForce.

 

Problèmes et contournements de types de données

Lorsqu’une fonction dans votre bibliothèque personnalisée attend des types d’entier, connectant des constantes de type Number aux arguments de la fonction, ceci peut causer une erreur d’incompatibilité semblable à celle-ci : No match for MyCustomClassLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.MyCustomClassLibrary.Converter.AddValues(MyCustomClassLibrary.Converter, xs:decimal, xs:decimal). Vérifier types d’argument. Ce problème est spécifique aux constantes de type Number uniquement. Un exemple de mappage qui pourrait générer cette erreur est affiché ci-dessous. Dans ce mappage, deux constantes de type Number sont connectées aux arguments de type de la fonction Integer.

mf_customlib_workaround

Les contournements possibles sont décrits ci-dessous :

 

1.Changer le type de constante de Number à All other. Pour ce faire, double-cliquez sur la barre de titre du composant de la constante.

2.Au lieu d'une constante, utilisez un composant de source (par exemple, un fichier XML) qui fournit des valeurs du type de données attendues par la fonction.

mf_customlib_workaround_03

3.Dans votre code externe, créez une fonction wrapper qui accepte une valeur décimale et retourne une valeur d'entier. La solution wrapper peut être importée en tant que bibliothèque séparée. C’est pourquoi vous ne devez pas changer le code source d’origine de la fonction cible pour utiliser cette approche.

 

© 2018-2024 Altova GmbH