7.4

l As soon as possible:This option needs to be checked, otherwise requests will not be handled as they come in (this
option is meant to be used on scheduled processes that run at intervals).
l Polling Interval (sec):This option determines how much time the HTTPServer Input waits between the moment it
finishes processing a request and the moment it picks up a new request. This should be put at 0 in order to process
requests as soon as possible, meaning immediately.
And finally, the HTTPServer Input task properties. While these are described in the HTTP Server Input task properties page,
here are a few considerations to keep in mind when using this task:
l The HTTPAction corresponds precisely to the name immediately following the first slash of your address. That is to
say, placing the action myaction here means the process would be triggered by opening http://1-
27.0.0.1:8080/myaction in your browser.
l The HTTPservice accepts both POSTand GETrequests. Other than the presence of file attachments, there is little dif-
ference in how these are handled. This means that visiting /myaction?id=12345&q=test would be the same as
having a form with two <input> fields named, respectively, id and q, and submitting them with the information
"12345"and "test". In both cases, this information is located in the XMLenvelope that is the original input file.
l When doing POSTrequests and uploading files, always make sure to include the "multipart"option in the <form>tag:
<form action="http://127.0.0.1:8080/myaction" method="POST" enctype="multipart/form-data">
Otherwise, file attachments will not be received, only their file names.
l The Mime Type option is better left at Auto-Detect unless the process requires it to be forced to a specific type. This
means that if a process can either return a PDF when successeful or an HTMLpage with an error message, it will not
attempt to send an HTML with a PDFmime type (which, obviously, would cause confusion).
l There is no HTTPServer Output task (see below on how to end your process)
Request/Process/Response cycle
Once a process using the HTTPServer Input task is created, it is important to understand the cycle that is triggered when such
a process runs. Note that this is the process when the default HTTPServer Input task options are used (more on how that
behavior changes later):
1. A request is received by the HTTPservice.
2. This request is converted into an XMLrequest file along with one or more attachements when present.
3. The XMLrequest file and attachments are saved in a local folder, if the HTTPAction is a valid one (otherwise, the files
are deleted).
4. The HTTPservice keeps the request from the client open (it does not yet respond ot it), and waits.
5. The HTTPprocess corresponding to the HTTPAction captures the XMLfile and attachments and the process begins.
6. The process runs its course just like any other process would (including subprocesses, send to process, etc).
7. The very last file that is active when the process finishes is then returned to the HTTPservice.
8. The HTTPservice returns the file to the client and then closes the connection.
9. If, during this time, the timeout has expired (if the process takes more than 120 seconds), the HTTPservice returns a
"timeout"to the client, but the process stills finishes on its own. When the process finishes, the return file is ignored by
the HTTPservice.
Point 7 is critical to understand, as it has an impact on what the client receives. If a process receives a file that is split into mul-
tiple parts and each of these parts generates and output, the last split's output will be sent to the client. If the last output task
generates a PostScript file for printing, this PostScript is returned to the client.
In most cases, what is returned is what remains after the last task, but only if this task's processing is done in PlanetPress
Worfklow. For example, if the data file is a text file and this file is sent to PlanetPress Imaging using the Image connector, it is
a text file that is returned, not the output of the Imaging. Similarly, ending a process with the Delete task does not return an
empty file, it returns the actual data file.
Special Workflow Types