Page Comparison

{noprint}{float:right|width=300px|background=lightgrey|border=solid blue 2px|margin=10px|padding=8px}
*Contents*
{toc:all=true|depth=4|excerpt=true|indent=14px}
{float}{noprint}
*Change log:*
|| *Date:* || *Author:* || *Version:* || *Changes:* || Completed || *Ext.* || *Int.* || *Is in Core* || Jira Ref. ||
| {page-info:created-date|dateFormat=dd MMMM yyyy} | {page-info:created-user} | 0.1 | Doc. created | Yes/No | | x | N/A | N/A |
| 18 July 2013 | Luca Casarini | 0.2 | Doc. completed | Yes | | x | N/A | N/A |




h1. Overview


| *Name of report* | System Status Report |
| *Schedule* | Daily |
| *System* | Retail/Wholesale; Prepaid/Postpaid |
| *Customer role* | Informed, Responsible |
| *CDRator Operations role* | Informed, Responsible |
| *CDRator role* | Informed |


Description of the roles:
# Escalate - the recipient escalates to the Informed role if the content of the report becomes a concern.
# Informed - the recipient gathers information by the content of the report. No reaction is expected.
# Responsible - the recipient is expected to read the content of the report (or a part of it) and to take the necessary actions.

{note:title=Exclusive Report}
This report is available only to customers with a Managed Service Agreement.
{note}


h1. System Status Report

The System Status Report returns the status of several queues of the system and represents an overall system health check.

There are (usually) two sections of the report:

* Issues to be handled by customer \- This section normally includes provisioning errors and workflow activities waiting for user action. Depending on the system configuration and different agreements with the customer, other queues could be added to the list.


* Issues to be handled by CDRator \- CDRator Operations will fix all errors in report which are not included in first section of the report.


h2. Queues and fields

The report groups the queues as follows (depending on the system configuration, one or more of the points below could be missing):

* Workflows waiting for user action
* Provisioning errors
* Workflows activities in error
* Rate errors
* Alert pending in error
* Subscription fees in error
* Process monitor alerts

The total number of elements belonging to a group is reported in the header:

!rpt7.png|border=1!

For every element of the queue these are the fields:
* Activity - an extended description of the field.
* Total - the number of occurrences of that activity.
* Latest - the most recent date and time that activity happened.
* Oldest - the oldest date and time the activity happened.

Latest and Oldest follow a conditional formatting scheme:
* {color:#ff0000}{*}Red and bold{*}{color} \- if the timestamp is within the day the report is generated.
* {color:#ff9900}Orange{color} \- if the timestamp is from 1 to 10 days before the report is generated.
* Normal - if the timestamp is from more than 10 days before the report is generated.

h2. Brand

If relevant, the Brand is part of the report:

 !rpt15.png|border=1!

h1.


h1. Example

The top of the report:

!example-report-3.png|border=1!

{warning}
The customer are expected to check this part of the report on a daily basis and to perform the necessary actions to reduce the amount of the queues.
{warning}


CDRator Operations ensures the elements on the queues don't grow because of bugs with the system.

The second table contains the elements handled by CDRator Operations:


!example-report-4.png|border=1!

CDRator Operations independently reacts and handles the activities in this sections.