4D v14.3

Executer sur serveur

Accueil

 
4D v14.3
Executer sur serveur

Executer sur serveur 


 

Executer sur serveur ( procédure ; pile {; nom {; param {; param2 ; ... ; paramN}}}{; *} ) -> Résultat 
Paramètre Type   Description
procédure  Chaîne in Procédure à exécuter dans le process
pile  Entier long in Taille de la pile en octets
nom  Chaîne in Nom du process créé
param  Expression in Paramètre(s) de la procédure
Opérateur in Process unique
Résultat  Entier long in Numéro du process pour un process nouvellement créé ou un process déjà en cours d'exécution

La commande Executer sur serveur lance un nouveau process sur la machine serveur (lorsqu'elle est appelée en environnement client/serveur) et retourne le numéro de ce process.

Executer sur serveur vous permet de démarrer une procédure stockée. Pour plus d'informations sur les procédures stockées, reportez-vous à la section Procédures stockées dans le manuel de référence de 4D Server.

Si vous appelez Executer sur serveur sur un poste client, la commande retourne un numéro de process négatif. Si vous appelez Executer sur serveur sur le poste serveur, la commande retourne un numéro de process positif. A noter que l'appel de la fonction Nouveau process sur le poste serveur est équivalent à l'appel de Executer sur serveur.

Si le process n'a pas pu être créé (par exemple s'il n'y a pas assez de mémoire), Executer sur serveur retourne zéro et une erreur est générée. Vous pouvez intercepter cette erreur à l'aide d'une méthode de gestion d'erreurs installée par la commande APPELER SUR ERREUR.

Vous passez le nom de la méthode de gestion du nouveau process dans procédure. Une fois que 4D a défini le contexte pour le nouveau process, il démarre l'exécution de cette méthode qui devient alors la méthode du process.

Vous passez dans pile la quantité de mémoire allouée pour la pile du process. Cette valeur représente la place utilisée en mémoire pour “empiler” les appels de méthodes, les variables locales, les paramètres des sous-routines et les enregistrements empilés. Elle est exprimée en octets, il est conseillé de passer au moins 64K (environ 64000 octets) mais vous pouvez passer davantage si la chaîne d'appel dans le process (sous-routines appelant des sous-routines en cascade) est importante. Si nécessaire, vous pouvez passer par exemple 200K (environ 200000 octets).

Note : La pile n'est pas la mémoire totale réservée au process. Les process se partagent la mémoire pour les enregistrements, les variables interprocess, etc. Un process utilise également de la mémoire supplémentaire pour stocker ses variables process. La pile ne contient que les variables locales, les appels de méthodes, les paramètres des sous-routines et les enregistrements empilés.

Note 4D Server 64 bits : La pile d'un process exécuté sur 4D Server 64 bits requiert une quantité de mémoire plus importante que sur 4D Server 32 bits (environ le double). Pour reprendre les ordres de grandeur fournis ci-dessus, il est conseillé dans ce contexte de passer une valeur de 128000 octets au minimum et de 400000 octets en cas de chaîne d'appel importante. Veillez à contrôler ce paramètre lorsque votre code est destiné à être exécuté sur 4D Server 64 bits.

Vous passez le nom du nouveau process dans nom. Avec 4D monoposte, ce nom s'affichera dans la liste des process de l'Explorateur d'exécution et sera retourné par la commande INFORMATIONS PROCESS appliquée à ce process. En client/serveur, ce nom apparaîtra en bleu dans la liste des Procédures stockées de la fenêtre principale de 4D Server.

Vous pouvez omettre ce paramètre ; dans ce cas, le nom du process sera une chaîne vide.

Attention : A la différence de la commande Nouveau process, vous ne devez pas avec Executer sur serveur créer un process local en préfixant son nom du symbole dollar ($). Cela fonctionnerait correctement en version monoposte, car Executer sur serveur se comporte comme Nouveau process dans cet environnement, mais, en client/serveur, cela génèrerait une erreur.

Vous pouvez passer des paramètres à la méthode process. Vous pouvez le faire de la même manière que pour les sous-routines. Notez cependant qu'il y a une restriction : vous ne pouvez pas passer d'expression de type Pointeur. Rappelez-vous également que les tableaux ne peuvent pas être passés comme paramètres à une méthode. Une fois qu'elle a commencé à s'exécuter dans le contexte du nouveau process, la méthode process reçoit les valeurs des paramètres dans $1, $2, etc.

Note : Si vous passez des paramètres à la méthode process, vous devez passer le paramètre nom, il ne peut être omis dans ce cas.

Si vous passez un objet 4D (C_OBJET) comme param ou valeur de retour, la forme JSON est utilisée en utf-8 pour le serveur. Si l’objet C_OBJET contient des pointeurs, leur valeurs dépointées sont envoyées, pas les pointeurs eux-mêmes.

Si vous passez le dernier paramètre (optionnel) *, vous indiquez à 4D de vérifier en premier lieu si un process du même nom que celui que vous avez passé dans nom est déjà en cours d'exécution. Si c'est le cas, 4D ne démarre pas de nouveau process et retourne le numéro du process existant.

Exemple  

L'exemple suivant démontre comment l'import de données peut être accéléré de manière spectaculaire en environnement client/serveur. La méthode Import classique listée ci-dessous vous permet de mesurer combien de temps prend un import d'enregistrements basé sur la commande IMPORTER TEXTE :

  ` Méthode projet Import classique
 $vhDocRef:=Ouvrir document("")
 Si(OK=1)
    FERMER DOCUMENT($vhDocRef)
    FORM FIXER ENTREE([Table1];"Import")
    $vhStartTime:=Heure courante
    IMPORTER TEXTE([Table1];Document)
    $vhEndTime:=Heure courante
    ALERTE("L'opération a duré "+Chaine(0+($vhEndTime-$vhStartTime))+" secondes.")
 Fin de si

Avec l'import de données classique, 4D Client analyse le fichier ASCII puis, pour chaque enregistrement, crée un nouvel enregistrement, remplit les champs avec les valeurs importées et envoie l'enregistrement au poste serveur afin qu'il soit ajouté à la base. Par conséquent, de nombreuses requêtes circulent sur le réseau. Afin d'optimiser l'opération, vous pouvez utiliser des procédures stockées pour effectuer l'import localement sur le poste serveur. Le poste client charge le document dans un BLOB et déclenche une procédure stockée en passant le BLOB comme paramètre. La procédure stockée place le BLOB dans un document sur le disque du poste serveur, puis importe le document en local. L'import des données est par conséquent effectué localement à une vitesse comparable à celle d'une version monoposte de 4D, car la plupart des requêtes transitant sur le réseau ont été éliminées. Voici la méthode projet CLIENT IMPORT. Lancée sur le poste client, elle déclenche l'exécution de la procédure stockée SERVER IMPORT, listée à la suite :

  ` Méthode projet CLIENT IMPORT
  ` CLIENT IMPORT ( Pointeur ; Alpha )
  ` CLIENT IMPORT ( -> [Table] ; Formulaire entrée )
 
 C_POINTEUR($1)
 C_ALPHA(31;$2)
 C_HEURE($vhDocRef)
 C_BLOB($vxData)
 C_ENTIER LONG(spErrCode)
 
  ` Sélectionnez le document à importer
 $vhDocRef:=Ouvrir document("")
 Si(OK=1)
  ` Si un document était sélectionné, ne pas le garder ouvert
    FERMER DOCUMENT($vhDocRef)
    $vhStartTime:=Heure courante
  ` Essayons de le charger en mémoire
    DOCUMENT VERS BLOB(Document;$vxData)
    Si(OK=1)
  ` Si le document a pu être chargé dans le BLOB,
  ` Démarrer la procédure stockée qui va importer les données sur le poste serveur
       $spProcessID:=Executer sur serveur("SERVER IMPORT";32*1024;"Serveur Import Services";Table($1);$2;$vxData)
  ` Nous n'avons alors plus besoin du BLOB dans ce process
       EFFACER VARIABLE($vxData)
  ` Attendons l'achèvement de l'opération effectuée par la procédure stockée
       Repeter
          ENDORMIR PROCESS(Numero du process courant;300)
          LIRE VARIABLE PROCESS($spProcessID;spErrCode;spErrCode)
          Si(Indefinie(spErrCode))
  ` Note: si la procédure stockée n'a pas initialisé sa propre instance
  ` de la variable spErrCode, il se peut qu'une variable indéfinie soit retournée
             spErrCode:=1
          Fin de si
       Jusque(spErrCode<=0)
  ` Envoyons un accusé de réception à la procédure stockée
       spErrCode:=1
       ECRIRE VARIABLE PROCESS($spProcessID;spErrCode;spErrCode)
       $vhEndTime:=Heure courante
       ALERTE("L'opération a duré "+Chaine(0+($vhEndTime-$vhStartTime))+" secondes.")
    Sinon
       ALERTE("Il n'y a pas assez de mémoire pour charger le document.")
    Fin de si
 Fin de si

Voici la méthode projet SERVER IMPORT exécutée en tant que procédure stockée :

  ` Méthode projet SERVER IMPORT
  ` SERVER IMPORT ( Entier long ; Alpha ; BLOB )
  ` SERVER IMPORT ( Numéro de table ; Formulaire entrée ; Données importées )
 
 C_ENTIER LONG($1)
 C_ALPHA(31;$2)
 C_BLOB($3)
 C_ENTIER LONG(spErrCode)
 
  ` L'opération n'est pas encore terminée, affectons 1 à spErrCode
 spErrCode:=1
 $vpTable:=Table($1)
 FORM FIXER ENTREE($vpTable->;$2)
 $vsDocName:="Fichier Import "+Chaine(1+Hasard)
 SUPPRIMER DOCUMENT($vsDocName)
 BLOB VERS DOCUMENT($vsDocName;$3)
 IMPORTER TEXTE($vpTable->;$vsDocName)
 SUPPRIMER DOCUMENT($vsDocName)
  ` L'opération est terminée, affectons 0 à spErrCode
 spErrCode:=0
  ` Attendons que le poste client à l'origine de la requête ait reçu les résultats
 Repeter
    ENDORMIR PROCESS(Numero du process courant;1)
 Jusque(spErrCode>0)

Une fois que ces deux méthodes projet ont été implémentées dans votre base, vous pouvez effectuer un import basé sur une procédure stockée, en écrivant par exemple :

 CLIENT IMPORT(->[Table1];"Import")

Si vous réalisez quelques tests comparatifs, vous pourrez constater qu'avec ce type de méthode, l'import des enregistrements est jusqu'à 60 fois plus rapide qu'un import "classique".

 
PROPRIÉTÉS 

Produit : 4D
Thème : Process
Numéro : 373
Nom intl. : Execute on server

 
HISTORIQUE 

Modifié : 4D 2004.3

 
VOIR AUSSI  

Nouveau process

 
UTILISATION DE L'ARTICLE

4D - Langage ( 4D v14 R3)
4D - Langage ( 4D v14 R2)
4D - Langage ( 4D v14.3)
4D - Langage ( 4D v14 R4)

Hérité de : Executer sur serveur ( 4D v12.4)