Skip to content

Chris workflow

Jump to bottom
Rudolph Pienaar edited this page Aug 9, 2016 · 29 revisions

#Client-side workflow

##Working with the Chris REST API

The Chris REST API uses the standard Collection+JSON hypermedia type to exchange resource representations with clients. All the functionality provided by the API can be discovered by clients by doing GET requests to links ("href" elements) presented by the hypermedia documents returned by the web server, starting with the "home page" url. The "home page" relative url would be: /api/v1/

In order to run a plugin app with specific arguments a client agent can follow the following workflow:

1. GET /api/v1/ 
2. GET "url with rel=plugins within the links list of the previous response" Eg.: GET /api/v1/plugins/
3. Look for the desired plugin in the items collection of the previous response and then GET "url with rel=instances" Eg.: GET /api/v1/plugins/1/instances/
4. Fill out the template object of the previous response and then do a POST request to the same url. Eg.: POST /api/v1/plugins/1/instances/ template:={data...}

Example

Let's assume you have a completely new session. The following "conversation" shows how to interact with a workflow consisting of a "FS" and "DS" plugin:

First start the server....

fdsdfsdfdsa

Now get the FS plugin list:

http fdskaljflsadjfklsafjlsa

Which will result in

fdsfsa

fdsaf
dsafsa

Now, note that the "links" field ocn

#Server-side workflow

##Developing a Chris plugin app

Chris plugin apps are Python packages that contain a module with the same name as the package. The module can be run from the command-line with a series of previously defined arguments to perform any predefined computing task. Internally plugin apps are added to the Chris Django project under the services package in the plugins django app. So given a Chris plugin app called simplefsapp it is possible to import it anywhere in the Django project:

from plugins.services.simplefsapp import simplefsapp

The Python module must define a single class that inherits from ChrisApp, the base class for all Chris plugin apps. Two methods are required to be overridden:

  • define_parameters(self)
  • run(self, options)

The first method can be overridden to define the arguments expected by the Chris plugin app. This can be done by calling the add_parameter method to individually define each single argument. add_parameter accepts the same arguments as the add_argument method of the ArgumentParser class defined in the Python's standard [argparse] (https://docs.python.org/3/library/argparse.html#module-argparse) module.

The second method can be overriden to define any computing task. The options argument is an object containing the arguments passed to the plugin app as attributes plus two additional attributes:

  • options.inputdir , directory containing the input data files (only available for plugin apps of type 'ds')
  • options.outputdir , directory where the app's output data files must be written

##Adding/removing a Chris plugin app

A new Chris plugin app can be added to the system by an administrator by first placing the corresponding python package in the appropriate subdirectory as explained above. The administrator can then register the plugin app with the system by running the plugin app manager which is a Python command-line utility also located under the services package in the plugins django app. Eg.:

python manager.py --add simplefsapp

After this the REST system will be aware of the new plugin app and will be able to respond to related HTTP requests.

To remove the plugin app the administrator can run:

python manager.py --remove simplefsapp
Clone this wiki locally