Idea Delivered

A RESTful Web Services API was added to the product with XPP 9.3.

It is available, and is distributed for use with any new installation or upgrade as of the XPP 9.3 release.

XPP Restful API Web Services

Replace Web Services with a RESTful API that is URL addressable for XPP functionality.

Low-level "micro" services (toxsf, compose, print, citi, etc) supported by XPP, that can be built upon for more high level customized  functionality.

Steve Piercey
Parents

  • And now on what exactly happens when we check a (task) ID

    Can you give us an idea on how you see the communication taking place?

    Here are my thoughts on a possible implementation

    So a GET .../xpp/docs/first:xyvision:comp:blkmerge:1-blkmerge/processes/compose will run in async mode and return a task ID

    Lets say the command to check on this task ID is:

    GET ../xpp/status/#TASKID will have to return the status, which could be either 'running', 'completed', 'error'. I guess that this status will be returned as JSON object  { "status": "running"}

    It could be nice if this object also contains something like { "status": "running", "progress": "processing page 5"}, so that the caller gets an idea of what is going on and where we are in the process.

    When the task is completed the response could be:

    { "status": "completed", "progress": "...the complete compose log ...", "exitcode": 0}

    The JSON object returned by XPP could contain other information that you think could be useful. Implementations not interested in the extra information can just ignore the parts that they are not interested in.

    The same could be true for all commands that just get executed (compose, toxsf,..)

    But I wonder how things will be done for commands that generate a resulting file like divpdf, xychange,..

    Will it be something like:

    GET  .../xpp/docs/first:xyvision:comp:blkmerge:1-blkmerge/processes/divpdf -> returns a 200 + TASKID (in a JSON object?)

    Then we do a number of GET../xpp/status/#TASKID till xpp returns a status of completed with also all console output generated by the divpdf process.

    Then do we get access to the resulting PDF file?

    Could it be as simple as doing a GET ../xpp/result/#TASKID ?

    Because like that we do not have to care about where xpp will generate the pdf file or even how it is named by xpp...

Comment

  • And now on what exactly happens when we check a (task) ID

    Can you give us an idea on how you see the communication taking place?

    Here are my thoughts on a possible implementation

    So a GET .../xpp/docs/first:xyvision:comp:blkmerge:1-blkmerge/processes/compose will run in async mode and return a task ID

    Lets say the command to check on this task ID is:

    GET ../xpp/status/#TASKID will have to return the status, which could be either 'running', 'completed', 'error'. I guess that this status will be returned as JSON object  { "status": "running"}

    It could be nice if this object also contains something like { "status": "running", "progress": "processing page 5"}, so that the caller gets an idea of what is going on and where we are in the process.

    When the task is completed the response could be:

    { "status": "completed", "progress": "...the complete compose log ...", "exitcode": 0}

    The JSON object returned by XPP could contain other information that you think could be useful. Implementations not interested in the extra information can just ignore the parts that they are not interested in.

    The same could be true for all commands that just get executed (compose, toxsf,..)

    But I wonder how things will be done for commands that generate a resulting file like divpdf, xychange,..

    Will it be something like:

    GET  .../xpp/docs/first:xyvision:comp:blkmerge:1-blkmerge/processes/divpdf -> returns a 200 + TASKID (in a JSON object?)

    Then we do a number of GET../xpp/status/#TASKID till xpp returns a status of completed with also all console output generated by the divpdf process.

    Then do we get access to the resulting PDF file?

    Could it be as simple as doing a GET ../xpp/result/#TASKID ?

    Because like that we do not have to care about where xpp will generate the pdf file or even how it is named by xpp...

Children
No Data