Server Requests pair an action (notification, logging, debugging, capture history record, etc) with a server request REST api call. There are two steps in providing this functionality:

• Annotate or decorate server API functions with an annotation that will wrap the function providing additional processing to the existing function.
  This is 'aspect oriented programming' providing common features across multiple REST functions. This is also referred to as 'cross-cutting concerns'. In this case the common feature is attachment of additional processing before or after the REST request is processed.

Current Implementation: The api for a form record (fetch, add, update) have an actionProcessing decorator.

• Define the type of action and associate it with a REST request and map the data used in the additional processing to the data that exists in the REST query.

Current Implementation: The request/action are associated and configured in the [Server Request Actions Maintenance](Server-Request-Actions(Server Request Maintenance)) screen.

1. Action - This is the action that will be performed such as database update, logging, email notification, debugging call. Processing for each action is done by a mixture of fixed coding and JSON configuration data that provides the specifics of the data that is processed.
2. Pre / Post Processing - When the processing will take place; before the REST call, after the REST call, or both.
3. URL - The request url supporting regex wildcards. For each call to the actionProcessing method (based on @actionProcessing decorator) the url being called is checked for a match as defined in the urlactions table. This information is cached so the first call will execute the query and cached information will be returned in subsequent calls.
4. Methods - The specific method calls that should be processed for the URL or NULL for all requests.
5. Action Data - The JSON specification of the event specific data. This allows the mapping of data from the server request to the data used in the action processing.
6. Template - The template provides the text to be populated with data and used during the processing.

Current Implementation: Text sent during a notification using {{}} to specify data elements that will be replaced.

• table - apptables.id for the table that is being queried
• action - 'add'
• columns - array of objects with 'id', 'type', 'attribute' attributes
  • id - appcolumns.id for the data element
  • type - where in the request data object that the data can be found; 'data', 'state', 'request'
  • attribute - data element name

Example:

{
    "table": 121,
    "action": "add",
    "columns": [
        {
            "id": 485,
            "type": "data",
            "attribute": "id"
        },
        {
            "id": 486,
            "type": "state",
            "attribute": "stateinid"
        },
        {
            "id": 487,
            "type": "state",
            "attribute": "stateoutid"
        },
        {
            "id": 490,
            "type": "request",
            "attribute": "details"
        }
    ]
}

The email action data provides a map of columns that will be returned in a query and then used in the email template.

• table - apptables.id for the table that is being queried
• columns - array of objects with 'id', 'type', 'attribute' attributes
  • id - appcolumns.id for the data element
  • type - where in the request data object that the data can be found; 'data', 'state', 'request'
  • attribute - data element name

{
  "table": 122,
  "columns": [
    {
      "id": 485,
      "type": "data",
      "attribute": "id"
    },
    {
      "id": 489,
      "type": "data",
      "attribute": "updatedat"
    },
    {
      "id": 481,
      "type": "request",
      "attribute": "statetransitionid"
    },
    {
      "id": -1,
      "type": "state",
      "attribute": "name"
    },
    {
      "id": -1,
      "type": "state",
      "attribute": "action"
    },
    {
      "id": -1,
      "type": "data",
      "attribute": "subject"
    },
    {
      "id": -1,
      "type": "data",
      "attribute": "issuetype"
    },
    {
      "id": -1,
      "type": "data",
      "attribute": "activity"
    },
    {
      "id": -1,
      "type": "data",
      "attribute": "status"
    },
    {
      "id": -1,
      "type": "data",
      "attribute": "priority"
    },
    {
      "id": 490,
      "type": "request",
      "attribute": "details"
    }
  ]
}

All,

Subject: {{subject}}

Updated: {{updatedat}}
State: {{name}}
Action: {{action}}
Activity: {{activity}}
Status: {{status}}
Priority: {{priority}}
Details: {{details}}

Thank you.
{{username}}
{{user.email}}
{{user.phone}}

Currently only appformController requests support actionProcessing extensions. The add and update processing extends the data available for post processing by doing the following:

1. Returns an extended query using the procedure formRecordFindById which returns the record and data from referenced lookup tables.
2. Captures state processing requests that are done when updating an 'issue' table. The add call queries the workflow_states table to get the initial state information and the update call queries the workflow_statetransisions to get the current state information.
3. Captures the initial request form data (key,value,fieldid) and makes it part of the data returned.