Navigation :

Reporting Configuration

Table Partitioning

All Reporting database tables that store data derived from Service or EDR information are partitioned against the event date. Partitioning is managed using the built-in PostgreSQL partitioning features.

For EDRs, the date/time of the event itself is used. For copies of service data, the date/time the database copy was initiated by NiFi is used.

Each partition covers a single 24 hour period from midnight (inclusive) to the following midnight (exclusive) in the local timezone. With daily partitioning, maintaining an exact number of days of data is simple using postgres partition maintenance.

Partitioning Configuration

All partition configuration is stored in the database table n2rep.partition_configuration in the n2reporting database table. To change the partition configuration this table must be edited directly via SQL tools.

The default configuration is:

DB Schema	DB Table	Retention Days	Pre-Created Day Count
ACD	CUSTOMER	7	10
ACD	FLOW	7	10
ACD	FLOW_VERSION	7	10
ACD	FLOW_VERSION_SCHEDULE	7	10
ACD	GEOGRAPHY_ENTRY	7	10
ACD	GEOGRAPHY_ENTRY_PREFIX	7	10
ACD	GEOGRAPHY_SET	7	10
ACD	HOLIDAY_ENTRY	7	10
ACD	HOLIDAY_ENTRY_DATE_RANGE	7	10
ACD	HOLIDAY_SET	7	10
ACD	N2ACD_EDR	93	10
ACD	N2SVCD_EDR	30	10
ACD	SERVICE	7	10
ACD	SUMMARISED_EDR	720	10
ACD	SUMMARISED_EDR_B_PARTY	720	10
ACD	SUMMARISED_EDR_SRP_INTERACTIONS	720	10

Where:

The database schema and table refer to the reporting database schema and table to manage. Other N-Squared products might also be listed in this table.
Retention Days is the number of days of historical data to keep.
Pre-Created Day Count is the number of future days (including today) to create partitions for each time the maintenance script is run.

Partitioning Management

A maintenance script is configured by the reporting database installation script and is run using the systemd timer subsystem. This is scheduled to run daily between 3 and 4 am.

Service Determination

Service determination (that is, whether an EDR session is considered an ACD call, or not) is performed by the NiFi dataflows implementation. The default implementation of this process is to base service determination on the source directory. Independent source directories, populated by independent Nifi transfer processes, effectively determine ACD vs non-ACD EDR streams.

If more complex service determination is required - e.g. because two distinct services are managed by the same AS nodes and it isn’t possible to split EDRs prior, then service determination can be based on the:

SIP From: URI header, or the
SCP InitialDP ServiceKey field

Service Determination by Initial EDR Field

SIP Call Service Determination

A SIP voice call is assigned a service based on the from address URI. Each SIP deployment of N2ACD must have the FROM_URI EDR field from the IN-INVITE-ALEG EDR mapped to the correct service name.

In the n2reporting database, the current mapping can be determined by running the following query:

select * from n2rep.sip_invite_service_mapping

For example the mapping may be:

`from_uri_regex`	`service`
`otg=LNP`	`SNS`
`otg=MNP`	`SNS`
`otg=CLI`	`SNS`
`otg=Whitelist`	`SNS`

The service name ACD must be used to match to the ACD service in Apache NiFi. The special service name drop may be used to indicate EDRs for the matching session can be dropped and not processed further. the service name SNS must be used to match to the N-Squared Simple Number Services (N2SNS) service processing.

INAP Call Service Determination

An INAP voice call is assigned a service based on service key. Each INAP deployment of N2ACD will require its own service key to service name mapping.

In the n2reporting database, the current mapping can be determined by running the following query:

select * from n2rep.initialdp_service_mapping

For example the mapping may be:

`service_key`	`service`
`9001`	`ACD`
`30419`	`drop`