Home > Aria Crescendo Documentation > Event Notification Best Practices

Event Notification Best Practices

Overview

Event notifications (also known as event driven provisioning) are the means by which Aria interacts with your service delivery system(s), informing you of any creation or modification of accounts and other elements of your Aria instance based on the events to which you have subscribed. 

You can subscribe to events, organized into six (6) Event Classes, about which you want to receive notifications. You can also specify destinations to which event notifications should be sent, such as server addresses or email addresses.

Aria sends a notification almost as soon as your specified event occurs. You can configure Aria to send event notifications in the following formats:

  • Account Data via Email (Multi-byte haracters supported)
  • Account Data via HTTP (Name Value Pairs)
  • Account Data via HTTP (XML Document)
  • Account Data via Secure HTTP (Name Value Pairs)
  • Account Data via Secure HTTP (XML Document)
  • Account Resource Sync
  • Simplified Account Data via Email (Multi-byte characters supported)
  • Simplified Account Data via Secure HTTP (Name Value Pairs)
  • Simplified Account Data via Secure HTTP (XML Document)
  • Simplified Account Data via Secure SFDC O-AUTH (Name Value Pairs)
  • Simplified Account Data via Secure SFDC O-AUTH (XML Document)

For XML-formatted data, Aria provides XSD (XML Schema Definition) files for each Event Class that describe the structure of the data payload, allowing you to validate the data. You can download the XSD files for each event class on the pages linked to in the table below.

Note: Performance of Aria Event Notifications depends on the volume of transactions currently being processed.

Event Class Categorization

Aria events are classified based on the types of activity that occur on your Aria client instance. Click the Event Class title to see a list of events in that class.

Event Class Number

Event Class

Description

7

Events associated with the creation and modification of accounts and master plan instance records and their related data elements.

8

Events associated with the creation and modification of orders for inventory items.

9

Events associated with the creation of financial transactions on accounts and master plan instances.

10

Events associated with the preparation and transmission of email messages to account holders, billing contacts, statement contacts, etc.

11 Usage Monitoring Events associated with usage on master plan instances.
12  Product Events associated with changes to plans and services. 

Event Notification Versioning

Event notification is versioned for each event group. Based on your business needs, you can use different versions of event notification for different event groups.

The table below lists the available versions of event notification for each event group:

Event Class Number Event Class Version(s) Available

7

Accounts and Master Plan Instances

1, 2, 3, 3.2

8

Orders

1

9

Financial Transactions

1

10

Account Notifications

1

11

Usage Monitoring

1

12

Product 1


Each version of event notification provides a different set of events and requires the applicable XSD and DTD files for that version.

You must use the correct version of the XSD and DTD files if you want to validate the data in your event notifications sent to you as XML documents. Please contact Aria Systems Customer Support if you need access to any future new versions of event notification for a particular event group.

Prerequisites

To use event notifications, you must first take these actions, described in detail in Event Notification Prerequisites:

  • accept the Aria IP address range;
  • configure your provisioning settings;
  • set up XSD schema files;
  • set up VIE (Virtual Inventory Engine) for virtual inventory;
  • enable XML statements.

Best Practices

The recommended practices to follow to enhance your event notification workflow are described below:

Performance

  • Subscribe only to events that you need to be informed of. If you subscribe to a large number of events that you don’t require, that may slow down your Aria implementation.
  • You can set up an unlimited number of destinations (endpoints) for your notifications. All notifications within an event class you subscribed to go to all destinations within that class. You may want to consider whether all of the destinations are necessary since a large number of destinations may slow down your Aria implementation.
  • Decide whether an event notification is actually needed immediately based on the actions you need to take based on the notification. You may want to consider getting an extract of your chosen Aria data instead of using event notifications, then taking action based on the data.

    Example: You can wait for invoices to be generated then extract invoice data for import into your financial system.
     
  • If you specify that Aria should make more than one attempt to send an event notification:
    • Set the delay between attempts to at least 300 seconds. This allows enough time for Aria to attempt another transmission and for your server to send back a response.
    • It is highly recommended that you set the delay between attempts to 900 seconds and specify 9 attempts. This will give you around 2 hours to resolve any issues with your system that may be preventing you from receiving event notifications.

Security

  • The SMTP (email) and HTTP methods are not secure and are therefore not recommended methods for transmitting event notifications.
  • Secure HTTP is the recommended method for transmitting event notifications.
  • Send your event notification data to only trusted parties. Sending data to third parties may compromise the privacy of your customers’ information.
  • Restrict access to the Event Notifications section in the Aria application to only authorized individuals.

Monitoring/Enhancement

  • In addition to using the event notification logs to monitor your event notifications, you can consider doing the following to ensure that your notifications are being sent as expected:
    • Add the Provisioning Events by Date report to your report catalog. You can then schedule that report using your chosen criteria.
    • Monitor the destination (examples: server or inbox) that you set up to receive notifications to make sure it is up and running.
    • Create alerts that will inform you if you have not received a notification from Aria over an expected period of time based on your typical account activity.
  • If you need to send a notification to different destinations depending on the content of the notification, Aria recommends that you:
    • set up 1 destination for that notification; and
    • configure Aria Workflow or your own custom application to:
      • optionally update or format the notification; then
      • redirect that notification from the destination to the applicable location or recipient.
  • Since you cannot add information to Aria's event notification data, you can use API calls to enhance the data.

    Examples:
    • if you subscribed to an invoice-related event, you can get the invoice details using an API;
    • if you subscribed to a plan change event, you can get the plan details using an API.

Process Overview 

After completing the Event Notification Prerequisites, perform these tasks to implement your event notification process:

 

Use Cases

Click on any of the links below to see instructions for working with a few key scenarios involving event notifications:

 

Note: A few common event notifications are provided above for demonstration purposes. Please click on the link in the Event Class column in the table above for a complete list of available event notifications that you can work with.

 


Subtopics

Aria Crescendo Developer’s Guide

Event Notification Process Overview

Enable Contract-related Event Notifications

Best Practices for Usage-related Event Notifications

Enable Usage-related Event Notifications

Last modified

Tags

Classifications

This page has no classifications.