4D v16.3SOAP DECLARATION |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4D v16.3
SOAP DECLARATION
SOAP DECLARATION
La commande SOAP DECLARATION permet de déclarer explicitement le type des paramètres utilisés dans une méthode 4D publiée comme Web Service. Lorsqu’une méthode est publiée en tant que Web Service, les paramètres standard $0, $1... $n sont utilisés pour décrire les paramètres du Web Service auprès du monde extérieur (notamment dans le fichier WSDL). Le protocole SOAP exigeant que les paramètres soient explicitement nommés, 4D utilise par défaut les noms “FourD_arg0, FourD_arg1 ... FourD_argn”. Ce fonctionnement par défaut peut toutefois s’avérer problématique pour les raisons suivantes :
La commande SOAP DECLARATION permet de s’affranchir de ces limites. Vous pouvez exécuter cette commande pour chaque paramètre entrant et sortant et lui assigner un nom et un type. Note : Même si la commande SOAP DECLARATION est utilisée, il est nécessaire de déclarer les variables et tableaux 4D dans la méthode Compiler_Web à l’aide les commandes du thème “Compilateur”. Passez dans variable la variable 4D à référencer dans l’appel du Web Service. Attention, vous pouvez référencer uniquement des variables process ou les arguments des méthodes 4D ($0 à $n). Les variables locales et interprocess ne peuvent pas être utilisées. Par défaut, seuls des arguments de type Texte pouvant être utilisés, les réponses du serveur SOAP sont en principe limitées à 32 Ko dans les bases de données en mode non Unicode. Il est toutefois possible de retourner des arguments SOAP d’une taille supérieure à 32 Ko, en utilisant des BLOBs. Pour cela, il suffit de déclarer les arguments en type BLOB avant d’appeler la commande SOAP DECLARATION (cf. exemple 4). Note : Côté client, si vous souscrivez à ce type de Web Service avec 4D, l’assistant Web Services générera naturellement une variable de type Texte dans la méthode proxy. Pour pouvoir l’utiliser, il vous suffit de retyper cette variable de retour en BLOB dans la méthode proxy. Passez dans type le type 4D correspondant. La plupart des types de variables et de tableaux 4D peuvent être employés. Vous pouvez utiliser les constantes ci-dessous, placées dans le thème Types champs et variables, ainsi que, pour les types XML, deux constantes du thème Web Services (Serveur) :
Passez dans entrée_sortie une valeur indiquant si le paramètre traité est “entrant” (c’est-à-dire correspondant à une valeur reçue par la méthode) ou “sortant” (c’est-à-dire correspondant à une valeur retournée par la méthode). Vous pouvez utiliser les constantes prédéfinies suivantes, placées dans le thème “Web Services (Serveur)” :
Vous pouvez déclarer des variables de type "structure XML" et "référence DOM", aussi bien en entrée qu’en sortie, via les constantes Est un XML et Est une référence DOM. Lorsque des paramètres de ce type sont définis, aucun traitement ni encodage ne leur est appliqué, les données sont transmises telles quelles (cf. exemple 5).
Note : Dans le cas de références DOM utilisées en paramètres sortants, il est recommandé d’utiliser des références globales, créées par exemple au démarrage et closes à la fermeture de l’application. En effet, une référence DOM créée au sein du Web Service lui-même ne peut pas être refermée avec DOM FERMER XML sinon le Web Service ne retourne plus rien. Les appels multiples au Web Service impliquent alors la création d’autant de références DOM non refermées, ce qui peut provoquer une saturation de la mémoire.
Les arguments SOAP entrants référencés à l’aide de variables 4D (et non via les arguments des méthodes 4D) doivent être préalablement déclarés dans la méthode projet COMPILER_WEB. En effet, l’utilisation de variables process dans les méthodes Web Services nécessite leur déclaration avant l’appel de la méthode. La méthode projet COMPILER_WEB est appelée, si elle existe, à chaque requête SOAP acceptée. Par défaut, la méthode COMPILER_WEB n’existe pas. Vous devez la créer explicitement. Passez dans alias le nom de l’argument tel qu’il doit apparaître dans la WSDL et dans les échanges SOAP. Attention, ce nom doit être unique dans l’appel RPC (paramètres entrants et sortants confondus), sinon seule la dernière déclaration sera prise en compte par 4D. Note : Les noms des arguments ne doivent pas débuter par un chiffre ni contenir d’espaces. En outre, pour éviter tout risque d’incompatibilité, il est recommandé de ne pas utiliser de caractères étendus (tels que des caractères accentués). Si le paramètre alias est omis, 4D utilisera par défaut le nom de la variable ou FourD_argN pour les arguments des méthodes 4D ($0 à $n). Note : La commande SOAP DECLARATION doit être incluse dans la méthode publiée comme Web Service. Il n’est pas possible de l’appeler d’une autre méthode. Cet exemple spécifie un nom de paramètre : //Dans la méthode COMPILER_WEB Cet exemple permet de récupérer un tableau de codes postaux sous forme d’entiers longs : //Dans la méthode COMPILER_WEB Cet exemple permet de référencer deux valeurs de retour sans spécifier de nom d’argument : SOAP DECLARATION(ret1;Est un entier long;SOAP sortie) Cet exemple permet au serveur SOAP de 4D de retourner un argument d'une taille supérieure à 32 Ko dans les bases de données en mode non Unicode : C_BLOB($0) Notez le type Est un texte (et non Est un BLOB). Cette astuce permet un formatage correct de l’argument. Cet exemple illustre l'effet des différents types de déclarations : TOUT SELECTIONNER([Contact])
Voir aussi
Fichier donnees verrouille
|
PROPRIÉTÉS
Produit : 4D
HISTORIQUE
Modifié : 4D v11 SQL Release 2 UTILISATION DE L'ARTICLE
4D - Langage ( 4D v16) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||