Actions (FT-1013.034)

About this document

Scope

This document provides background information as well as a functional description of the FT-1013.034 Actions standard feature. The described feature is supported from the release version 4.0 onwards.

Note

Actions is a standard feature and does not require a special license.

This feature is part of the Automation functionality with number FN-1013.

Feature Availability

Feature overview

Goals

The aim of the Actions feature is to allow to create and manage Actions (i.e., CMP operations that can be triggered once a Rule condition is met) as a part of the CMP's extensive automation framework.

Functionality of the feature

Basic Concepts of Automation Rules

CMP provides an extensive automation framework that is based on three basic elements: Triggers, Rule Filters, and Actions.

Triggers/Rules

Rules define events that - when the event condition is fulfilled - automatically trigger one or many Actions. Event conditions can be related to the following two CMP objects and the Rule Type explicitly determines the object that is linked to the related event condition:

• SIM Cards (~ SIM Rules), and

• SIM Pools (~ Pool Rules).

Rule Filters

Rule Filters represent specific filter criteria that allow to limit the set of CMP objects that the event condition shall be evaluated on.

Actions

Actions represent CMP operations that can be triggered once a Rule condition is met. A Rule can have one or many Actions assigned, and if a Trigger condition is met, all of the assigned Actions will be executed in the order given by the sequence numbers (in ascending order) set during the assignment process.

The following Action categories are available:

• Notifications

  • Notification via email or SMS (Action Type: “Notification“)

  • Email notification for specific user groups (Action Type: “Account Notification“)

• API Requests

  • Allows any REST API call as Action (Action Type: ”REST API Request”)

  • Allows to specify a static URL to which the message should be sent when a Rule is triggered (Action Type: “XML Push API”)

• SIM Card Operations

  • Real-time deactivation/suspension of specific connectivity services (Action Type: “Service Blocked for Rule Period“)

  • Changes to the following properties of a SIM Card:

    • Billing Status (Action Type: “Change SIM Billing Status“)

    • Network Status (Action Type: “Change SIM Network Status“)

    • Active Price Plan (Action Type: “Change SIM Price Plan“)

    • Service Profile (Action Type: “Change SIM Service Profile“)

    • APN Group (Action Type: “Change SIM APN Group“)

Actions are defined independently from the Rule definitions which allows users to define the basic behavior of the Action only once and reuse the settings for multiple different Trigger Types. Additional Action parameters that are available when assigning an Action to a Rule make it possible to complement the given basic behavior of the Action by a specific one in the context of the Rule:

• Action Repetition Type (ONCE or ALWAYS) determines how often one Action is triggered within a given period (Billing Cycle or 24 hours).

• Execution Type (Permanent or Temporary) determines if the change performed by the Action triggered shall be a permanent one or needs to be rolled back after a period of time.

• Action Schedule determines when the Action will be executed.

Apparently not all additional parameters - respectively, not all described values - make sense in combination with some Action and/or Rule Types. For further explanations on supported parameters in which combinations and corresponding restrictions please see the chapter Assigning Actions to Rule Triggers below.

Action Repetition Type

The Action Repetition Type parameter allows specifying how often an Action will be triggered within a specific period whenever the Rule event or condition is detected by CMP. The default period for this parameter is the current Billing Cycle unless the Rule Type indicates a Rule Period of 24 hours, e.g. Rule Type “Data Usage - 24hrs“.

This parameter has two available values:

• ALWAYS: The assigned Action is executed every time the Rule condition is met.

• ONCE: The assigned Action is only triggered once for a SIM Card with the first occurrence in the given period, and every subsequent occurrence of the Trigger event will be ignored until the end of the period.

The Action Repetition Type parameter allows to control if e.g. a notification is sent always for a SIM Billing Status change event or only once for the first change in the Billing Cycle.

Note that the repetition behavior of the Action is validated for each SIM separately.

Execution Type

The Execution Type parameter defines if the assigned Action should be a permanent one or needs to be rolled back at the end of the Billing Cycle.

This parameter has two available values:

• Permanent

• Temporary (BC-ONLY)

Currently, CMP provides the functionality to set the Execution Type only when assigning Actions to Rule Trigger of the following Action Types:

• Change SIM Price Plan: The Temporary option is only available for Actions with target Postpaid Price Plans, otherwise, the Execution Type will be set automatically to Permanent.

• Change SIM Billing Status: In order to support the temporary suspension of SIM Cards the Temporary option is only available if the target Billing Status is Suspended, otherwise, the Execution Type will be set automatically to Permanent.

Action Schedule

The Action Schedule parameter defines when the assigned Action should be executed after the Rule is triggered.

• Immediate: Action is executed immediately after the Rule was triggered.

• Next Billing Cycle: Action is scheduled beginning of the next BC.

• Days from Trigger: Action is scheduled nx24 hours after the Rule was triggered, where n is the User input number of days.

• Hours from Trigger: Action is scheduled n hours after the Rule was triggered, where n is the User input number of hours.

Basic Flow for defining Automation Rules

The following diagram displays the basic sequence of steps to define an Automation Rule.

Assigning Actions to Rule Triggers

In CMP there are three general principles related to the assignment of Actions to Rule Triggers.

1. (AP1) Actions of each Action Type can be used with each Trigger Type.

2. (AP2) An Action behaves always in the same way regardless of the Rule Type that triggered the Action.

   • Note that there is one exception to these two principles, the Action Type “Service Blocked for Rule Period“ which can only be used with a limited number of Rule Types and adapts its behavior specifically to the SIM that triggered the Action. For further details see chapter Action Type “Service Blocked for Rule Period” below.

3. (AP3) Each Action is always executed in relation to the SIM that triggered the Action.

For Pool related Rules there are some specific definitions, determining which SIMs (belonging to the respective Pool) are affected by the Action triggered. Please refer to chapter Assigning Actions to Pool related Triggers for further explanations.

Action Type “Service Blocked for Rule Period”

The main purpose of the “Service Blocked for Rule Period” Action Type is to provide an immediate (near real-time), reliable and target-oriented way of blocking connectivity services to avoid fraud and unwanted over-usage situations. In order to meet these requirements, the execution of this Action Type is implemented as close as possible to the corresponding online service interfaces (Gy, Ro) provided by the underlying network infrastructure, which results in the following consequences.

• Combining service related Trigger Types (e.g. Voice Usage in Zone) with a Service Blocked Action wouldn’t meet the speed requirement if the related usage information is not provided in almost real-time. For that reason, CMP will not allow to assign a Service Blocked Action to a Trigger Type for offline services.

• Some Trigger Types require more execution time due to the longer evaluation time caused by the evaluation complexity (e.g. Pool related Triggers), while others are service independent (e.g. SIM Custom Attribute Changed).

Due to the above-mentioned reasons, Actions from Type “Service Blocked for Rule Period“ do NOT follow the AP1 principle described earlier in this document. The following diagram displays the supported combinations of Rule Types and “Service Blocked for Rule Period” Action, assuming that the related services are online Services.

In order to allow specific (target-oriented) blocking of services, the Service Blocked Action behaves differently depending on the Rule Type that triggered it. This means that the “Service Blocked for Rule Period” Action is NOT Rule agnostic (as described in AP2 principle earlier), instead, it delivers enhanced functionality that translates the Trigger Type information into corresponding Action behavior as follows:

• A - Service that is monitored in the Trigger, i.e. the service that is blocked by the Action (e.g. data, SMS MO).

• B - In case the Rule Trigger provides further traffic filtering e.g. for Zone or Country, the service is blocked only for traffic happening in the related Zone or Country (if applicable).

• C - Rule Period (Billing Cycle or 24 hours) for how long the Rule Trigger is evaluated, i.e. the period how long the Service Blocked Action is active (either until the end of the Billing Cycle or the end of the current 24 hours).

The following diagram provides an example of how the information of the Rule Trigger translates into the corresponding behavior of the Service Block Action:

• Given Trigger Type: “SMS MO Usage in Zone- Billing Cycle“ (threshold trigger)

• Any Service Blocked Action triggered by such a Rule will immediately block SMS MO service (A), but only in the corresponding Zone (B), until the end of the Billing Cycle (C).

Detailed Flow for defining Automation Rules

The following diagram summarizes the steps of Automation Rules setup that have been described throughout this document.