Utilisation drupal batch api avec services

Question

J'ai une application drupal qui a besoin de publier une partie de son contenu - il y a un frontal wysiwyg flash qui communique avec un backend drupal à travers le module de services. L'utilisateur peut télécharger des images/vidéos, les placer et les manipuler en flash, et quand ils auront fini, exporter une version statique. Dans le cadre de ce processus d'exportation, l'application doit effectuer un traitement sur les éléments médias - redimensionnement & etc, donc j'ai utilisé l'API batch pour qu'elle ne traite que les éléments à la fois pour arrêter les délais d'attente et ainsi de suite. Cela fonctionne principalement bien, mais je suis en train de me défaire de la façon dont batchapi semble fonctionner. Ce que je suis en train de faire est la suivante:

1. L'outil flash appelle le service d'exportation
2. Le service d'exportation crée un nœud qui représente cette exportation, et retourne un node_id
3. Les incendies de services d'exportation au large de la exporter en arrière-plan, une fois qu'il est fait, il change un statut dans le nœud
4. Pendant ce temps, l'outil flash interroge l'application pour voir quand la publication est terminée, et notfies l'utilisateur.

Ce qui semble me faire décoller au moment on tire hors du processus de traitement par lots en arrière-plan, sans déclencher la chose redirect ce lot fait quand je l'appelle batch_process(), pour que je puisse retourner l'identifiant de nœud à clignoter et initier le lot en même temps.

Espérons que cela a du sens - des suggestions/idées? Ou est-ce que je le fais mal?

Answer 1

pas 100% sûr (n'ont pas utilisé l'API de lot dans un certain temps), mais je vois 3 options en ce moment:

1. Utilisez votre flux de travail et définir le lot « init_message » à quelque chose contenant le noeud id:
   • Appelez le batch_process(), en acceptant la redirection. Votre application flash devrait suivre la redirection, puis analyser la page retournée pour extraire l'ID de noeud du message affiché
   • semble laid, bien que, comme vous auriez à analyser la page d'initialisation du lot standard:/
2. Oubliez le sondage et laissez l'outil flash attendre le résultat:
   • Comme pour l'option 1, votre outil flash devrait être en mesure de gérer les redirections émis par le traitement par lots - vous commenceriez le traitement par lots , définissant le $redirect_url à une page qui renverra le résultat au besoin par l'application flash.
   • Votre application flash suit les redirections, toujours vérifier la page de résultat - une fois là-bas, juste utilise
   • ne sais pas comment cela cadrerait avec le module de services, bien que/
3. de Split l'initialisation dans votre flux de travail:
   1. outil flash appelle le service à l'exportation sur une URL « amorçage »
   2. service d'exportation crée noeud et retourne id noeud (aucun lot a commencé ici!)
   3. outil Flash récupère id nœud et appelle le service d'exportation sur une URL « processus », en passant l'ID de noeud
   4. service d'exportation utilise passé ID de nœud pour initier le traitement par lots réelle (crée par lots et appelle batch_process())
   5. ... continuer comme par flux de travail d'origine (sondages, etc.)

la dernière version semble être le plus facile/plus propre, au prix d'une demande supplémentaire pour commencer la chose, ce qui ressemble à un problème mineur dans votre scénario.

---

Edit:

• Une variante de l'option 3 pourrait être pour que le service d'exportation initial (celui qui crée le noeud) pour appeler la page d'initialisation de lot au moyen d'un même drupal_http_request(), avant renvoyer l'identifiant de noeud à l'application flash. Même idée de base (diviser la demande initiale en une création du noeud et une autre en commençant le lot), mais plus autonome du point de vue des applications flash, car elle ne doit pas déclencher le traitement par deux appels distincts.