This document describes how to set up a Comet WebService. Nowadays, you will rarely want to do this, but rather build applications based on the PublishingHub and priint:publishing server. But for small integration tasks, setting up an Comet WebService may still be an option.

Both priint:comet and priint:comet server plugins can use an ODBC / OCI database, a local folder containing a set of XML files or a web service connection to retrieve configuration and application data.

The web service connection works very much like local XML files, except for the way files are retrieved and sent by the plugins. Instead of typical filesystem operations like “open”, “read” or “write” the web service must provide the two operations “getBinaryFile” and “putBinaryFile”. Well, then there's a couple of more methods for authorization or loading and saving placeholders, all in all about 10 (16 if you need batch processing too) methods all described in the WSDL documents below.

Currently we support two web service specifications. The elder is based on SwA to transfer binary data, also we use SOAP encoded arrays and other technologies not supported by all frameworks.

For the sake of completeness this is the old specification and a short guide how to integrate in axis:

• comet4axis.zip
• comet4axis.wsdl

From Revision 1735 (2010/02) a new service specification is supported. The following ZIP file contains two WSDL file and a couple of Java Interfaces. You can use the latter to import the service in a Java Application Server environment or use the WSDL for any other platform.

cometservice.zip

A simple reference implementation is included, which can easily be adapted for a full working version.

CometCore

Use this WSDL and Java Interface for “normal” PlugIn integration

CometBatch

Use this WSDL and Java Interface if you need batch processing too.

This is a very brief overview of all relevant SOAP operations. For further information contact support@priint.net

the PlugIns will always call the old Login method first (http://werk-ii.de/soap/comet#login) to determine which service specification must be used. New services must return a SOAP Fault in that case.
The login method must return a sessionID on success, which allows to identify this session for subsequent requests. The WebService can, but does not have to, evaluate the language and client parameter (e.g. for session initialization routines or authorization issues).
If login fails, the method should return an error code (i.e. return value != 0) and a qualified error message. The return code must not be 2, because this error code means "session expired" and causes the Comet Plugins to reconnect using the same credentials (which in this case wouldn't make sense).

Basically a SOAP project is very similar to an XML Offline project. A certain set of files will be requested using the getBinaryFile method.
You will find the required files in this archive:

• xmlroot.zip

This should just be implemented vice versa.
A file uploaded with a certain fileId should be available using the same fileId later.

Note that there is no delete command. Files should be deleted if the PlugIns send a putBinaryFile request with empty content.

These methods can be implemented according to the requirements of your application.
Both accept a method name and an argument string, which can be evaluated by your WebService application.

Commonly these operations will be used to load or save placeholder data. Depending on your configuration the request is initiated by an cscript function call (soap::call or soap::getlist) or triggered by the PlugIns.

Further information can be found in the PlugIn documentation or the sample actions in the XMLRoot archive.

All response messages include a resultcode. This must always be “0” on success, all other codes can be specified according to the requirements of your application except for result code “2”, this is reserved for “Session invalid or expired”.

The getMessage method should provide an appropriate message for each error code you use (otherwise an “Unknown error” message will be prompted to the user), in other words:
It's your responsibility to return convinient error codes for certain situations AND provide error messages for this codes.

Unless you intend to use InDesign® Server for batch processing you don't have to implement the methods starting with “autocomet”. You can either choose to use the CometCore WSDL and Interfaces or just omit the unneeded operations.

• products
• publications
• previews