views:

37

answers:

1

I have a drupal app that needs to publish out some of it's content - there is a flash wysiwyg front end that communicates with a drupal backend through the services module. The user can upload images / video, places and manipulates them in flash, and when they are done will export out a static version. As part of this export process the app needs to do some processing on the media elements - rescaling &etc, so I have made use of the batch api so it only processes on element at a time to stop timeouts and so forth. This mostly works ok, but I am getting unstuck by the way batchapi seems to work. What I am trying to do is this:

  1. The flash tool calls the export service
  2. The export service creates a node that represents this export, and returns a node_id
  3. The export service fires off the export in the background, once it's done it changes a status in the node
  4. Meanwhile the flash tool polls the app to see when the publish is done, and notfies the user.

What seems to be getting me unstuck at the moment is firing off the batch process in the background, without triggering the redirect thing that batch does when I call batch_process(), so that I can return the node id to flash and initiate off the batch at the same time.

Hopefully that makes sense - any suggestions / ideas? Or am I Doing It Wrong?

A: 

Not 100% sure (haven't used batch API in a while), but I see 3 options right now:

  1. Use your current workflow and set the batch 'init_message' to something containing the node id:
    • Call batch_process(), accepting the redirect. Your flash app would need to follow the redirect and then parse the returned page to extract the node id from the displayed message
    • sounds ugly, though, as you'd have to parse the standard batch initialization page :/
  2. Forget the polling and let the flash tool wait for the result:
    • As with option 1, your flash tool would need to be able to handle the redirections issued by the batch processing - you'd start the batch processing, setting the $redirect_url to a page that will return the result as needed by the flash app.
    • Your flash app follows the redirections, always checking for the result page - once there, it just uses it
    • not sure how this would fit with the services module, though :/
  3. Split the initialization in your workflow:
    1. Flash tool calls export service on a 'bootstrap' URL
    2. Export service creates node and returns node id (no batch started here!)
    3. Flash tool retrieves node id and calls export service on a 'process' URL, passing the node id
    4. Export service uses passed node id to initiate the actual batch processing (creates batch and calls batch_process())
    5. ... continue as per original workflow (polling, etc.)

The last version seems to be the easiest/most clean one, at the cost of an additional request to start the whole thing, which sounds like a minor issue in your scenario.


Edit:

  • A variation of option 3 might be to have the initial export service (the one that creates the node) to call the batch initialization page by means of a drupal_http_request() itself, before returning the node id to the flash app. Same basic idea (split the initial request into one creating the node and another starting the batch), but more self contained from the flash apps 'point of view', as it does not have to trigger the processing by two separate calls.
Henrik Opel
YOu have given me some clues, I think, but it is still taking a while to get my head around it. There is something about setting the batch to be non-progressive here: http://drupal.org/node/638712 but not sure I completely get it.
Andrew
but then a non-progressive batch is of no use to me in this case. hrm.
Andrew
Yup - if I understand the code in `batch_process()` and `_batch_process()` correctly, setting `$batch['progressive']` to FALSE will just cause the batch to be processed in one go, thus loosing the main advantage of avoiding timeouts.
Henrik Opel

related questions