PIPES - com.phenixidentity~phenix-pipes

Note

The purpose of PIPES module is to centralise all data access. The PIPES module handles all reads and writes to/from any datasource. In addition, data manipulation and validation is also a big part of PIPES.

Within the PIPES module one or more PIPES are configured. Each PIPE has a very specific purpose. Authenticating a user, fetch data from one or more datasources etc. Each PIPE consists of one or more VALVES. A VALVE is the functional building block which has one very small but well defined function. There are VALVES for every common CRUD operation and more. Over 100 different VALVE types are currently available.

Valves address data in RAM using the data model.

Configuration

Let's take a closer look on how data is represented. This will give a better understanding of how PIPES function.

{
    "id": "9a5987e4-5f85-48d6-b7c7-02defab38592", //A unique ID is required
    "description": "Just a description",
    "valves": [{  //A list of VALVES to be performed, top to bottom.
        "name": "InputParameterExistValidatorValve", //The name of the VALVE. This is name is used by the system as a key to find tha actual code delivering functionality 
        "config": { //Each VALVE has a configuration set specific to that particular VALVE. 
            "param_name": "password",
            "skip_if_expr": "request.authenticatedrequest === 'true'" //Possible execution rules
        }
    }, {
        "name": "LDAPSearchValve",
        "config": {
            "connection_ref": "3de8a6f2-223b-4afb-bb95-550cd8aa66c9",
            "base_dn": "o=nordicedge",
            "scope": "SUB",
            "size_limit": "0",
            "filter_template": "uid={{request.username}}", //To make execution dynamic data can be hardcoded or taken from the request by property expansion.
            "attributes": "uid,"
        }
    }, {
        "name": "LDAPBindValve",
        "config": {
            "connection_ref": "3de8a6f2-223b-4afb-bb95-550cd8aa66c9",
            "password_param_name": "password",
            "skip_if_expr": "request.authenticatedrequest === 'true'"
        }
    }],
    "created": "2016-08-12T12:22:23.787Z"
}

Response

Once the last VALVE has executed successfully the PIPES module responds to the requestor with a OK status and potentially additional data.

Pipe Status

Pipe status is a mechanism to monitor the state of a pipe and temporary disable it if it is detected as not OK,  so that it doesn't brake or block other parts of the system. Use this mechanism when single pipes in error affects the over all performance of Pipes by blocking.

Pipe status is controlled by the implementation, representing a strategy for how to recover a non OK pipe.

Available implementations

Recovery retry means that pipe recovery is done by calling (“letting calls through”)  after a number of calls or a period of time. If a retry call is successful, pipe is recovered.

• Default (“default”): No-op implementation. Always considers a pipe to be OK. This is the default behaviour and has the exact same behaviour as before pipe status was introduced.

• Basic recovery retry (“basic”): Keeps track of how many times a broken pipe has been called and for how long. Checks if pipe has recovered by letting calls through based on configurable counter and interval (whichever comes first). Works on pipe instance (ie not aware of cluster or multiple pipe instances, works best in a single server/single pipes configuration).

• Static recovery retry (“static”): Same as basic but keeps track of all pipe instances in a JVM. Requires some synchronization for thread safety that may impact performance.

Configuration

In the current version status is configured on a pipe. This mean you’ll have configure it on every pipe that should use it. This may change in the future.

Properties

Name	Description
pipe_status_impl	Name of pipe status implementation (see above)
recovery_retry_threshold	Number of times a non OK pipe should be blocked before trying to recover (default: 25).
recovery_retry_interval	Interval in seconds a non OK pipe should be blocked before trying to recover (default: 60)

Note

Properties are specific to the selected pipe status implementation, but static and basic are configured in the same way.

Example

{
    "id" : "pipe-id",
    "config" : {
        "pipe_status_impl" : "basic",
        "recovery_retry_threshold" : "5",
        “recovery_retry_interval”: “10”
    }
}

The above configuration will, if a pipe returns failure, skip the next 4 calls or wait 10 secs before allowing pipe to receive calls again. If that call is successful, pipe is OK and all calls will be processed as usual, otherwise the next 4 calls will be skipped or wait another 10 secs.

Tags

Valve