Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Change Log:

Date:

Author:

Version:

Changes:

Completed

Ext.

Int.

Is in Core

13 November 2023

CMI

1.0

Doc created

No

Terms and definitions:

Terms/definitions:

Meaning:

TBD

To be determined

N/A

Not applicable

ANBES

An NRDB Message Type meaning: cancellation of order (code 122)

GODK

An NRDB Message Type meaning: confirmation on order (code 111)

KABES

An NRDB Message Type meaning: receipt for order cancellation (code 141)

FBES

An NRDB Message Type meaning: error message (code 125)

FEND

An NRDB Message Type (Code 127, the meaning is not provided in the NRDB documentation)

FERD

An NRDB Message Type meaning: porting complete (code 115)

Purpose of Document

This document provides an overview of features introduced in Release 6.0 of the NRDB Number Porting project, as well as providing details of any required configuration.

Introduction to Functionality

The purpose of the NRDB Number Porting project is to facilitate number porting for Norwegian customers, using the NRDB framework. Release 6.0 of the NRDB Number Porting project includes a number of refactoring changes, primarily related to Np Export, deprecating some very old functionality and bringing the project more in line with Core 11 implementation principles.

Deprecated Logic

The following components should be considered deprecated, and should be avoided if at all possible. While not all the logic in these components has been converted into actions at this time, it is strongly recommended to consider doing so when updating or creating workflows that are meant to use any of the functionality provided by these components.

WfCNumberExportNorway

A number of functions have been deprecated, and the logic moved into new actions. Any workflows related to NP Export should be updated accordingly.

checkAnumber

checkAnumber checks if the number that requested outported is allowed to be outported and if it is not it sets different reject code to the RSP depending on the reason. The logic of this method should be handled using workflow actions instead. The logic for cancelling existing export flows has been moved to a new action, com.CDRator.billing.np.no.action.CancelNpExport (see details below.) The customer validation logic has been moved to a new action, com.CDRator.billing.np.no.action.ValidateNpExport (see details below.)

anbesHasBeenReceived

This method checks if an NRDBMessageType of code 122 (ANBES) has been received for the current np export flow. It has been replaced by a new action, com.CDRator.billing.np.no.action.HasReceivedNRDBMessageOfType (see details below.)

sendGodk

Creates a NRDBMessageType of the type NP_GODK unless an NP_ANBES has been received in which we then redirects the flow to send a NP_KABES. The logic for handling NP_ANBES and NP_KABES should be relegated to the workflow itself. The creation of the NP_GODK message should be handled by the new action com.CDRator.billing.np.no.action.CreateNRDBMessageTypeObject (see details below.)

sendFbes

Creates a NRDBMessageType of the type NP_FBES unless an NP_ANBES has been received in which we then redirects the flow to send a NP_KABES. The logic for handling NP_ANBES and NP_KABES should be relegated to the workflow itself. The creation of the NP_GODK message should be handled by the new action com.CDRator.billing.np.no.action.CreateNRDBMessageTypeObject (see details below.)

sendFend

Creates a NRDBMessageType of the type NP_FEND unless an NP_ANBES has been received in which we then redirects the flow to send a NP_KABES. The logic for handling NP_ANBES and NP_KABES should be relegated to the workflow itself. The creation of the NP_GODK message should be handled by the new action com.CDRator.billing.np.no.action.CreateNRDBMessageTypeObject (see details below.)

sendKabes

Creates a NRDBMessageType of the type NP_KABES. This logic has been replaced by the new action com.CDRator.billing.np.no.action.CreateNRDBMessageTypeObject (see details below.)

sendFerd

Creates a NRDBMessageType of the type NP_FERD. This logic has been replaced by the new action com.CDRator.billing.np.no.action.CreateNRDBMessageTypeObject (see details below.)

terminateExportProcess

Cancels the export process and reactivates the service, subscription etc. This logic has been replaced by a new action, com.CDRator.billing.np.no.action.CancelNpExport (see details below.)

startTerminatingProcess

Sets the status of the Export flow to completed and starts the termination process on the subscription. Should use existing action com.cdrator.main.subscription.action.TerminateSubscription to terminate the subscription, and new action com.CDRator.billing.np.no.action.CompleteNpExport (see details below) to complete the export flow.

WfCNumberPortabilityNorway

Only some light code cleanup has been done to this class, though, as mentioned above, if doing any workflows related to the functionality of Np Import, it is strongly recommended to include time in the estimate to refactor that logic into new functionality instead of continuing to use WfCNumberPortabilityNorway.

New Logic

An overview of new logic, introduced in Release 6.0 of the NRDB Number Porting project.

New Actions

The following are new actions, implemented to replace deprecated logic of the WfCNumberExportNorway component.

CancelNpExport

This action will cancel an ongoing NP Export Process. It can cover two different scenarios:

  • If the property cancelOtherFlows is set to false, the action will cancel the current export process. This is usually needed when a request to cancel the current np process has been received. If the property reactivateSubscription is set to true, the subscription associated with this flow will be reactivated when the flow is cancelled.

  • If the property cancelOtherFlows is set to true, the action will cancel any other outstanding NP Export workflows. This is usually used at the start of an export process, to ensure that the current export process is the only active process for this number.

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.CancelNpExport

  • cancelOtherFlows

  • reactivateSubscription

NpExportFlowNO

N/A

CompleteNpExport

This action finalizes an NP Export, updating NpExportFlowNO status id, case status id, and creating a final np export step note. It is used as the last step of a successful Np Export workflow.

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.CompleteNpExport

N/A

NpExportFlowNO

N/A

CreateNRDBMessageTypeObject

This action creates a new NRDBMessageType object based on the provided code. The action currently support NRDB Message Types of codes 111Out (GODK), 115OUT (FERD), 125Out (FBES), 127Out (FEND) and 141Out (KABES) as needed by the Export process. This logic should be expanded as necessary.

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.CreateNRDBMessageTypeObject

messageType

NpExportFlowNO

NRDBMessageType

HasReceivedNRDBMessageOfType

This action checks if an NRDBMessageType of the specified type has been received for the provided NpExportFlowNO.

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.HasReceivedNRDBMessageOfType

messageType

NpExportFlowNO

true/false

HasSecretNumber

Checks if an NRDBMessageType of code 111 has been received, and whether the COORDINATED_PORTING column of the NRDB_MESSAGE_TYPE table has been set to 2 or 3. This is used for NP Import to determine if the imported number was a secret number at the donor network, and act accordingly in the rator system.

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.HasSecretNumber

N/A

NpFlowNO

true/false

InitializeNpExport

Initializes an np export flow with status id, case status id and subscription id. Typically used at the start of an Np Export workflow to initialize the export process.

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.InitializeNpExport

N/A

NpExportFlowNO

N/A

ValidateNpExport

  • Validates the user and checks if the phone number is valid for outporting. For user validation, this check will fail if:

  • The account owner does not have a customer id (Users.getPersonalId() for business accounts, Users.getBirthDay() for private accounts.)

  • The account owner has a customer id, but it does not match the customer id on the NpExportFlowNO

  • If the subscription provided on the NpExportFlowNO is not active

  • If the service is in status 230 and the parameter value NPSYSTEM.DISABLE_CHECK_BLOCK_NOT_PAID is configured to ā€œNā€ or not configured at all

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.ValidateNpExport

N/A

NpExportFlowNO

true/false

ValidateNpExportPortDateForMinimumNumberOfDays

Validates export date by calculating the earliest date that is valid for export (based on parameter values), and comparing it to the the requested port date.

Mandatory parameter values:

  • NPSYSTEM.MIN_EXPORT_DATE_FBES

  • NPSYSTEM.MIN_EXPORT_DATE_FEND

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.ValidateNpExportPortDateForMinimumNumberOfDays

N/A

NpExportFlowNO

true/false

ValidateNpExportPortDateForMinimumWorkingHours

Validates export date by calculating the difference between the np export flow's order date and export date, and comparing them to a minimum allowed difference in hours. This minum allowed difference is configured as the execution argument minWorkingHours. If this value is set to 0, this validation will be skipped. The provided rejectComment is the comment that will be set on the NpExportFlowNO if this validation fails.

full name

properties

execution arguments

result

com.CDRator.billing.np.no.action.ValidateNpExportPortDateForMinimumWorkingHours

N/A

  • NpExportFlowNO

  • minWorkingHours

  • rejectComment

true/false

NRDB Message Type Status

The NRDB Number Porting project has been updated with a new way of handling Status, that is more aligned with core status handling: com.CDRator.billing.np.no.status.StatusNRDBMessageType. All relevant classes have been updated to use this status type. Note that StatusNRDBMessageType requires these Status IDs to be configured in the STATUS table. A script to install these statuses has been included below, as well as committed to the rator-np-no-nrdb project.

The provided status ids are:

0

UNHANDLED

1

HANDLED

2

ERROR

3

REMOVED

4

OUTPORT

9

RETRY_ERROR

Configuration

Parameter values

Parameter

Parameter type

Description

NPSYSTEM.MIN_EXPORT_DATE_FBES

N

Minimum days to receive a BEST

NPSYSTEM.MIN_EXPORT_DATE_FEND

N

Minimum days to receive ENDR

Status Types

--insert status types
INSERT INTO STATUS_TYPES (ID, NAME, DESCRIPTION, CODE)
VALUES (202311090630000001,'NRDB Message Type','Status type for nrdb message types','NRDB_MESSAGE_TYPE');

--insert status
INSERT INTO STATUS (ID, TYPE_ID, ACTIVE, STAT, DESCRIPTION, PARENT_ID)
VALUES (0, 202311090630000001, 1, 'UNHANDLED', 'Unhandled', NULL);

INSERT INTO STATUS (ID, TYPE_ID, ACTIVE, STAT, DESCRIPTION, PARENT_ID)
VALUES (1, 202311090630000001, 1, 'HANDLED', 'Handled', NULL);

INSERT INTO STATUS (ID, TYPE_ID, ACTIVE, STAT, DESCRIPTION, PARENT_ID)
VALUES (2, 202311090630000001, 1, 'ERROR', 'Error', NULL);

INSERT INTO STATUS (ID, TYPE_ID, ACTIVE, STAT, DESCRIPTION, PARENT_ID)
VALUES (3, 202311090630000001, 1, 'REMOVED', 'Removed', NULL);

INSERT INTO STATUS (ID, TYPE_ID, ACTIVE, STAT, DESCRIPTION, PARENT_ID)
VALUES (4, 202311090630000001, 1, 'OUTPORT', 'Outport', NULL);

INSERT INTO STATUS (ID, TYPE_ID, ACTIVE, STAT, DESCRIPTION, PARENT_ID)
VALUES (9, 202311090630000001, 1, 'RETRY_ERROR', 'Retry error', NULL);

References

NRDB Message Reader Engine - Version 1.2

  • No labels