Une application WINDEV exécutée sous Windows peut se connecter avec un connecteur natif, un provider OLE DB ou un pilote ODBC à une base de données Oracle, MySQL, MariaDB SQL SERVER, PostgreSQL (…).

A l'identique, une application WINDEV Mobile exécutée sous iOS ou Android peut se connecter à la même base de données. Et cela, même si l'éditeur de la base ne fournit pas de client natif pour iOS ou Android.

Voici le principe détaillé en commençant par les pré-requis :

• un serveur web sur lequel on installe :
  • le serveur réservé de WINDEV avec le webservice d'accès aux bases de données,
  • un connecteur natif ou provider OLE DB d'accès à la base,
  • le client de la base de données,
  • si le serveur réservé est sur un serveur différent de celui qui héberge la base données, ouvrir tous les ports nécessaires à la communication entre le client et la base.
• l'application Android qui va :
  • utiliser SQLConnecteWS pour donner les paramètres de connexion à la base et l'adresse du serveur qui héberge le webservice,
  • SQLExec pour exécuter des requêtes sur les bases de données (comme l'aurait fait une application WINDEV sous Windows).

Comment ça marche :
Bien. ;-)

Comment ça marche, en détail :

• l'application appelle la fonction SQLConnecteWS avec :
  • l'adresse du webservice sur le serveur : cette adresse permet de récupérer la description du webservice (WSDL) et toutes les données nécessaires à son utilisation.
    L'application garde en mémoire cette description pour son utilisation ultérieure.
  • les paramètres de connexion à la base : il s'agit de tous les paramètres :
    • qui seront utilisés sur le serveur réservé, pour effectuer la connexion effective à la base lorsqu'elle sera nécessaire,
    • des mêmes paramètres qui auraient été utilisés par la fonction SQLConnecte d'une application WINDEV pour se connecter à la même base depuis le serveur réservé.
      L'application garde en mémoire ses paramètres de connexion.
• l'application appelle la fonction SQLExec pour toutes les interrogations, ou mises à jour de la base. La fonction SQLExec va :
  
  • appeler le webservice avec l'adresse (adresse location) contenu dans sa description WSDL,
  • si c'est son premier appel déclencher la connexion à la base avec les paramètres mémorisés lors de l'appel de SQLConnecteWS
  • passer le code SQL de la requête afin que le serveur fasse son exécution.
• lorsque le webservice reçoit une demande de l'application mobile iOS ou Android :
  • si c'est le premier appel il fait le SQLConnecte avec les paramètres reçus pour la connexion, et il fait SQLExec avec le code SQL de la requête,
  • pour tous les appels suivants, il fait le SQLExec avec le code SQL passé par l'application mobile.

Le webservice sert donc juste d'intermédiaire pour contourner l'absence d'un client pour la base de données.

Le principe de ce mécanisme est simple, mais il y a donc quelques intermédiaires qui peuvent jouer les grains de sables. Les pièges les plus courants qui bloquent les interrogations sont :

• échec d'appel du webservice sur SQLConnecteWS : vérifier la configuration du serveur web, il n'a pas RAWP (le serveur réservé) activé dans le site virtuel du serveur web qui reçoit la demande,
• échec d'appel du webservice sur le premier SQLExec :
  • l'adresse de consommation du webservice n'est pas valide : le "adresse location" contenu dans sa description WSDL est faux. C'est le cas si a l'installation du serveur réservé, on lui a donné un nom ou une adresse IP du réseau local, inacessible lorsqu'il est appelé à partir d'un domaine. Dans ce cas le plus simple est de :
    • réinstaller le serveur réservé,
    • à l'étape "Adresse du webservice",
    • indiquer l'adresse externe ou mieux le domaine permettant d'accéder au serveur serveur web qui héberge le webservice.
  • serveur réservé, client de la base de données, connecteur natif ou provider OLE DB ne sont pas dans un même et unique mode de compilation : ils doivent tous être en 32 bits, ou tous être en 64 bits.
  • ou les paramètres de connexions ne sont pas adaptés : le test sur le serveur sur lequel le serveur réservé est installé d'un SQLConnecte avec un exécutable WINDEV peut faciliter les recherches pour contrôler les paramètres.
  • les droits d'accès ou l'installation du client de la base, ou son provider OLE DB, ne sont pas adaptés. Les traitements du webservice sont lancés par le serveur réservé qui est exécuté par défaut avec le "compte système local" :
    
    
    Il faut donc que le client de la base de données et/ou son provider OLE DB, soient installés pour ce compte. Sans cela un exécutable WINDEV pourra faire la connexion avec SQLConnecte, mais le webservice échouera avec une réponse du type " Data source name not found and no default driver specified". Dans ce cas les solutions sont donc soit :
    • de changer l'utilisateur pris pour exécuter le service "Serveur d'application (réservé) PC SOFT", afin de spécifier un utilisateur pour lequel le client de la base ou provider est installé,
    • de réinstaller le provider OLE DB de telle sorte qu'il soit utilisable avec les autorisations du "compte système local".

Bon à savoir :

• On peut récupérer la description du webservice (WSDL) comme le fait la fonction SQLConnecteWS.
  Par exemple si on donne à SQLConnecteWS l'adresse https://monserveur, la récupération du WSDL se fera avec :
  https://monserveur/WDSOAPDB_WEB/awws/WDSOAPDB.rawws?wsdl
  Cela permet par exemple de vérifier l'adresse d'appel ("adresse location" tout à la fin) du webservice par la fonction SQLExec.
  
  
• On peut aussi tester la version du serveur réservé qui héberge le webservice :
  https://monserveur/RAWP/RAWP/EXE/VERSION
  
  
• lorsque le webservice n'a pas été installé avec la bonne adresse pour être consommé (cf. "adresse location" précédemment), ou si cette adresse change, on peut remplacer l'adresse directement sur le serveur sans passer par la réinstallation complète. Dans ce cas l'adresse doit être changée :
  • dans le fichier WSDL du serveur (via un éditeur texte) :
    C:\Program Files\PC SOFT\Serveur Reserve <version>\WDSoapDB\wdsoapdb.wsdl
  • dans la valeur URL de la clé de registre (via le programme REGEDIT) :
    HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\PC SOFT\RSERVER\<version>\Webservices\wdsoapdb