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.
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.
Order Process
Configuration matrix must be defined:
From Product and RatePlan | The combination of Product and RatePlan currently assigned. |
To Product and RatePlan | The allowed Product and RatePlan which may be used as target for a rate plan change. |
Effective date | The logic for calculating the date of making the rate plan change effective. Different rules may be applied: 'Tomorrow', 'EndOfMonth', ... |
Start date | A number of hours relative to the effective date, which describe when the rate plan change process starts. When this has passed, the rate plan change cannot be stopped (i.e. point of no return). |
Allowed channel(s) | Indication of which channels (customer care, self care, ...) allow ordering this rate plan change. Still to be defined how this is to be represented. |
Key | A string that will be the dynamic key for hookpoint keys, but may also be used for identifying price elements. |
To interact with this configuration matrix, and to place a rate plan change order, some API's should be implemented:
Retrieve valid configuration matrix elements:
- Given a subscription and a channel, return the list of available configuration elements valid for this subscription and channel.
Retrieve information about pending rate plan change:
- Given a subscription, return the pending rate plan change if it exists. Null otherwise. Used to show and potentially modify the existing rate plan change.
Order rate plan change:
- 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.
The requirements in /wiki/spaces/callmobile/pages/109623384 indicate that provisioning may be requested and fees applied. The intention is to consider it business requirements and thus to place it in the appropriate workflow.
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 customer care 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.
To control the different rate plan change steps, a rate plan change should have different states:
- pending, meaning the rate plan change is ordered but not yet started.
- started, meaning the rate plan change has exceeded its start date and the initial business logic is invoked. Note, the state is set when the rate plan change has invoked the business logic, meaning the business logic does not have to terminate before the rate plan change goes into next step. If this is needed, the business logic should be declared as 'in-process'.
- post-processing, meaning the rate plan change has been executed but there is post-processing to be handled by workflows
- completed, meaning the rate plan change has completed.
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:
com.CDRator.billing.product.RatePlanChangeEngine <EngineName>
where <EngineName> is replaced with an appropriate name for identification.
Additional configuration is optional:
| Parameter name | Default value | Description |
|---|---|---|
rateplanchange.engine.batchsize | 100 | 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.
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 no post-RPC workflow is invoked, the RPC will be set to status 'Completed', and the rate plan change engine will pick it up and delete it.
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