Navigation :

N2SVCD Integration

The N2VS backend requires integration with other N2SVCD applications to operate fully.

Each of the following sections covers the required configuration to enable a particular function of the N2VS. All required functions for your specific deployment should be configured.

For all details of how to configure each N2SVCD application, refer to that application’s specific documentation.

Inbound Request Handling

All voucher server backend request are handled by the receipt and processing of a HTTP request with a JSON payload. To enable HTTP requests in the backend, a REST server must be configured.

<application name="N2VS-REST-API" module="RestServerApp" admin_alloc="1m" user_alloc="64m" overloaded_poll_ms="60000" overloaded_active_ms="60000">
    <!-- parameters as the deployment requires -->
    <config>
        <handlers>
            <handler method="POST" application="N2VS-SERVICE-LOGIC"/>
            <handler method="DELETE" application="N2VS-SERVICE-LOGIC"/>
            <handler method="GET" application="N2VS-SERVICE-LOGIC"/>
            <handler method="PUT" application="N2VS-SERVICE-LOGIC"/>
        </handlers>
    </config>
</application>

The RestServerApp when configured must be configured to pass all requests to the N2VS Lua service logic. In the above example this is the LogicApp with the name N2VS-SERVICE-LOGIC.

Database Connectivity

SMS Database

The N2VS SMS database is a PostgeSQL based database which is used by the backend. Access is via the N2SVCD DBApp:

<application name="DB-SMF" module="DBApp" admin_alloc="1m" user_alloc="64m" overloaded_poll_ms="60000" overloaded_active_ms="60000">
    <!-- parameters as the deployment requires -->
</application>

Configuration of this DBApp in the N2VS LogicApp is via the name smf - i.e. db_app_name_smf:

<application name="N2VS-SERVICE-LOGIC" module="LogicApp" admin_alloc="1m" user_alloc="64m" overloaded_poll_ms="60000" overloaded_active_ms="60000">
    <parameters>
        <parameter name="db_app_name_smf" value="DB-SMF"/>
        <!-- more parameters -->
    </parameters>
</application>

Voucher Database

The N2VS Voucher database is a MongoDB based document database which is used by the backend. Access is via the N2SVCD DBApp:

<application name="DB-VOUCHER" module="DBApp" admin_alloc="1m" user_alloc="64m" overloaded_poll_ms="60000" overloaded_active_ms="60000">
    <!-- parameters as the deployment requires -->
</application>

Configuration of this DBApp in the N2VS LogicApp is via the name voucher - i.e. db_app_name_voucher:

<application name="N2VS-SERVICE-LOGIC" module="LogicApp" admin_alloc="1m" user_alloc="64m" overloaded_poll_ms="60000" overloaded_active_ms="60000">
    <parameters>
        <parameter name="db_app_name_voucher" value="DB-VOUCHER"/>
        <!-- more parameters -->
    </parameters>
</application>

Database Timeouts

The backend voucher system generates vouchers in partial batches, which can take several seconds to perform if the MongoDB voucher database is not scaled for heavy writes. To manage bulk voucher processing, database timeouts are increased in the default configuration.

In the default configuration for the N2VS LogicApp connection to databases, the timeout is set to 60s:

        <agent module="DBApp::DBLuaAgent" libs="../apps/db/lib">
            <config>
                <db_timeout_ms>60000</db_timeout_ms>
            </config>
        </agent>

For each of the N2SVCD DBApp configurations, the default expiry timeouts are configured to be 60s too:

        <parameter name="db_request_expiry_ms" value="60000"/>
        <parameter name="action_timeout_ms" value="60000"/>

Additionally, each of the N2SVCD polling timeouts is also increased:

<application ... overloaded_poll_ms="60000" overloaded_active_ms="60000">

This mitigates watchdog polling checks in cases where larger voucher batches are generated and the voucher service becomes (relatively) loaded during the generation of many thousands of vouchers.

OCS Connectivity

OCS connectivity for the “Redeem” voucher action is likely to require a RestClientApp for HTTP communication with the OCS. In cases where another protocol is used (e.g. Diameter) refer to N2SVCD and the OCS integration plugin for the N2VS for more specific information.

Where a HTTP REST Client is used for OCS connectivity, configure the RestClientApp:

<application name="OCS-REST-Client" module="RestClientApp" admin_alloc="1m" user_alloc="64m">
    <!-- parameters as the deployment requires -->
</application>

and in the N2VS LogicApp configuration, configure the reference to the client app:

<application name="N2VS-SERVICE-LOGIC" module="LogicApp" admin_alloc="1m" user_alloc="64m" overloaded_poll_ms="60000" overloaded_active_ms="60000">
  <parameters>
        <parameter name="rest_app_name_ocs" value="OCS-REST-Client"/>
        <!-- more parameters -->
    </parameters>
</application>

Note that the name (ocs in this case, as part of rest_app_name_ocs) will be dependent on the OCS integration plugin configured for use by the N2VS installation. It may be named something else.

In addition to the parameter, ensure the relevant agent is also included in the agents section of the N2VS LogicApp:

<agents>
    <agent module="RestClientApp::RestLuaAgent" libs="../apps/rest_c/lib"/>
    <!-- other agents required by the N2VS -->
</agents>

The Voucher Server Backend API

The voucher server backend API is intrinsically linked to the configuration of the N2VS LogicApp instance run by N2SVCD. The API endpoints are defined using the <triggers> configuration of the logic app:

<triggers>
    <trigger method="get" path="/api/ping" script_key="ping"/>
    <trigger method="get" path="/api/voucher_generation_functions" script_key="voucher_generation_functions"/>
    <!-- other triggers not shown. -->
</triggers>

The voucher API URL endpoints supported by the voucher server can be adjusted (e.g. by changing the URL) if specific requirements exist for a N2VS deployment. However, as both the frontend API and the queue-processor use these API endpoints, changing them will require the deployment of multiple LogicApp instances to handle both internal N2VS and external BSS communication requests.