external assets

since there are issues with UNC paths, how can I:

set a variable in designer to point to my root asset folder (containing different background pdfs).
use them as asset path in designer, then in workflow change that variable to another path (since the drive mapping is different).

I tried:

var assets = ‘file:///P:/mypathtoassets/’;
if (automation.jobInfos.JobInfo9 !=‘’){
assets = automation.jobInfos.JobInfo9;
}

bgURL = assets + “mypf.pdf”;

in workflow I tried to set the Jobinfo9 var to ‘file:///E:/mypathtoassets/’ but it didn’t work though in Designer it worked.

What do you mean “In Workflow … it didn’t work”? Do you mean the variable can’t be set to that value? Or the variable is set correctly but isn’t passed to the Designer?

the variable can be set, sure. but the external assets or the path aren’t found by workflow. I’m using a control script to switch backgrounds of print sections.

These backgounds should be loaded from an external folder, so I’ve to switch between path names to the assets since a UNC path (other post) doesn’t work yet.

The Workflow server addresses the path with file:///E:/… the workstation running designer has a mapped path file:///P:/…

In Designer the assets are displayed, but in workflow they don’t show (in the generated pdf).

Again… when you say in Workflow they don’t show, you mean when you run the Output Creation task (or the Create Content task), right? Which means it’s the Connect Server that’s unable to access the files.

Which means you should set the JobInfo9 value to be the path that the Connect Server should use to access the resources, not the path that the Workflow would use (since it’s not actually using those resources).

In addition, you are pointing both the Workflow and Designer to mapped drives. Are you certain those mapped drives are available to the Services? Remember that services may run under different user credentials than the Designer application (or than the Workflow Configuration tool, for that matter).

Tested this as well and it works.

Have

resourceURL = automation.jobInfos.JobInfo9 + ‘background.pdf’;

in a control script (with JobInfo9 holding the path to the PDF, e.g. ‘file:///c:/temp/’) and that works well in a Workflow process (it gets the PDF background printed as expected).

I’m running crazy…

If I set the path in the control script as:

URL=‘file:///E://PPWF//Folder1//data//background.pdf’; it gets the background printed (in workflow), so no file access issue.

if I set the path like:

URL = automation.jobinfos.JobInfo9 + ‘background.pdf’;
in workflow with Set Job Infos and Variables I set Var/Info# to value:
‘file:///E://PPWF/Folder1//data//’ (before datamapping…) nothing happens, no background.

Then I tried to render the jobinfo9 on the page with a text script in designer.

result = automation.jobInfos.JobInfo9;
results.html(result);

trying then to place the variable on the empty sheet just to see what’s in the jobinfo9:

It’s not visible, e.g. renders empty???

Am I missing something?

Why you have double slashes in your path strings? I don’t think this is necessary (though it may be for back slashes).

It works well here, but when using paths to network folders via mapped drives it fails in any case.

Also in a text script the JobInfo Variable seems to be out of scope as automation.jobFnfos.JobInfo9 is empty, but if assigning it to an extra record field in datamapper by script it works as the record field is in scope of a text script.

why the double quotes? I tested every combination and that worked :slight_smile:

Update: it worked, when passing the automation.jobinfo to an extra record field. thx a lot!

But: is it really necessary to pass a job-variable to a record? Imho that doesn’t make sense. It’s just info for the whole job not for the individual records.

it’s a limitation of the software at the moment, the automation object only is available for web context pages (see also note in online help), but in a future version this may be extended to all contexts.

So currently in a print context you need to pass on the jobinfo value via a record field it seems.