[SOLVED] Is printing from the Designer versus the Workflow any different performance wise?

OL Connect Professional
1

It’s been a while among my colleagues that we debate whether doing big print jobs (10k, 50k+ records either with Document splitting or big merged PDFs) directly from the Designer or from the Workflow is better.
There are occasional spot jobs where building a workflow wouldn’t be really needed since the print job is very straightforward and the job is do it and trash it afterwards.
This debate has random data points with little real analytics supporting both arguments.

However, these days while fidgeting with the REST API endpoints getOperations I noticed that when a print workflow is submitted through the Designer or the Workflow the process operations are different. This brought me back to the above perplexity.

If the API treat these runs differently maybe also the underlying process is executed differently?

For the sake of the topic assume a basic print job with a datamapper, a template a base job preset (nothing changed from defaults) and a base output preset (nothing changed from defaults).

Specifically I am referring on how operations are represented in the JSON Operation list returned by all the getOperations endpoints.

Print job from the Designer

All operations are of type PrintRestService with subTask Content Creation, Job/Output Creation.

Print job from the Workflow

The JSON Operation list follows what I would have expected to be the only possible pipeline:

  • DataminingRestService with the datamining operation.
  • ContentCreationRestService with the template mixin.
  • JobCreationRestService
  • OutputCreationRestService
2

Hi @Maxiride,

What getOperations returns for Workflow vs Designer should look the same if the workflow uses the “All in One” task.

Based on your description it sounds like your workflow uses separate “Execute Data Mapping”, “Create Print Content”, “Create Job” and “Create Output” tasks instead, which follows a different path.

Printing from the Designer always follows the “All in One” path. “All in One” is mostly just a convenience wrapper around the various subtasks, so I would expect performance for both paths to be similar.

However, “All in One” does have some smartness where it will run Data Mapping and Content Creation in parallel if possible, so perhaps there are cases where that will be slightly faster than chaining the subtasks.

2 Likes
3

Exactly, sorry I didn’t specified that.

Thanks for the clarification!