Skip to content

Commit

Permalink
Merge branch 'master' into AAV/NLIC-2442-warning-level
Browse files Browse the repository at this point in the history
  • Loading branch information
r-brown authored Jul 17, 2024
2 parents f8e4cf7 + 01baf54 commit 4304181
Show file tree
Hide file tree
Showing 3 changed files with 270 additions and 0 deletions.
Binary file added docs/assets/images/notifications.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
20 changes: 20 additions & 0 deletions docs/licensing-models/subscription.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,26 @@ Required additional properties specific to the TIMEVOLUME [licenses](object-mode
- `Integer` **`timeVolume`** - specifies the licensed time period in days. Normally it is copied from the corresponding license template, but can be changed later for each license individually.
- [`Timestamp`](restful-api#data-types) **`startDate`** - specifies a date at which the validity period of the license begins.

Grace Period
------------

By offering the Grace Period option, you can provide flexibility to your customers and ensure a smoother transition in subscription renewals.

Grace Period option under the Subscription Licensing Model allows you to provide a specific time frame during which your end-users can continue to use your software, even if their subscription has expired. It can be useful in situations where users need additional time to renew their subscription or when a temporary interruption in subscription payment has occurred.

To enable the Grace Period option for Subscription licensing model in NetLicensing, follow these steps:

- Sign in to your NetLicensing account
- Go to the Products section and select the product you want to enable the Grace Period for
- Select Product Module configured by the Subscription Licensing Model
- Scroll down to the Packages section
- Enable "Grace Period" option
- Save your changes

Once the Grace Period option is enabled, the end-users can continue to use your software during the specified Grace Period, even if their subscription has expired.

It's important to note that during the Grace Period, end-users are expected to renew their subscription to maintain access to the software features beyond the Grace Period.

Validation
----------

Expand Down
250 changes: 250 additions & 0 deletions docs/notifications.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,250 @@
---
layout: default
title: Notifications
nav_order: 92
description: "Automate your licensing workflows and streamline your business processes with NetLicensing webhook notifications"
permalink: notifications
---

Notifications
=============

NetLicensing offers a Notifications feature that allows you to receive real-time notifications for specific events related to your vendor account. These notifications provide timely updates and alerts regarding the activities and statuses of your licenses and customers.

With the Notifications feature, you can set up endpoints to receive notifications for events such as:
- Creation of a new customer
- Issuance of a license
- Change in a customer’s warning level

These notifications are sent via HTTP POST requests to the specified endpoint URL, allowing you to integrate them into your systems or applications for further processing.

By leveraging the Notifications feature, you can automate your licensing workflows and streamline your business processes. You can use the notifications to trigger actions like sending automated emails to customers, updating internal databases or CRM systems, or generating reports based on events occurring within your licensing environment.

Setup
-----

Manage your NetLicensing Notifications from the *"Settings / Notifications"* section. Here, you can view, deactivate, delete, and create notifications.

### Creating a New Notification

1. Click on "Add Notification" to start the creation process
2. In the "Create Notification" view, fill in the required attributes
3. Click "Create" to create notification

<a href="assets/images/notifications.png" class="imagelink" data-lightbox="notifications" data-title="Notifications" data-alt="Notifications">
<img src="assets/images/notifications.png" />
</a>

### Notification Attributes

- **Name**: The name of the notification.
- **Number**: A unique notification number. If left empty, a number will be generated automatically.
- **Events**: One or more events that will trigger the notification. Options include:
- **Create Customer**: Triggered when a new customer is created.
- **Create License**: Triggered when a new license is created.
- **Change Warning Level**: Triggered on customer's [warning level](warning-level) changes (e.g., from `GREEN` to `YELLOW` or `YELLOW` to `RED`).
- **Type**: The type of notification. Currently, only `WEBHOOK` is supported.
- **Endpoint**: The URL where an HTTP POST request with the specified payload will be sent. **Note:** The endpoint must use the secured HTTPS protocol with a public SSL/TLS certificate.
- **Payload**: The specific payload for the event can be defined here.

Payload Structure
-----------------

Notification payload can be configured to include specific data related to the event that triggered the notification. The payload is sent as a JSON object in the body of the HTTP POST request to the specified endpoint URL. The structure of the payload depends on the event type and the data associated with the event.

The standard payload structure includes the following fields:

- **Event**: `${event}` - full event object
- **Data**: `${event.data}` - event-specific data
- **Name**: `${event.name}` - event name; can be one of the following: `LICENSEE_CREATED`, `LICENSE_CREATED`, `WARNING_LEVEL_CHANGED`
- **Timestamp**: `${event.timestamp}` - timestamp of the event

Below are examples of the payload structure (`event.data` element) for different events:

<div>LICENSEE_CREATED</div>
{: .code-example .ml-5 .code-header }
```json
{
...
"items": {
"item": [
{
"property": [
{
"value": "IADGNSGZG",
"name": "number"
},
{
"value": "true",
"name": "active"
},
{
"value": "PQMW7JWWN",
"name": "productNumber"
},
{
"value": "Customer 04",
"name": "name"
},
{
"value": "{\"RED\":[],\"YELLOW\":[],\"GREEN\":[]}",
"name": "warningLevel"
},
...
],
"type": "Licensee"
},
{
"property": [
{
"value": "PQMW7JWWN",
"name": "number"
},
{
"value": "true",
"name": "active"
},
{
"value": "Pricing Table demo product",
"name": "name"
},
...
],
...
"type": "Product"
}
],
...
},
...
}
```
{: .ml-5 }


<div>LICENSE_CREATED</div>
{: .code-example .ml-5 .code-header }
```json
{
...
"items": {
"item": [
{
"property": [
{
"value": "L76HEM5M6",
"name": "number"
},
{
"value": "true",
"name": "active"
},
{
"value": "License 01",
"name": "name"
},
{
"value": "IADGNSGZG",
"name": "licenseeNumber"
},
{
"value": "E9FSDF2RX",
"name": "licenseTemplateNumber"
},
...
],
"list": [],
"type": "License"
}
],
...
},
...
}
```
{: .ml-5 }


<div>WARNING_LEVEL_CHANGED</div>
{: .code-example .ml-5 .code-header }
```json
{
...
"items": {
"item": [
{
"property": [
{
"value": "N123456",
"name": "number"
},
{
"value": "true",
"name": "active"
},
{
"value": "P5URES4FZ",
"name": "productNumber"
},
{
"value": "Customer 04",
"name": "name"
},
{
"value": "{\"RED\":[],\"YELLOW\":[],\"GREEN\":[\"MQWTGNYMI\",\"MT2VNWASP\"]}",
"name": "warningLevel"
}
...
],
"list": [],
"type": "Licensee"
},
{
"property": [
{
"value": "true",
"name": "valid"
},
{
"value": "Features",
"name": "productModuleName"
},
{
"value": "GREEN",
"name": "warningLevel"
},
{
"value": "MultiFeature",
"name": "licensingModel"
},
{
"value": "MT2VNWASP",
"name": "productModuleNumber"
}
],
...
"type": "ProductModuleValidation"
}
],
...
}
}
```
{: .ml-5 }

Considerations and Best Practices for Receiving Notifications
-------------------------------------------------------------

When building an application to receive notifications, consider the following factors:

1. **Reliability**: Notification delivery is not always guaranteed due to factors such as network issues, server errors, or application downtime. Implement retry mechanisms and idempotency to handle missed or duplicate notifications.

2. **Security**: Ensure secure connections using encryption protocols, such as TLS, to protect the integrity and confidentiality of the data transmitted via notifications. Validate the source of the notifications by checking signatures or using secret keys.

3. **Scalability**: Design your notifications receiver to handle varying loads. Use asynchronous processing to manage high volumes of incoming notifications efficiently.

4. **Logging and Monitoring**: Implement comprehensive logging and monitoring to track notifications deliveries and failures. This helps in diagnosing issues and improving the reliability of your notification handling.

5. **Validation**: Validate incoming notification data to ensure it adheres to the expected format and contains all necessary information. This helps prevent the processing of invalid or malicious data.

6. **Versioning**: Plan for versioning of your notifications endpoint(-s) to accommodate future changes without disrupting existing integrations. Ensure backward compatibility whenever possible.

0 comments on commit 4304181

Please sign in to comment.