Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Contents

Table of Contents
maxLevel4
indent10px
printablefalse

Change log:

Date:

Author:

Version:

Changes:

Completed

Ext.

Int.

Is in Core

Jira Ref.

02 December 2013

Torben Poort Lange

1.0

Doc. created

Yes

x

 


X

 


Order Overview

At the date of the order, the order is placed which starts the ordering process. This process is ended by invoking the hookpoint "RATEPLAN.CHANGE.ORDER". After successful completion, the rate plan change enters a 'Pending' state.

Based on the given effective date, a start date is calculated. When this date is passed, the corresponding process begins and ends with invoking the hookpoint "RATEPLAN.CHANGE.START". After successful completion, the rate plan change enters into the 'Started' state.

Drawio
simple0
zoom1
inComment0
custContentId653460722
pageId113410687
diagramDisplayNameBackEnd - RatePlanChange process overview.drawio
lbox1
contentVer1
revision2
baseUrlhttps://enghouseglobal.atlassian.net/wiki
diagramNameBackEnd - RatePlanChange process overview.drawiorevision1
pCenter0
width1090.6036376953125
links
tbstyle
height411.26703493957393

Immediately after the rate plan change has entered the 'Started' state, the execute process begins by invoking the hookpoint "RATEPLAN.CHANGE.PRIOR" followed by applying the core business logic. Subsequently, the hookpoint "RATEPLAN.CHANGE.AFTER" is invoked. Upon successful completion the rate plan change enters the 'Completed' state. 

Please note that two different workflows identified by hookpoints “START” and “PRIOR” are both invoked in the 'Started' state. The reason is to allow the customer to implement required logic in either workflow based on what is considered the most appropriate – immediately following the start of the process or immediately before the execution of the actual rate plan change process. In any case, the “PRIOR” workflow is invoked just after the “START” work.

Drawio
1
simple0
zoom1
inComment0
custContentId653527120
pageId113410687
diagramDisplayNameRatePlanChangeOverview.drawio
lbox1
contentVer1
revision2
baseUrlhttps://enghouseglobal.atlassian.net/wiki
diagramNameRatePlanChangeOverview.drawiorevision
pCenter0
width937
links
tbstyle
height582.5

Order Process

Configuration matrix must be defined:

...

  • Given a configuration matrix element, subscription and effective date, validate if the rate plan change is allowed according to the configuration matrix element.
  • Given a configuration matrix element, subscription, effective date, silent indication, fee apply indication and list of chosen options, persist the requested rate plan change and invoke the hookpoint "RATEPLAN.CHANGE.ORDER" + key from the configuration matrix element. The silent indication will be transferred to the various workflows to allow external communication to be excluded. The fee apply indication will be transferred to the various workflows to indicate if fees should be added or not.

Implementation Information

It should be rather straightforward to implement the configuration matrix and related API. However, a GUI must be created to maintain the configuration elements, and (at least) the current rate plan change panel in CustomerCare must be updated to utilize the API functionality.

When a rate plan change is ordered, the current functionality that saves the rate plan change record and associated options must be inspected and validated. As far as I know, scheduling a rate plan change does not work that well. Some work is needed to validate and probably also correct the functionality.

Start Process

When a rate plan change is ordered, a start date is calculated based on the effective date. When this start date is passed, some business logic may be executed.

Implementation Information

The RatePlanChangeEngine will look for rate plan change records with a start date being passed.
For such a record, a workflow must be executed: the static key is "RATEPLAN.CHANGE.START" and the dynamic key is specified on the configuration matrix element.

...

In case either business logic or core logic fails for any reason, the rate plan change state will not change.
This means, that if a rate plan change in state 'started' is being picked up because the actual rate plan change is to be executed, it either stays in status 'started' if failure happens in either business logic or core logic, or the status become 'completed' if everything completed successfully.

Engine Configuration

The engine must be started using the following command line:

...

Parameter nameDefault valueDescription
rateplanchange.engine.batchsize100

The number of records being processed in one database transaction.

Execute Process

It is important that a rate plan change is executed before the effective date in order to ensure that traffic, fees etc. are billed correctly on that date.

In order for a rate plan change to become active no later than the effective date, it is necessary to initiate the execution process some time before midnight on the day before the effective date, i.e. if the effective date is set to the 2nd December, the process must be completed before the 2nd December at 00:00.

A rate plan change consists of a number of steps:

  • Business logic to be executed prior to the core logic (hookpoint key "RATEPLAN.CHANGE.PRIOR"). By using this business logic the rate plan change information may be altered, fees may be added, provisioning tasks may be created, and external communication may be initiated.
  • A billing group member must be created referring to the new rate plan, and service options must be created or deleted.
  • The set of new billing group members, updated service options as well as potentially information about a product change will be added to a workflow context which allows the result to be altered and invoke other types of business logic. This should happen as part of workflow identified by the hookpoint key "RATEPLAN.CHANGE.AFTER".
  • The set of new billing group members, updated service options and product information will be persisted. This change should happen no later than 00:00 ot the effective date, otherwise rating and billing may be wrong.

To ensure that the rate plan change is persisted prior to the effective start date, the process must be initiated some time before the effective date. It is suggested that this is a parameter for the rate plan change process which specifies that the execution should begin some hours before the effective date. Thus it is up to the prior workflow to keep the logic simple and avoid external dependencies to ensure that the actual rate plan change may be handled in time.

Note

Today it is possible to create the billing group membership in advance, so this could actually happen immediately after the start of the process. However, this is not possible to do for product changes nor option changes.

Implementation Information

The current rate plan change engine must be altered to allow the identification of pending rate plan changes according to the start date and effective date.

The current rate plan change process must be inspected to ensure the changes are done according to core logic, and that the appropriate workflows are executed. Changes are needed to separate the outcome of the rate plan change process with the persistence of the same outcome.

Post Process

When a rate plan change has been executed a workflow can be invoked, which means that we no longer can delete the rate plan change during the execution step as it needs to be available for the workflow. So the rate plan change workflow is now responsible for deleting completed rate plan changes that have gone through the new RPC flow

 


Before the workflow is invoked, the RPC is set to status 'Post-Pending'. 

...

If a post-RPC workflow is invoked, this workflow will be responsible for setting the status on the RPC to 'Completed' when appropriate. This is so the workflow does not have to be in-process and can be run asynchronously