Plugins

Plugins are places in Socotra where system behavior can be customized with user-created scripts written in Javascript.

Note

See the Scripts API topic for information about deploying scripts and retrieving logs from scripts.

The following plugins are currently available:

• Rating

• Payment Schedules

• Proration

• Underwriting

Script Format

Each plugin is implemented in a javascript file with a predefined name. A data object with a predefined format is passed to a function, again with a predefined name, and the response is sent back using the javascript return statement. For example, a simple implementation for the underwriting decision plugin can look like this:

// in underwriter.js
function getUnderwritingResult(data)
{
  console.log("Hello underwriting world!");

  return {
    "decision": "accept",
    "notes": [ "Everyone wins!" ]
  };
}
exports.getUnderwritingResult = getUnderwritingResult;

In this example, the file is underwriter.js, the function name is getUnderwritingResult, and the return object has a decision string property and a notes string array property. The exports statement at the end is required.

Script Data

Each plugin is passed a data object with information specific to that plugin. See the feature guide for the specific plugin for information about the structure of the data object.

Note

To ensure full precision in passed data, numeric values in the data object are passed as strings. You can use the javascript parseInt or parseFloat functions to convert these values to standard javascript numeric values as needed.

Table Lookups

To lookup information in a table, use the function:

socotraApi.tableLookup(configVersion, tableName, key)

The table referenced by the tableName paramater must have two columns named key and value. The value returned will be a string but can be converted to other javascript types as desired.

Note

Tables are versioned with the Product Versioning feature. The config version for a given policy can be found in the Policy2Response object. To use the latest version of the table, pass the value 0 for configVersion.

Script Deployment

Scripts may be uploaded in either of two ways:

• Embedded in a configuration deployment. There will be top-level folder in the configuration zip file called /scripts which will contain folders and javascript files below.

• Uploaded directly to the scripts deployment endpoint with a zip file in multipart form format. With this endpoint, include the structure below what would have gone in the configuration /scripts folder.

Script Enablement

By default scripts are disabled. To enable them, include a ProductScriptingConfig block in your /products/{productName}/policy.json configuration file. For example, the following block will enable the underwriting and proration plugins, other plugins will be disabled:

{
  "plugins": {
    "getPerilRates": {
      "path": "master/rater.js",
      "enabled": true
    },
    "getProrationResult":
    {
      "path": "master/my_proration_plugin.js",
      "enabled": true
    },
    "createInstallments":
    {
      "path": "master/installments.js",
      "enabled": false
    },
    "getUnderwritingResult":
    {
      "path": "master/underwriter.js",
      "enabled": true
    }
  }
}

The path, relative to the scripts folder in the configuration, is set with the path parameter for each plugin type. For example, the rater.js file would be located in the folder /scripts/master.

Logging

In a javascript plugin script, the javascript method console.log can be used to log messages which can be retrieved later.

To retrieve logs, first call the scripts log query endpoint (with a QueryRequest object to filter based on desired values) to retrieve a list of top-level QueryResponseLineItem objects (there will be one per plugin call).

Then, using the specific LogEvent of interest, retrieve individual log messages by calling the scripts logging endpoint again by setting the requestId property of the QueryRequest object.

Note

Top-level logs are generated by Socotra and aren’t based on console.log events in plugin scripts. The format and contents of the message properties of those events is subject to change. Don’t base integration code or automated processes on the structure or contents of those messages.