Object Model

DataScripts are attached to virtual services. Each DataScript will execute when an event is triggered, such as when the virtual service receives an HTTP request or HTTP response. Each DataScript object includes at least one and potentially more events.

A virtual service may have multiple DataScripts attached. If multiple DataScripts use the same events, such as HTTP requests, then the order of the DataScripts assigned to the virtual service will be considered for the order of processing of the DataScripts. For instance, if the first DataScript is set to discard all client requests to the /secure directory, and the second DataScript is set to redirect all authenticated clients making requests for the /secure directory to a different path, the second DataScript will never be executed.

The supported events are:

Event	Description
HTTP_REQ	This event triggers when the request line and all the headers of the HTTP request have been parsed successfully, but before any potential POST body has been received.
HTTP_RESP	This event triggers when the response status line and all headers of the HTTP response have been parsed successfully, but before the response body has been received.
RESP_FAILED	This event triggers when any error/timeout happens before a valid response header can be received from the server and forwarded to the client. There are only 3 HTTP functions which can be invoked from the RESP_FAILED event: avi.http.response() avi.http.redirect() avi.http.internal_status() All other HTTP functions return errors, and the client connection will end prematurely. Examples under which the RESP_FAILED event occurs include: TCP/SSL connection or handshake to the back-end server fails. Request proxy to the back-end server times out. No response, partial response, or bad response headers from the server. The server resets the connection while NSX Advanced Load Balancer is waiting for the back-end server to respond.
LB_DONE	This event triggers once the server selection is done, but before establishing the connection to the back-end server. This event enables the configuration of various policies once the server selection is done. The following are the DataScripts APIs supported for this event: avi.vs.log() avi.http.response() avi.http.add_header avi.http.remove_header( name ) avi.http.replace_header( name, value ) avi.http.get_header( [[name] [context]] )

This object model allows the flexibility to create a library of DataScripts. A virtual service can be configured to refer to any DataScript object from this library, provided it belongs to the same protocol as the DataScript’s events. To use a DataScript with an HTTP request event, the virtual service must be configured for application type HTTP.

Each virtual service object can refer to any number of DataScripts. All DataScripts are parsed during configuration time. Hence, any incorrect DataScript will result in a failure when the user attempts to save the new or modified DataScript. The configuration time error is reported as an aid in debugging.

When a DataScript execution encounters a failure, the script execution ends prematurely for that HTTP request or response. An HTTP Internal Server Error is sent to the client, and a client log is generated with the stack trace of the prematurely ended script to aid in debugging.