Is there a working example and tutorial on how to use this new feature?
I wrote an article a few months back for internal use, but it hasn’t been picked up by our documentation team yet.
So here a link to a zip file that contains a PDF version of that article, along with several resources that allow you to see how the feature can be used and to run tests to compare the performance of the new REST call with that of the traditional means of enhancing an existing PDF.
1 Like
Thank you! I’ll check it out.
I understand the demo workflow, thank you. But isn’t this supported through standard plugins? When I use your sample process and Ignore the “Create Print Content” step on the first branch, the Create Job task throws an error that there is no valid content set.
No, this is not available through standard plugins yet, you can only access the functionality through scripting.
As for the process, I guess the article wasn’t clear enough: the 4 branches demonstrate 4 different means of running an end-to-end job and only the last branch uses the content-creation bypass feature. The process is meant as a way to compare performance between all 4 methods (it was used to produced the bar charts in the article)
.
So really, all you’re interested in is the script on row 19.
1 Like
I understood the process. It’s just not something I can deploy; my users aren’t coders, so features that aren’t support by the plugins aren’t features I can use, unfortunately.
It would be fairly simple for you to create your own custom plugin, using our Custom Plugin Packager (download it from this page).
That way, you fully control the contents and behavior of your script, while providing an easy-to-use plugin for your users.
It’s mainly a support issue. Client doesn’t want to have custom Run Script blocks or plugins in production.
That said, I’m personally interested in becoming better at using the API.
Why do the resources, already sent to the server, need to be “uploaded” to the filestore?
And the “application/octet-stream” vs. “/xml” vs. “/zip”: some links to further reading on why the different types would be helpful. (EDIT: found this in the Help:
)
>> Why do the resources, already sent to the server, need to be “uploaded” to the filestore?
Files may become out of sync at some point. You might make a change to a template and send it to Workflow, but until that change is also propagated to the FileStore (which is where the Merge Engine will look for it), it can’t be used by Connect.
>> the “application/octet-stream” vs. “/xml” vs. “/zip”
Not quite sure what you are asking. Do you mean to say you’d like to upload XML or ZIP content specifically? To Connect, it doesn’t matter, it’s just a data file and is always treated as a binary stream to avoid any possible loss of data if any conversion/validation were to occur.
The only reason for specifying a content-type when uploading a file is to give the receiving end an indication on the type of file being sent so it can process it accordingly. But the Connect file store does not process the files. It just stores them.