Automated Electricity Billing Process with WSO2 Technologies - Sergain Labs

  • Home
  • Automated Electricity Billing Process with WSO2 Technologies

Problem Definition

Electricity has become a basic human need in the modern world and that has created a unique ecosystem that involves electricity consumers and the provider company. Sergain is an electricity provider with a wired network around the country. As of now Sergain has a manual meter reading process and entering data manually. This was a troublesome process because of the increasing demand and scalability. In this article we will explain how Sergain is trying to do a digital transformation using WSO2 products. The main requirement in this ecosystem is to measure electricity consumption of each customer and the billing process. For the moment, this happens entirely manually, as described below.

  • Electricity meters are placed at each house in the country.
  • Currently, a person should go to each house, calculate the usage, and hand over the usage details to the office.
  • Then, a data entry operator will add these data to the central database.
  • The entire process involves multiple stakeholders such as:
  • The person who reads the electricity meter (Meter reader)
  • A person who enters billing information into the system (Data entry operator)
  • A financial operator
  • The electricity consumer
Proposed Architecture

Proposed Solution

  • Meter readers will have access to a mobile application and they can enter meter readings to the system during the site visits.
  • Consumers will have a consumer mobile application which allows them to view their consumption details, view bills, make payments online, etc.
  • Financial operators will have a web application where they can perform administrative tasks such as dispute resolution, access system data for audit purposes etc.
  • All these web and mobile applications are secured using widely adopted industry standards, using WSO2 products.
Expected Architecture

Solution Architecture

In the proposed solution, WSO2 API Manager used to secure and apply quality of services for REST APIs. WSO2 Identity Server is used for identity and access management of the web and mobile applications. Both of these products will be used to implement API Management and the Authentication layers. If we consider high level deployment layers, API Management layer will be the outermost layer. Microservices are deployed in the inner layer and directly connected to the database layer.

Features offered with WSO2 Identity Server such as device authentication, user provisioning, federated login, etc. are used in the system. WSO2 API Manager is used to secure APIs and have fine grained access control for different personas. Choreo Cloud API Analytics will act as an analytics solution and maintain API access related analytics. This will be used for both analytics and alerting when service outages happen.

Solution Architecture

Deployment

If we analyze deployment from outermost layer to inner layers you will first see external facing load balancers. These load balancers are used as main access points for API gateways and application traffic. These proxies/HTTP load balancers are deployed in DMZ and exposed to the internet.

Inside the LAN first you will see identity and access management instances, API manager gateways, application containers which are exposed to outside via load balancers. Then we have a traffic management instance which acts as a traffic volume calculator for API Manager. Database and micro services can be deployed in militarized zones with firewall separated segments. API Manager gateways can be deployed on a demilitarized zone or deployed in a militarized zone with external HTTPs traffic access.

Here NFS is used to synchronize file system based artifacts, but from API Manager 4.0.0 onward this is not something mandatory in the deployment (as event based sync mechanism will take care about artifact synchronizations).

All microservices deployed in google cloud environment with auto scaling using kubernetes. These services are deployed in the inner layer and connected to databases as well. These microservices are designed using OpenAPI definitions and spring java code auto generated using open-API tools.

Deployment Diagram

Microservices — CI/CD

Continuous Integration (CI) is a software engineering practice in which incorporates build, package, and test applications. This practice creates a platform for developers to commit code changes more frequently and have a feedback loop that is critical to detect errors as soon as they are introduced. This process helps developers to focus more on features than spending more time on bug hunting. The continuous Delivery (CD) process automates the delivery of applications to selected infrastructure environments. Our backend microservices are developed using spring-boot framework and push the frequent changes to the Github repository. We have built our CI/CD pipeline for the backend microservices using Github actions. Each commit to the Github repository will trigger the build pipeline which associates with a complete test suite to validate the new changes. After successful validation, the docker container will be created with the new changes and pushed to the private docker registry. In the end, new changes will be applied to the Kubernetes environment.

CI/CD Diagram

Technical Details — WSO2 API Manager

WSO2 API Manager deployed as all in one server for demonstration purposes. Proposed production deployment can use “Simple Scalable Deployment Pattern” considering the product usage.

While runtime traffic for API access can vary according to usage patterns and time, it is recommended to scale gateways as needed. Horizontal scaling is recommended in the event of initial planned capacity exceeded. There is a possibility of using load average, transactions per seconds and some other parameters to decide scaling requirements. If this is a high volatile system we recommend keeping a hot pool of gateways to minimize loading time(but this is a corner case).

Control plane can have 2 control plane nodes to manage high availability. Since control plane operations are not rapidly increasing over the time our recommendation is to go with 2 node active/active deployment.

To monitor API usages and access patterns, API Manager deployment was added as an environment in choreo side and provisioned analytics keys to local deployment.

Open API definitions extracted from actual microservices are used for the API creation(with some additions such as scopes etc). Resource level scopes used for fine grained access control for different personas.

Technical Details — WSO2 Identity Server

WSO2 Identity Server is used as the key component that manages user identities and access control for the system.

OOTB Self Signup feature is used to allow consumers to register themself to the system. A custom event handler is used to validate the consumer’s mobile number against the Sergain consumer account number using an API on the company side. Once the user is registered, consumer details are sent to Sergain using the same handler.

In order to provide passwordless authentication capabilities to the Sergain electricity consumers, a custom authenticator is used. An adaptive authentication script attached to the login flow switches between default login flow and the passwordless login flow, based on an attribute in the authentication request.

Mobile apps for consumers and meter readers communicate via authorization code grant type, where both clients authenticate without a client secret as they are public clients. PKCE has been made mandatory to ensure additional security in the flow. Account lock on failed login attempts and Idle Account Suspension features are also enabled for added security.

OOTB features such as Notification based password recovery, Security question based password recovery, Username recovery, etc. are also enabled.

User Flows

Consumer Self Registration

  • Consumers can download the Sergain mobile application from the playstore and proceed to self register.
  • User is asked to provide a preferred username and if the username is available, the consumer can provide basic details such as name, address, mobile number and Sergain account number.
  • After submitting those details, the application will do a validation with the mobile number and the account number and if the validation is successful, an OTP is sent to the provided mobile number.
  • Once the OTP is confirmed, the registration is completed.
Consumer Registration Flow Diagram

Consumer Login — Basic

  • Registered consumers can login to the Sergain application by providing their username and password.
  • A check is performed to verify whether the mobile number of the consumer is verified or not, in case of incomplete registrations.
Consumer Login Flow Diagram

Consumer Login — Passwordless

  • Registered consumers have the option to login to the Sergain application via passwordless authentication as well.
  • In this method, an OTP is sent to the consumer’s registered mobile number and the consumer can login only with that OTP.
  • Note: The consumer has to login with his/her credentials once for this mechanism to work, as the application caches the username of the consumer.
Consumer Login Flow Diagram (Password Less)

Meter Reader Functions

  • Meter readers will have a pre-configured account that they can use to login to the meter-reader application.
  • Once logged-in, they can search a Sergain consumer account and add meter readings.
Meter Reader Functions Flow Diagram

Consumer Functions

  • Once logged in, consumers have access to a dashboard that provides basic details about their Sergain electricity accounts.
  • They can also see their current outstanding balance and make payments through the Sergain payment gateway.
Cunsumer Functions Flow Diagram

Finance Operator Functions

  • Finance operators of Sergain have access to a web portal that allows them to manage Sergain electricity accounts and other administrative operations.
Financial Operator Functions Flow Diagram

Conclusion

In this article we have discussed the digital transformation journey of a traditional electricity service provider. The article covers related user flows, using WSO2 products and features, and some recommendations in detail. This is a very common use case we can observe across all industry vertices such as BFSI, retail, power and energy, healthcare, etc. Sergain provides assistance for many organizations to become digitally driven organizations while reducing their operational costs. WSO2 integration and identity product stack can be used for both greenfield and brownfield integrations while following the industry best practices. As a leading WSO2 partner in the Asia pacific region, Sergain provides WSO2 deployment assistance, product customizations, extension developments and all other services.

Leave Comment