Skip to end of metadata
Go to start of metadata

API function overview

The main goal of the overall workflow indexng work is to provide a way to scientist for searching workflows by its funcionality, properties, or other conceptualization allowing their easy accessibility.

In order to make the workflows more available to the users we have created an api which includes set of services that provide indexing, searching and recommending workflow processes.

The API will be described with more detail in the follwing sections.

API usage

The usage of this API is similar to most of the APIs that provide information for the users in the Wf4ever project (Stability services, Checklist, etc.).

Let's suppose that we have a process name (or list of processes). This will be the only input needed for running the API correctly.

  • Process/Processes: Name of the process or list of processes names that we want to use for the search or recommendation services.

1.The workflow abstraction services would then be invoked in a sequence of two HTTP operations:

Case 1: Search

Case 2: Recommend

Link relations

Links where the services are currently available:

General information about the workflow abstraction in wf4ever:

For other information see also:

HTTP methods

The only HTTP method available for this API is the GET method. Depending on the content negotiation (which is explained in the next point) we will get a)description of the service or b)results obtained by the invocation of the stability evaluation.

Service description


Searching inside workflows

The created trie structured provided for indexing purposes has been encapsulated in order to provided the next two services :

  • Search: it receives a sequence of processes and searches for workflows that contain that sequence.
    • Service_call: /wfabstraction/rest/search?process=Processor regex_value 
    • Inputs: sequence of processes names (?process=text1&process=text2)   
    • Output: xml or json structure providing the following info ( process_id, freq, URIs). 
      • Process_id: the name of the process used in the query
      • freq: How many times this process appears in other workflows.
      • URIs: Uris of the workflows where it the proecces appears.
  • An example of output is:



Recommendation service for processes inside workflows

  • Recommend: it returns the most frequent next process given a sequence of previous ones. 
    • Service_call: /wfabstraction/rest/recommend?process=Processor regex_value 
    • Input: sequence of processes names (?process=text1&process=text2) 
    • Output: xml or json structure providing the following info ( id, prob, freq). 
      • id: id of the recommended process
      • prob: The probability given for the recommendation to be correct.
      • freq: number of times it appears.
  • An example of output is:



Security considerations

Workflow abstraction is formed by a read-only functions, so there shouldn't be any security risks of adding or deleting content. The main problem is that this service provides information about names of processes and maybe not everybody wants to make the names of tis processes available.

Cache considerations

No cache considerantions have been taken as this service provides small amounts of information and it is no need to cache.

  • No labels