<commit_before># Workflow Service

The pz-workflow service enables the construction and use of "event" notifications to enable simple "if-this-happens-then-do-that" workflows.

A user will follow these general steps:

. Register a new event type
. Register a trigger for that event type
. Send an event
. Poll for new alerts
. Go to 3.


## The EventType

The user (or some service) first defines an `EventType` which is the "schema" for the events that the user will be generating. The `EventType` object is POSTed to `/eventType` and contains contains a `name` (string) and a map describing the event type's parameters.

The request payload looks like this:

[source,json]
----
{
    "name": "testevent-1468847218",
    "mapping": {
        "filename": "string",
        "code":     "string",
        "severity": "integer"
    }
}
----
The `name` must be unique across all event types.

The available data types are `string`, `boolean`, `integer`, `double`, `date`, `float`, `byte`, `short`, and `long`. (By no coincidence, these are the basic types that Elasticsearch supports.)

The response payload looks like this:

[source,json]
----
{
  "statusCode": 201,
  "type": "eventtype",
  "data": {
    "eventTypeId": "98fc25e8-bd97-4444-a972-c06aa0f0edf1",
    "name": "testevent-1468847218",
    "mapping": {
      "code": "string",
      "filename": "string",
      "severity": "integer"
    },
    "createdBy": "xyzzy",
    "createdOn": "2016-07-18T13:06:58.983944263Z"
  }
}
----


## The Trigger

The user then defines a `Trigger` which defines what action is to be taken when a specific event occurs. The `Trigger` is POSTed to `/trigger` and contains two parts, the `Condition` and the `Job`. The `Condition` defines what type of event is to be watched for and what the specific parameters of that event should be, expressed using Elasticsearch DSL query syntax against the parameters in the event type. The `Job` defines what action is to be taken, expressed as using Gateway/Dispatcher-style syntax.

The request payload looks like this:

[source,json]
----
{
    "title": "High Severity",
    "enabled": true,
    "condition": {<commit_msg>Update JSON formatting<commit_after># Workflow Service

The pz-workflow service enables the construction and use of "event" notifications to enable simple "if-this-happens-then-do-that" workflows.

A user will follow these general steps:

. Register a new event type
. Register a trigger for that event type
. Send an event
. Poll for new alerts
. Go to 3.


## The EventType

The user (or some service) first defines an `EventType` which is the "schema" for the events that the user will be generating. The `EventType` object is POSTed to `/eventType` and contains contains a `name` (string) and a map describing the event type's parameters.

The request payload looks like this:

[source,json]
----
{
    "name": "testevent-1468847218",
    "mapping": {
        "filename": "string",
        "code":     "string",
        "severity": "integer"
    }
}
----
The `name` must be unique across all event types.

The available data types are `string`, `boolean`, `integer`, `double`, `date`, `float`, `byte`, `short`, and `long`. (By no coincidence, these are the basic types that Elasticsearch supports.)

The response payload looks like this:

[source,json]
----
{
    "statusCode": 201,
    "type": "eventtype",
    "data": {
        "eventTypeId": "98fc25e8-bd97-4444-a972-c06aa0f0edf1",
        "name": "testevent-1468847218",
        "mapping": {
            "code": "string",
            "filename": "string",
            "severity": "integer"
        },
        "createdBy": "xyzzy",
        "createdOn": "2016-07-18T13:06:58.983944263Z",
    }
}
----


## The Trigger

The user then defines a `Trigger` which defines what action is to be taken when a specific event occurs. The `Trigger` is POSTed to `/trigger` and contains two parts, the `Condition` and the `Job`. The `Condition` defines what type of event is to be watched for and what the specific parameters of that event should be, expressed using Elasticsearch DSL query syntax against the parameters in the event type. The `Job` defines what action is to be taken, expressed as using Gateway/Dispatcher-style syntax.

The request payload looks like this:

[source,json]
----
{
    "title": "High Severity",
    "enabled": true,
    "condition": {
{'fraction_non_alphanumeric': 0.11623108665749655, 'fraction_numerical': 0.030261348005502064, 'mean_word_length': 3.4384537131230926, 'pattern_counts': {'":': 38, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3815540', 'n_tokens_mistral': 1372, 'n_tokens_neox': 1270, 'n_words': 540}