Chargement de batchs via upload

[symac]

Pour les grosses bibliothèques le WS de l'Abes, en particulier sur les demandes d'Unica, a tendance à planter. Il serait intéressant de pouvoir charger un fichier manuellement, que l'on aurait récupéré au préalable via wget ou autre, qui est moins juste au timeout que la solution utilisée via l'interface web d'admin.

[kerphi]

Salut Sylvain, aurais tu un exemple du (ou des) WS unica de l'Abes qui ont tendance à planter ? On pourrait ajouter une issue sur ce sujet dans le dépôt https://github.com/abes-esr/abes-webservices/issues

[symac]

@kerphi bonjour Stéphane, désolé pour le retard, ça m'était sorti de la tête. Je viens de refaire le test avec un exemple qui plantait souvent :

https://www.idref.fr/AlgoLiens?localisationRcr=335222103&unica=localisationRcr&paprika=1&rownum=15

À l'heure actuel l'appel me renvoie bien des résultats, mais il faut pas loin de 5 minutes pour obtenir les 18 résultats concernés. Si ça passe quand je fais un wget en ligne de commande, quand je fais l'appel depuis l'interface web, j'ai beau essayé de lancer la récupération en arrière plan, j'atteins quand même un timeout au niveau de mon serveur (il y aurait sûrement des solutions plus robustes pour lancer ce téléchargement via mon PHP et éviter d'atteindre le timeout). Mais si je dois contourner ce sera par l'upload d'un fichier récupéré sur ma machine je pense.

[jsicot]

Salut,

Je me raccroche à la discussion car j'ai rencontré le souci évoqué par Sylvain en utilisant son appli. J'ai tenté d'utiliser la commande signalée dans le readme : php bin/console app:harvest-records mais je me demande si elle est fonctionnelle ? Je suis parvenu à comprendre qu'il était nécessaire d'exécuter en amont le ws algoliens pour récupérer la sortie et stocker ensuite le fichier dans un répertoire ws_files, mais j'ai ensuite obtenu plusieurs erreurs à l'exécution, notamment ici par exemple. La fonction n'existe pas, j'ai essayé de la raccrocher à App\Service\WsHarvester :
$this->$wsHarvester->processContent($rcr, 2, $content); mais la function est déclarée en private et n'attend qu'un paramètre... Bref, du coup, j'ai abandonné.

Après Sylvain, je me dis que tu pourrais simplement ajouter un timeout plus élevé ici :

--- a/src/Service/WsHarvester.php
+++ b/src/Service/WsHarvester.php
@@ -159,7 +159,8 @@ class WsHarvester

             $this->batchImport->setUrl($currentUrl);
             $response = $client->request('GET', $currentUrl, [
-                'max_duration' => 0
+               'timeout' => {pour la valeur, à voir laquelle serait la plus pertinente. Chez moi, j'ai été obligé de pousser à 120 pour que ça fonctionne}
             ]);

Voilà, je ne sais pas ce que vous en pensez ? Merci, A+ Julien

[symac]

Bonjour @jsicot et désolé pour le retard ! En effet la commande avait du répondre à un besoin à un moment donné mais j'étais pas allé au bout de la finalisation. Je viens de déployer une nouvelle version ( 55b4ffcdb2e836f9dffd520f451923175f51c97d ) qui devrait mieux fonctionner et permet de tout charger en ligne de commande si on le souhaite (tout un ILN sans rien faire de spécifique, un RCR particulier si l'on a téléchargé le fichier au préalable). Resterait à charger un RCR particulier et que la commande se charge d'aller télécharger le fichier via le WS, pas d'usage à court terme donc je laisse là.

Concernant le problème du timeout de mémoire, c'était pas la requête qui plantait mais plutôt mon serveur Apache qui atteignait son timeout et n'allait pas au bout de la requête, d'où l'option de passer par la ligne de commande.