Information on creating a custom calculator service
This calculator service integrates with the core platform's billing service & generates a demand. A bill can be fetched based on the demand and presented to the user. This page provides details about creating a custom calculator service.
Code for the custom calculator service is here. A separate API spec is written for the calculator service.
A calculator service typically has three APIs:
_calculate - This API returns the calculation for a given service application.
getbill or createbill - Creates and returns the bill associated with a particular application.
_search - to search for calculations.
The birth registration service calls the _calculate API to generate a demand for birth registration charges.
Calculating costs for a service and raising demand for bill generation
The calculation class will contain the calculation logic for the birth certificate registration charges. This can vary from city to city. Based on the application submitted, the calculator class will calculate the tax/charges and call the billing service to generate the demand.
What is a demand?
A demand is the official communication sent by a government authority to a citizen requesting them to pay for a service. A demand leads to a bill. When a bill is paid, a receipt is generated. A demand can be modified prior to bill generation.
For our guide, we are going to create a Calculation Service that will call the calculator to generate a demand. Follow the steps below -
Create a class under service
folder by the name of CalculationService
Annotate this class with @Service annotation and add the following logic within it -
TBD
In governments, each region, city or state has custom rates and charges for the same domain. For example, birth certificate registration rates may differ from city to city and the way it is computed can also vary. This cannot be generalised into a platform service. However, billing is a generic platform service.
The way DIGIT solves for this is to "unbundle" the problem and separate out billing from calculations. A customisable service called a "calculator" is used for custom calculation. The calculator then calls the billing service to generate the bill. Each service/module ships with a "default" calculator which can then be customised for that city.
Code of developer guide till this stage is available here. Postman collection of btr-calculator is available here. Postman collection of btr-services is availble here.
Status of payment
A demand leads to a bill which then leads to payment by a citizen. Once payment is done, the application status has to be updated. Since we have a microservices architecture, the two services can communicate with each other either through API calls or using events.
The collection service publishes an event on a Kafka topic when payment is collected for an application. Any microservice that wants to get notified when payments are done can subscribe to this topic. Once the service consumes the payment message, it will check if the payment is done for its service by checking the businessService code. The application status changes to PAID or triggers a workflow transition.
For our guide, we will follow the following steps to create payment back update consumer -
Create a consumer class by the name of PaymentBackUpdateConsumer. Annotate it with @Component annotation and add the following content to it -
Create a new class by the name of PaymentUpdateService in the service folder and annotate it with @Service. Put the following content in this class -
Create the following POJOs under models folder:
PaymentRequest.java
Payment.java
PaymentDetail.java
Bill.java
BillDetail.java
BillAccountDetail.java