Jump to content

Original Input File Name Path

Recommended Posts

I'm trying to grab the name of the folder the original input file came from. FusionPro.inputFileName doesn't work because it changes to the path the scheduler uses once the file is composed.


I see that there is a somewhat relative path in the def file which contains the folder name. Is there any way to get that path?

Link to comment
Share on other sites

Two questions for you:

1. What exactly are you trying to do with the "original" input file path? What are you trying to accomplish?

2. In what context is this composition happening? In FusionPro VDP Producer? In FP Server via the Server API Web Service? In some other FP Server-based system (such as MarcomCentral or EFI Digital StoreFront)?


FusionPro.Composition.inputFileName returns the actual data file used for the composition, at composition time.


FusionPro.inputFileName should return the original input file path specified in the DEF (Data Definition) file, at both rule validation and composition time. And it does exactly that at composition time in FusionPro VDP Creator, for both regular and Preview compositions.


However, for a job that is collected up and composed via FusionPro VDP Producer or FusionPro Server, the "original" input file is the one that's collected into the Zip file or collect folder.


Even though we're in the FusionPro VDP Server (API) sub-forum, since you mention the word "Scheduler", I presume you're talking specifically about a FusionPro VDP Producer composition. In the case of Producer specifically, the "original" input file is the one in Producer's working directory. And that working directory is usually either a local path on that server, or a UNC path. (And actually, if you do a "Recompose" of the job via the Producer Monitor application, and upload a new input file there, then the "original" path returned by FusionPro.inputFileName will be the one originally uploaded with the job, while the "actual" file used for the composition returned by FusionPro.Composition.inputFileName will be the one you uploaded for the Recompose.)


Therein lies the rub: even if FusionPro.inputFileName returned the path of the original file that you specified in Acrobat, that's probably a local path on your client machine, and the Producer machine probably can't access that path anyway. (Even for full-on FP Server, if you're using the Server API Web Service, it's still generally going to be a path in the Server API's working directory, or in a similar location where the application stores its repository of submitted jobs.)


So, I'm not sure what good knowing that original path is going to do for you. Which brings me all the way around to my first question at the start of this post: For exactly what purpose are you trying to get that "original" data file path, and what are you trying to do with it? If I can understand what your ultimate goal is, then I can probably suggest a way to fulfill it.

Edited by Dan Korn
Link to comment
Share on other sites

The job is a regular template in acrobat that is then sent to the API server for composition.


What happens is data files are placed on a file server in a folder that is the job number. The input file itself is named in a predictable way but does not contain the job number, only the folder it's in has it.


The workflow is that the template is opened and the input file assigned, then it's sent to a producer server for composition. What I am attempting to do is read the folder name, ie the job number, and then rename the output file prefixed with the job number.


I did end up writing a function that reads in the def file to grab the job number. It works fine for this job but it seems like there should be an easier way to do it. The frustrating thing about this function is I have to hardcode in the template name and hope no one changes it or the def file wont read.


It would be really nice if there was a way to read the original input file path, which is already preserved in the def file. It would also be nice if the PDF template name was also preserved somewhere. I know I could have used that a few times on other projects.


If you have any other ideas on how to achieve this, I'd love to hear them. Here is the function I currently have working to get the number from the def file.


function get_job_no(template_name)
var iname = FusionPro.inputFileName;
var job_no = iname; //get number from iname in case job is composed locally

if (FusionPro.Composition.isBatch)
	var iname_path = iname.replace(/[^\\]*$/, ""); //gets path without file name
	var def_name = template_name.replace(/.pdf/i, "") + ".def";
	var XDF = new ExternalDataFileEx(iname_path + "\\" + def_name, "\t");
	job_no = XDF.GetFieldValue(8, 0);

return job_no.replace(/.+\\(.+)\\[^\\]+$/, '$1'); //gets last folder name from iname or XDF

Link to comment
Share on other sites

Thanks for that information. However, I'm still a bit confused as to exactly what workflow you're using. You say the job is "sent to the API server", which implies FP VDP Server (API), but you also say, "it's sent to a producer server," which implies FP VDP Producer, a completely different product. Can you elaborate a bit on exactly what you do (i.e. what you click on) to "send" the job? Sorry to be picky, but I need to nail this down, because what I suggest as a solution would be different depending on your product and workflow.


Also, I'm a bit fuzzy about exactly what is in your DEF file that you're trying to extract. Can you post the full <DataSource > section of your DEF file (the first 15 lines or so)?


In addition, can you supply the context of the rule that's calling the JavaScript function you posted? Specifically, what are you passing to it as the template_name parameter?


Or, the questions in my previous two paragraphs can be answered by posting the collected job (without the fonts).


As for wanting to know the PDF template file path, that also depends on the workflow. There is definitely a way to retrieve that in a FusionPro Server workflow, but it's harder with Producer. If you can elaborate on what you are trying to do with the template file path, that would be helpful as well.


I can tell you, at least in a general/philosophical sense, that FusionPro is not designed to rely on knowing either the names or paths of any of the files you mention. You can have a perfectly valid FusionPro job that has no input data file at all, with the "None" input option, or a job that uses an abstract ODBC data source. Likewise, you can have a perfectly valid FusionPro job with no "background" or "template" PDF file at all. For that matter, with FP Server, you don't even technically need a Data Definition file, as the older DL Formatter product which was the precursor to FusionPro didn't even have that concept, and just did a more basic data merge, without any rules, using a tagged markup data file, a DIF file, and a CFG file.


Furthermore, FusionPro is designed so that most jobs can be transferred, collected, and composed on any computer anywhere, even with swapping in new data, in generic workflows which don't rely upon specific file paths or naming conventions. It's also designed with custom workflows and applications in mind, especially with FP Server, where other apps can customize almost any aspect of a FusionPro job. Following on that, while you can write rules which do things based on file paths, it's hard for us to anticipate every possible such workflow. Therefore, we can't support everything under the sun without some custom programming, and that kind of programming is often more appropriately done outside of FusionPro, in another application which handles its own business logic to modify the data, and possibly the layout (via the DIF API), then invokes FusionPro with those parameters, rather than putting that kind of business logic into JavaScript rules in a FusionPro template. Whether your requirements fall into that category is not yet completely clear to me, but it sounds like you're heading in that direction.

Link to comment
Share on other sites

Sorry if I confused the issue with the product names. The server itself has the API on it. In this particular case, it's just used to compose jobs being sent to Producer.


I understand everything you are saying and understand the limits and intent of the product.


I will try to elaborate on the workflow. The client sends a data list to an account manager who then creates a job number. A folder is created on a file server which is named the job number. The data file which is named by the customer is then placed in that folder.


So it might look something like this: //SERVER/Jobs/12345/filename.csv


The data team then gets the job. They simply open the PDF FusionPro template and define the data file. Then the job is composed using the FusionPro Producer server. The job is then sent off to the other server which has no knowledge of the file server where the original csv came from.


Inside the template is an OnNewOutputFile rule.


var template_name = "MyTemplateName.pdf";
FusionPro.Composition.outputFileName = get_job_no(template_name) + "_MyOutputName.pdf";


When this file is then sent off to the server for composition, FusionPro.inputFileName of course gets a new path local to the server, no longer the original path to the csv. This makes perfect sense. I'm not questioning that at all.


What I need is to get the folder name (the job number) from the original path of the csv so the output file can be renamed with the job number. This is the only place where the job number would reside as its not part of the csv or of any other rules being brought in as data.


The original input file path is preserved in the def file in the server working folder:


<?xml version="1.0" encoding="UTF-16"?>
<!--Data Source Definition file generated by: FusionPro(R) VDP Server 10.1.9
MajorVersion = "7" 
MinorVersion = "1">
     FileName = "..\..\Jobs\[color="Red"]12345[/color]\filename.csv"
     Type = "Delimited Text" 
     Delimiter = "," 
     FirstRow = "true" 
     TaggedStrings = "false" 
     Encoding = "default" 


The function posted earlier reads the def in as an external data file and extracts that job number so when OnNewOutputFile runs, it can properly rename the output file with the job number.


With the output file named with the job number prefix, it can then go into a queue to be proofed and so forth.


What would be ideal is to avoid having to read in the def since FusionPro already knows that path. If there was a function to grab the original data file input path, instead of the current path the server needs at composition, this would be pretty straight forward.


I really hope this clears things up. As it stands, the problem is solved, it just feels clunky.

Link to comment
Share on other sites

Thanks for the further explanation.


If you already have a license for FP Server, then you have the ability to use the FusionPro Server Web Service API, and the Manager app that comes with it. You can use this to either (A) program your own application to invoke FusionPro in an automated way, or (B) to set up hot folders, where you can specify that FusionPro will compose a particular template when a data file is dropped into a folder, and how the output file name gets generated, where one of the options is to base the output file name on the input (data) file name.


Frankly, the whole reason to have FP Server is to automate a workflow like that, so that you don't have to have humans (your "data team") performing a manual workflow step ("open the PDF FusionPro template and define the data file"). (This, of course, is a corollary to the idea that the whole reason that you have a computer in the first place is to automate repetitive tasks.)


So, if your "About FusionPro" box says you have FusionPro VDP Server, and if you don't already have the FP Server Web Services API system and the Manager app, then please contact Support to obtain the API system.

Edited by Dan Korn
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...