Contourner les délais d'attente du service SOAP

Certaines de nos applications fournissent des services SOAP qui utilisent des requêtes SQL basées sur « DSTIME » qui renvoient les enregistrements récemment ajoutés ou modifiés. Comme les enregistrements ne changent pas souvent, ces requêtes renvoient généralement un petit nombre d’enregistrements et prennent donc peu de temps.

Cependant, nous apportons parfois une modification à la table qui affecte tous les enregistrements de cette table. Lorsque cela se produit, lors de la prochaine requête SOAP provenant d'un client SOAP, le service exécutera sa requête, ce qui prendra très longtemps car tous les enregistrements sont inclus (pour nos applications, les requêtes renvoient des centaines de milliers d'enregistrements dans ce cas).

Le temps de production des résultats dépasse donc parfois le « timeout » par défaut spécifié dans la connexion à la passerelle CSP pour l'instance hébergeant le service SOAP. Cela entraîne la fermeture de la connexion avant que le client n'obtienne les données demandées et le client reçoit à la place un message d'erreur semblable au suivant :

ERROR #5002: ObjectScript error: InvokeClient+208^%SOAP.WebClient.1

Nous pouvons confirmer que l'erreur est due à un délai d'attente en affichant les détails de l'erreur SOAP sur le client à l'aide de la fonctionnalité « Journal SOAP InterSystems IRIS » décrite ici.

La sortie suivante du fichier journal confirme l'erreur de délai d'attente :

Input to Web client with SOAP action = http://www.intersystems.com/user/SOAPTest.SlowSOAPService.GetSlowService

ERROR #5922: Timed out waiting for response
string**** SOAP client return error. method=GetSlowService, action=http://www.intersystems.com/user/SOAPTest.SlowSOAPService.GetSlowService
     ERROR #5922: Timed out waiting for response

Pour résoudre cette erreur, nous avons ajouté du code pour définir un délai d'expiration de connexion à l'instance du client SOAP avant d'appeler la méthode SOAP qui utilise cette requête. Nous avions exécuté la requête sur la page SQL du portail de gestion, en écrivant le résultat dans un fichier csv, et avons noté qu'elle prenait plus de 6 minutes. Nous avons donc ajouté ce code pour augmenter le délai d'attente à 10 minutes avant d'appeler le service (les noms ont été modifiés pour protéger les innocents).
😊):

    #dim result As %XML.DataSet
    set wc = ##class(SlowSOAPService.WebClient.SlowSOAPServiceSoap).%New()
    set sc = wc.TimeoutSet(600)
    set sc = wc.GetSlowService(.result)

La classe %SOAP.WebService fournit la méthode « TimeoutSet » qui modifie uniquement la valeur du délai d'expiration de connexion pour cette requête. Cela n’affecte pas la valeur du délai d’expiration de la connexion à la passerelle CSP, qui est par défaut de 30 secondes (pour encourager l’écriture de code côté serveur efficace).

En fait, pour préserver cette incitation, nous pouvons garantir que le délai d'attente prolongé n'est utilisé que dans les rares cas où nous en avons besoin en encapsulant le code client dans un code conditionnel qui vérifie une globale, comme suit :

    #dim result As %XML.DataSet
    set wc = ##class(SlowSOAPService.WebClient.SlowSOAPServiceSoap).%New()
    if (^reallySlowSvcExpectedTime > 0) {
        set sc = wc.TimeoutSet(^reallySlowSvcExpectedTime)
    }
    set sc = wc.GetSlowService(.result)

La globale agit à la fois comme un indicateur (supérieur à 0 ? Définir le délai d'attente) et comme le nombre de secondes à attendre. Pour le problème décrit au début de cet article, nous informons les clients qu'ils doivent temporairement définir un global à l'aide d'un terminal IRIS connecté à leur instance comme suit :

    set ^reallySlowSvcExpectedTime = 600

Une fois que nous nous attendons à nouveau à ce que le service renvoie rapidement une petite quantité de données, les clients peuvent être réinitialisés pour utiliser le délai d'expiration par défaut en redéfinissant la globale sur 0 :

    set ^reallySlowSvcExpectedTime = 0