Revision as of 17:39, 20 May 2019

Aim of this service is to describe the implementation of gFeed-Service (for more information refer to GFeed).

Architecture

Deployment

Plugins

Plugins are expected to be found in the service classpath. They are typically distributed as uber-jar and their deployment depends on the hosting container.

To see a complete list of available plugins implemetations please refer to gFeed-Plugins

IS Requirements

The following is a list of minimal requirements for the execution of gFeed Service. Please keep in mind that depending on deployed plugins these requirements may not be enough.

• Database : the service needs a dedicated DB for its logic and looks in the current context for a DB registered as Service Endpoint with
  • Category : Database
  • Name : Feeder_DB

• Common configuration : the service loads default plugins configurations from the IS by lookig for a Generic Resource registered as
  • Secondary type : configuration
  • Name : gcat-feeder

HTTP Interface

Following is a list of methods exposed by gFeed HTTP interface. All methods require authentication so keep in mind that a gcube-token is expected. In this section <BASE_URL> stands for http(s)://<HOSTNODE>/gCat-Feeder/gcube/service/ where <HOSTNODE> should be determined by querying the gCube Information System.

Capabilities

Get available collectors

In order to get information on available collectors clients can perform a GET HTTP method on <BASE_URL>/capabilities/collectors. The response is a JSON representation of available collectors.

Get available controllers

In order to get information on available controllers clients can perform a GET HTTP method on <BASE_URL>/capabilities/controllers. The response is a JSON representation of available controllers.

Executions

Submission

Get submission history

In order to get the history of submitted executions clients can perform a GET HTTP method on <BASE_URL>/execution. The response is a JSON array of reports referring to submitted executions.

Get report

In order to get a report for a specific execution clients can perform a GET HTTP method on <BASE_URL>/execution/<EXECUTION_ID>, where <EXECUTUION_ID> is the id returned from submission method. Aim of this method is to monitor the outcome of a submitted execution (Asynch logic).

Please keep in mind that detailed reports are provided as a text file, accessible at reportUrl. The following is a report example :

 {
    "id": 4,
    "collectors": [
      "DATAMINER_ALGORITHMS_COLLECTOR"
    ],
    "catalogues": [
      "GCAT"
    ],
    "callerEncryptedToken": ...,
    "callerIdentity": ...,
    "callerContext": ...,
    "status": "SUCCESS",
    "reportUrl": ...,
    "startTime": ...,
    "endTime": ...
  }