Public APIs for Adobe Central Pro Server

Question

Hi,
Can anyone point me to the Public APIs that are available with the Adobe Central Pro Server e.g. I would want my application to dynamically add or remove steps in the job db, or change the target printer. Also, is it possible to invoke the preview functionality that comes with the Adobe Designer and integrate with an existing application
Here what we are trying to do is add the printing (template merging) facility to an existing application and would want access to the public API for these products.
Thanks in anticipation!
Regards,

Answer 1

I'm not sure you can do what you describe in the manner that you appear to be wanting to do it. I know of no APIs that are provided. There are ways to get the job done, though.<br /><br />The job management data base is an ascii text file that can easily be changed programatically. Parts of our application use it for building a drop-down list of printers for the user to select from. Changing it doesn't automatically cause Central to use the new file. Central must be told to reload it before it will be using the modified file. This can be done by placing a certain "command" file in Central's control folder, but it would not run until after the current job completes - if the current job is the one that just changed the file and further steps of the same job are for the processing of the data, then that would be too late. Once a job starts, all the parameters and tasks from the job management database and on the original ^job statement is what will be used. This goes for changing anything about the job, whether it be adding/deleting steps, changing the printer, or any other parameters.<br /><br />We accomplish pretty much what you want by doing several things. <br /><br />*First, we define all of the various configurations of jobs that we need. For example, our main printing job has four tasks; it is not uncommon to need to restart a job someplace besides the first task. Therefore, we have four different jobs defined, each one starting further down the list of tasks. We do the same thing when the processing of the data has to vary in some manner - we have jobs pre-defined for each specific set of tasks and the source of the data sets the ^job name as required for the specific tasks that have to be done.<br /><br />*For modifying the printer, we use the -z<printer> and -asp<driver> parameters on the ^job statement and the source of the file sets the values as necessary. The source of the file will also set the job name so that the desired job is ran. <br /><br />*We also have built into our custom agents the capability to recognize when a "soft" failure is occurring (such as can't reach our database) and it will put the job back in for processing after changing the job name to run the correct job for restarting at the proper step. <br /><br />*One of our steps is to check a control file to see if there is a redirection for the specified printer to a substitute printer (say, the original printer is down for maintenance). This agent will put the job back in for processing, changing not only the job name but the printer parameters. It has to be put back in, instead of just changing the parameters and passing the file on to JFMERGE, because Central uses the parameters on the original ^job line, it doesn't use the parameters that might be on the ^job line when JFMERGE starts.<br /><br />*We have also created our own agent for running as the JFERROR task. This task runs when one of the agents supplied with Central encounter a failure. Our agent analyzes the failure and determines if it was "hard" or "soft". If it was a "soft" failure, this agent requeues the job, changing the name and parameters as necessary.<br /><br />So far we have been unable to determine how to get our VB6 agents to set the ErrorLevel to notify Central that the agent failed (we came up with a workaround instead of spending a lot of time trying to get the ErrorLevel to work). This is necessary to prevent Central's agents from processing when a predicessor custom agent fails. Since we couldn't set the ErrorLevel, we just set up all of our agents to always create an output file for input to the next task. When one of our agents fail, it only outputs a modified ^job line with no following data. This modified ^job line is recognized by our custom agents as an indication that a failure is in process so it skips any processing except to pass the file to the next task. Since there is no data or form commands in the file, once it gets to JFMERGE, it just terminates without producing any output or error condition.<br /><br />Previewing is accomplished by running the JFPVMRG agent to create a PDF and then JFPVSEND to send it to the originating IP# for receipt by the View Manager which will then load it into Adobe Reader. At this point, the job running on Central will be finished - it could have produced hard-copy output or not depending on its design. Once the user receives the PDF, they can do whatever they want with it (save, print, etc).<br /><br />We use the above capability for our users to view an "archive" image of forms, after it has been processed normally. I know of others that use it to create the PDF as part of the normal processing, allowing the user to then print from Adobe Reader it if they wish.<br /><br />What we do is to drop a DAT file into Central's input folder that runs the above two agents. Our application that is running on the user's PC then watches for Adobe Reader to load and when it does it forces it to be the top-most task (we do this because we have a problem that it will often open behind other windows).