Some questions about the server version

[samiboy]

Hello,

 

I am trying to figure out the following:

 

A) Is there a way to invoke the FP server through an API? or is DLQueue the only way?

 

B) What is the difference between the current Server version and the previous versions, which weren't named "server" but seem to be doing the same. In the older version I would pass the DLQueue (or directly to FP on the command line) the path of 3 files, and I still do it now. ?

 

Thanks in advance!

Sam

[Dan Korn]

A) Is there a way to invoke the FP server through an API? or is DLQueue the only way?

 

FusionPro Server is simply a command-line application (FusionPro.exe). It can be invoked the same way as any other command-line utility.

 

DL Queue can run any command-line app, but it's by no means the only possible way to do so. We provide it as a convenience to FP Server customers.

 

We are currently investigating a new DL Queue-like interface to allow easier interaction with newer technologies like .NET Web Services. However, like the current DL Queue, this will most likely be a layer which sits on top of the existing command-line interface.

 

What kind of API would you like to see? Your feedback will be extremely valuable.

 

B) What is the difference between the current Server version and the previous versions, which weren't named "server" but seem to be doing the same. In the older version I would pass the DLQueue (or directly to FP on the command line) the path of 3 files, and I still do it now. ?

 

I'm not sure to what previous versions you're referring (DL-1000 maybe?), but the interface is the same. It's actually four files:

 

• Input file
  
• Format (.dif) file
  
• Job Settings (.cfg) file
  
• Output file
  

However, in FusionPro 4.0 and later, there is an alternate command-line interface to FusionPro Server, which is a single parameter specifying a Job Settings (.cfg) file, with optional entries for the other settings (InputFile, FormatFile, OutputFile, etc.). This was added to facilitate the use of a single job file; however the old four-parameter interface is still supported.

[samiboy]

Thank you for replying Dan.

 

Quote:

"We are currently investigating a new DL Queue-like interface to allow easier interaction with newer technologies like .NET Web Services. However, like the current DL Queue, this will most likely be a layer which sits on top of the existing command-line interface.

 

What kind of API would you like to see? Your feedback will be extremely valuable."

 

That would be great. What I'd like to see is to be able to write something like this:

 

FusionPro fusionProInstance = new FusionPro();

 

String newPDFPath =fusionProInstance.CreatePDF(Input file, Format (.dif) file, Job Settings (.cfg) file, Output file);

 

and internally you'll be handing all the queuing necessary for handing high volume, but it would be completely abstracted...And I won't have to worry about running and configuring DL Queue as long as I'm running everything on the same machine...that would be great.

 

Also: Is it would be great if the CreatePDF call above can have an overload that takes files contents (string) instead of hard files,

and returns the pdf data stream.

Like this:

 

byte[] newPDFSteam =fusionProInstance.CreatePDF(string Input file, string Format (.dif) file, string Job Settings (.cfg) file, Output file);

 

(Internally you can temporarily save the files) this will help decouple FusionPro server machine from having to have all files on the same machine. This means I could have on instance of FusionPro and I can call it from multiple clients without having to worry about what files are sitting on the FP machine.

 

Does this make sense?

 

Thanks

samiboy

[Dan Korn]

Thanks samiboy. That's great feedback. It does make sense, and it pretty much lines up with what we've already been thinking about for a new API.

 

There would likely still be some minimal configuration on your ASP.NET web server to let the API know how you want to run the jobs, e.g. under what user account and, optionally, on which FP Server machine, or on which set (queue) of multiple FP Server (Target) machines.

 

Traditionally, the way to run FP Server jobs through DL Queue is to set up all the paths to be UNC so that the job can run on any Target machine on the network, both to access resources and to write the output. However, I like the idea of being able to return the output file as a stream directly from the Web Service. This is basically what FP Direct does already when you click "View Output" from the FP Direct Monitor program. FP Direct also sends over all the job files in the collected ZIP file; in other words, it streams the input to FP Server as well, which would seem to be the logical counterpart to the streaming output in your example API.

 

So that suggests that there are two different paradigms for the new API to support: one where you pass around UNC file names (or, less Windows-centric, file URLs) for input and output, and one where the input and output data are streamed in the API call.

[samiboy]

Yes Dan That's exactly it.

 

Let me just add one thing though, it would be beneficial to have a mixture of both path and Stream for the different files (for example: a steam for the instance file and path for the config file) , because I can see us not having the need to send the cfg file from the client. So it would be great if I can do the follwoing revised code:

 

FusionPro fusionProInstance = new FusionPro();

 

//i have the option to either use steam or path

fusionProInstance.SettingsFilePath = path;

fusionProInstance.InstanceFileSteam = steam;

//set the rest of the files path/stream properties

 

byte[] newPDFSteam =fusionProInstance.CreatePDFStream();

//and an overload in case all params are stream

byte[] newPDFSteam =fusionProInstance.CreatePDFStream(byte[] instance file, byte[] cfg....);

 

//or

string newPDFURL = fusionProInstance.CreatePDFPath();

//and an overload in case all params are path's

string newPDFSteam =fusionProInstance.CreatePDFPath(string instance file path, string cfg path....);

 

This way i am not locked into all path or all stream.

 

Just a suggestion.

 

Thanks again for your reply

samiboy

[Dan Korn]

Thanks again samiboy, more great ideas.

 

I'm actually thinking about an API where the CFG file settings are properties on the "job" object, so you could potentially do something like this in your C# code:

 

FusionProJob myJob = new FusionProJob();
myJob.Layout = new FusionProLayout(@"\\server\path\myjob.dif");
myJob.DataDefinition = new FusionProDataDefinition(@"\\server\path\myjob.def");
myJob.Input = new FusionProFlatInput(@"\\server\path\myjob.csv", ",", true);
myJob.OutputFormat = "PDF";
myJob.EmbedFonts = true;
// other CFG-type setttings...
FusionProServer server = new FusionProServer(
       @"http://localhost/FusionPro/Composition.asmx");
int result = server.Compose(myJob);
byte[] newPDFSteam = myJob.StreamOutput();

Where (I envision) the FusionProLayout object would be a .NET-y version of the current DIF API, the FusionProFlatInput object would be a way to specify a file, delimiter, etc., and the FusionProServer object would be basically a wrapper on the new DL Queue-type web service and the command-line FP Server (configured on the web server). The FusionProDataDefinition object could also have an API behind it to define resources, rules, and other "Input Options"-type things. We're brainstorming all kinds of ways to break up everything you need to define and run a job into a .NET/XML object-oriented API.

[mrboston]

The last post on this thread was two years ago. Are you any closer to providing a real FusionPro Api that can be instantiated and interfaced programatically instead of in batch mode?

[Dan Korn]

The last post on this thread was two years ago. Are you any closer to providing a real FusionPro Api that can be instantiated and interfaced programatically instead of in batch mode?

Yes! We are currently working on a .NET-compatible Web Service interface to FusionPro Server, implemented in a Windows Service which can be installed on any computer running FP Server with minimal configuration. It will support both multi-record batch compositions and single-record previews. A C# example of a call to make a Preview is:

List<FPQueueWCFServices.DataField> dataFields = new List<FPQueueWCFServices.DataField>();

foreach (DataGridViewRow row in dataGridView1.Rows)
{
   FPQueueWCFServices.DataField dataField = new FPQueueWCFServices.DataField();
   dataField.Name = (string)(row.Cells[0].Value) ?? "";
   dataField.Value = (string)(row.Cells[1].Value) ?? "";

   dataFields.Add(dataField);
}

int id = 0;
string errormsg;

FPQueueWCFServices.Preview request = new FPQueueWCFServices.Preview();
request.Data = dataFields.ToArray();
request.GroupName = groupName;
request.TemplateName = templateName;
request.TimeoutSeconds = -1;

string url = FormMain.myFPWcfService.GetPreviewJPEG_URL(request, ref id, out errormsg);
if (!string.IsNullOrEmpty(url))
   pictureBox1.Load(url);
else
   MessageBox.Show(errormsg, "Preview failed");

We're expecting to release a Beta version of this later this quarter (by the end of the month). Please contact Sales if you're interested in participating in Beta testing.