Client Application Features

To load or create a micro analytic module, the client application posts a module, with a request body that contains the DS2 source code, to the module’s resource collection.

The DS2 source code is represented as a source code representation that compiles into one DS2 package. The package is represented as a micro analytic module with multiple methods that are represented as steps in the REST API. Therefore, a module might contain multiple steps. These modules and steps are stored in memory. The response body that is returned contains a module resource for the module.

The client application references a step directly by using an ID of the module generated by the REST server. This ID is referred to as the module ID, and the name of the step (compiled DS2 method) is referred to as the step ID.

Before executing the step, the client application performs a GET method on the step to retrieve these signatures:

The client application posts to the step's validations resource, along with a request body that contains the input values that are required to execute the step (compiled DS2 method).

When the POST is received, the input values are validated against the input signature of the step. A validation error is reported to the client as a response body that contains the validation results. This allows the client to validate its input before execution.

The service supports a synchronous way to execute a step (compiled DS2 method). In this case, the client application posts to the step resource, along with a request body that contains the input values that are required to execute the step (compiled DS2 method).

The client application creates a new revision of a module through its module ID.

The client application deletes a module through its module ID.

Payload logging enables you to capture the JSON payload, for both input and output, and log it to a file, so that it can be harvested and analyzed.

The data is captured in text files. The files are managed using log4j and can be configured to roll over daily or when the file reaches a particular size. The files are created in the same location as the system log file. The name of the file is SASMicroAnalyticServiceMessages<version_number>.log. Every node in the cluster produces its own file. It is possible to change the location by modifying the log4j configuration ID. It is recommended that the file be local to the cluster node, to minimize impact on system performance.

For every invocation of the REST service, a single line that contains the timestamp is logged. The timestamp is followed by a payload JSON object that contains both the request and the response representations. The timestamp is a fixed size. The payload object is not.

Payload logging can be turned on by defining the system property sas.mas.message.audit and setting its value to TRACE. This change can be made in the wrapper.conf file (Windows) or setenv.sh (UNIX) as shown below: