1 of 47

Platform

About the Platform

Principles

The platform is built as a Digital Public Good and follows a key set of design principles listed below.

Single Source of Truth - Data resides in multiple systems across departments and getting an integrated, consistent and disaggregated view of data is imperative.
Federated - Central, State and Local Governments represent the federated structure of government. This federated structure must be taken into cognisance while designing systems that enable intergovernmental information exchange.
Unbundled - Break down complex systems into smaller manageable and reusable parts that are evolvable and scale independently.
Minimum - Minimum data attributes that have a well-defined purpose is mandatory; everything else is optional.
Privacy and Security - Ensuring the privacy of citizens, employees and users while ensuring the system's security.
Performance at Scale - The system is designed to perform at scale.
Open Standards - The system is based on open standards so that it is easy to discover, comprehend, integrate, operate and evolve.

Approach

The platform applies the microservice architecture concept. Access the list of services supported by iFIX here.

Standards

The services are designed to comply with standards which consist of the Common Information Model and APIs. Click here to view the details.

Setup

To set up the platform, follow the installation steps listed here.

Release Notes

v2.0-alpha release details

Release Summary

IFIX 2.3-alpha release details and highlights are available in the below release notes.

IFIX Core Release Notes
IFIX Adaptor Release Notes

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

iFIX Core Release Notes

Release Summary

iFIX Core v2.3 contains the following changes.

The data stores have been shifted:
1. From MongoDB to PostgreSQL
2. From Druid to ElasticSearch

Enhancements

Document Resources and Links

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

iFIX Core Build Updates

With the iFIX v2.3-alpha update, some of the DIGIT core services also need to be deployed. The builds of the same are also listed below. These have been picked from DIGIT-v2.7.

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

iFIX Adaptor Release Notes

Release Summary

MGramSeva iFix Adapter v2.3 has the below changes.

Data store moved from MongoDB to ElasticSearch
Non-backward compatible minor change to the /_create and /_update of department-entity and project master.

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

iFIX Adaptor Build Updates

With this update, the iFIX Adapter services now depend on some of the DIGIT Core services. egov-persister should be deployed and configured.

All content on this page by is licensed under a .

Migration to DIGIT Architecture

Migration to DIGIT architecture primarily involves the following changes to iFIX-Core:

Transactional DB is switched from MongoDB to PostgreSQL
Analytics DB is switched from Druid to ElasticSearch
1. Correspondingly, the dashboard is switched from Metabase to the DSS dashboard

Migration Checklist

Migration Steps - iFIX

Deploy ifix-migration-toolkit-db:develop-b7a2050-13 to ifix environment
Port forward to the ifix-migration-toolkit pod

Instruction

The following common request body is used to hit the ifix-migration-toolkit endpoints:

Migrate ifix-master-data-service

Migrate Government

Government master data is moved to MDMS. Please manually copy the government(tenant) data to the tenants master of tenant module. Here is a link to a sample .

Migrate Chart of Account

First, deploy the latest image of the ifix-master-data-service
1. (So that the tables get created in PostgreSQL.)
Deploy plain search docker image of ifix-master-data:
Ensure is configured in the egov-persister
Hit the Chart of Account migrate endpoint of the migration-toolkit

Migrate fiscal-event-service: Fiscal Events

With this, we will be performing migration from MongoDB to both, PostgreSQL and ElasticSearch. Data will be read from MongoDB using fiscal-event-service's plain search api, and pushed to a kafka topic.

From there, the data will reach PostgreSQL using egov-persister.
From kafka-topic data will pass through ifix-es-pipeline. After that ifix-es-pipeline will post the processed data to the next kafka topic in the pipeline. From there, egov-indexer will read from the topic and index the data onto ElasticSearch.

Instructions:

First, deploy the latest image of the fiscal-event-service
1. (So that the tables get created in PostgreSQL.)
Follow the instructions mentioned in the ifix-es-pipeline project's README to setup the ES mapping before performing the migration.
Deploy plain search docker image of fiscal-event-service:
Deploy the latest image of ifix-es-pipeline
Hit the Fiscal Event migrate endpoint of the migration-toolkit

Migration Steps - Adapter

Deploy ifix-migration-toolkit-db:develop-2557812-9 to mgramseva environment.
Port forward to the ifix-migration-toolkit pod

Instruction

The following common request body is used to hit the ifix-migration-toolkit endpoints:

{
    "requestHeader": {}
    "tenantId": "<tenant-id>"
}

Migrate ifix-department-entity-service

First, deploy the latest image of the ifix-department-entity-service
1. (So that the tables get created in PostgreSQL.)
Deploy plain search docker image of ifix-department-entity-service:
```
egovio/ifix-department-entity-service-db:mongodb-plainsearch-b12bf24-4
```
Ensure department-entity-persister.yml is configured in the egov-persister.
(Ensure department-entity-migration-progress is configured in egov-persister to record the progress of the migration. In case of any failures during migration, with this, it will resume the migration from where it left off. )
Hit the Department Hierarchy migrate endpoint of the migration-toolkit
```
/ifix-migration-toolkit/department_hierarchy/v1/_migrate
```
Hit the Department Entity migrate endpoint of the migration-toolkit
```
/ifix-migration-toolkit/department_entity/v1/_migrate
```

Migrate adapter-master-data-service

First, deploy the latest image of the ifix-department-entity-service
1. (So that the tables get created in PostgreSQL.)
Deploy plain search docker image of ifix-department-entity-service:
```
egovio/adapter-master-data-service-db:mongodb-plainsearch-b12bf24-5
```
Ensure adapter-master-data-service.yml is configured in egov-persister.
Hit the Department migrate endpoint of the migration-toolkit
```
/ifix-migration-toolkit/department/v1/_migrate
```
Hit the Expenditure migrate endpoint of the migration-toolkit
```
/ifix-migration-toolkit/expenditure/v1/_migrate
```
Hit the Project migrate endpoint of the migration-toolkit
```
/ifix-migration-toolkit/project/v1/_migrate
```

Specification

iFix specification details

Overview

iFix is a fiscal data exchange platform that enables the exchange of standardized fiscal data between various agencies. iFix is designed to enable the exchange of fiscal data between various agencies and ensure the visibility of fiscal data. iFix makes it possible to chain the fiscal data with each other and establish a chain of custody for the entire lifecycle from budgeting to accounting.

From the iFIX perspective, there are two types of agencies

Fiscal Data Provider - posts the fiscal data into iFix using well-defined formats.
Fiscal Data Consumer - can query the fiscal data.

Both these roles are interchangeable.

Registration

Providers and consumers need to register on iFix before they can post or query fiscal data. To register the concerned person from the agency must be provided with the following information on the iFix portal - Name of the Agency, Contact Person, Name, Contact Person’s Phone Number, and Contact Person’s Official Email Address. The OTP sent to the email address for the person should be used to register.

System Registration & Access Key Generation

Registered users -

logs in to the iFix portal using the official email address
registers one or more systems as a provider or consumer or both
provides the name of the system
a unique ID is generated for each system (example: mgramseva@punjab.ifix.org)
a secret API key is also generated for each system - use this key to post or query fiscal data
The API key can be regenerated if required - only one API key is active at a given point in time

The portal provides the ability to generate new keys for each system.

Posting

Fiscal data providers post the fiscal data in two ways.

A fiscal message - is directed to a specific consumer and is delivered to intended consumers. These messages are available for query by intended consumers only.
A fiscal event - iFix stores the events for consumers to query

Fiscal Event consists of

Header
1. From
2. To
3. Date of Posting
Body
1. Fiscal Event Type e.g. Revenue, Expenditure, Debt
2. Fiscal Event Subtype
  - Revenue - Estimate, Plan, Demand, Receipt, Credit
  - Expenditure - Estimate, Plan, Bill, Payment, Debit
  - Debt - in progress - will be provided later.
3. Array of fiscal line items
  - Amount
  - CoA
  - Location Code - from Location Registry
  - Program Code - from Program Registry
  - Project Code - from Project Registry
  - Administrative Hierarchy Code from Administrative Hierarchy Registry
  - Start Date of Period
  - End Date of Period
  - ….
  - ….
4. Attachment - Attachments consist of additional attributes like key-value pairs e.g. Account Number, Correlation ID or Documents
5. Signature - Fiscal messages can be signed by multiple agencies and add the signature to the Signature Array that contains the below-mentioned values -
  - Array of Signature
    System
    eSign - Signed Value of the Fiscal Event/Message Body using the System Key
    Purpose - Acknowledgement or Approval or Rejection
    Comments
    Date of Signing

Reversal

Data providers can reverse a previous fiscal message or event. The data provider reverses the data by posting the same event with a negative amount in the line item(s). The data consumers should handle reversals appropriately.

Querying

Data consumers can query fiscal data. They can query Messages - the unread messages that have been delivered to them. When consumers read the unread messages, these messages are marked as read. Events - Consumers can also query fiscal events posted by other data providers.

Reference Data Management

Location
Administrative
Chart of Account …. … …

Functional Specifications

iFIX business specifications

Overview

This page provides the details of the fiscal event-based approach for building out iFIX as an information exchange platform. These details are used to define the technical specifications for iFIX and the functional specifications that are open for validation and inputs internally and from the ecosystem.

Scope

The specifications have been defined from the lens of a sub-national government (the state in the current context) and are limited to interactions from a financial information perspective. The interactions covered on this page include:

State Finance Department (FD) and Central (National) Government
State Finance Department (FD) and Line Department(s) at the state level
State Line Department’s interactions with other line departments
State Line Department’s interactions with government autonomous bodies including local government and/or non-government agencies

The functional specifications are built using publicly available information and inputs from the Department of Water Supply and Sanitation (DWSS), Punjab, and Finance Department, Punjab. Financial information-related interactions of the Central Government with other Central Line Departments are out of the scope of the current specs.

Fiscal Events Based Approach

The broad objective of iFIX is to enable the flow of reliable and verifiable fiscal information in a timely manner. Recognizing the multiplicity of unique types of information flows in the current PFM system, iFIX aims at simplifying this network of information flow. The key driver of this simplification will be the use of standardised formats for fiscal information exchange. To arrive at a crystallised set of formats and protocols covering all fiscal information exchanges following steps have been followed

Step 1 - Define what is a fiscal event (and its types) or what is the scope of relevant fiscal information from an iFIX perspective (refer section)
Step 2 - Document the current public finance management processes at a generic level, i.e. defined using actors, verbs, inputs and outputs to ensure they are representative of all minor variants of the process at the level of various sub-national governments in India. (refer to tables in , columns 1-6)
Step 3 - Apply the definition of the fiscal event to the current processes to collapse or abstract the fiscal event essence of the whole process to a set of fiscal events. (refer to tables in , columns 7-9).
Step 4 - Extract the current data attributes used for fiscal information exchange to define the format for fiscal information exchange. (refer to tables in , columns 10)

Definition of Fiscal Event

Events that trigger the generation of relevant fiscal information, at any stage in the budget cycle, are termed fiscal events. To be classified as a fiscal event, the event will need to meet one of the following criteria:

Transaction-Based Fiscal Events: Such fiscal events are triggered when there is fiscal information being generated due to an actual change of hands of a financial asset or in simple words due to a financial transaction.

Non-Transactional Fiscal Events: While there are numerous non-transactional events that occur throughout the budget cycle, these are termed Fiscal events only if they meet at least one of the following criteria:

Minimum Degree of Finality: A non-transactional event will be considered a fiscal event only when the action resulting from or the document produced from the event has definitive implications for the budgetary cycle. Examples:
1. A draft of the budget that has been prepared at the state line department level (DDO) and sent to the next competent authority (BCO) for approval will trigger a fiscal event. The reason for this is that it is assumed that the line department at its level has done the calculations for arriving at a final figure which then needs to be approved by the next competent authority.
2. With respect to any payments to be made out of state treasury, any verbal/ email-based intra-Finance department go-ahead (between State Treasury and Cash Planning Department) to make the payment will not be considered a Fiscal Event. Only the generation of Payment Advice to the concerned bank will trigger a fiscal event.
Change in ability to claim/ use/ dispose of a financial asset: A non-transactional event will be considered a fiscal event if it results in (de-)authorizing a certain individual or entity to claim/ utilize/ dispose of a financial asset. Examples:
1. Allocation of the budget by the department to respective DDOs authorises the DDOs to utilize the funds as planned in the budget and will trigger a fiscal event.

Types of Fiscal Events

The fiscal information generated during each fiscal event needs to be recorded in a specific format for the purpose of exchange. Based on the current budgetary practices and guidelines followed at the sub-national and national levels in India, the fiscal events triggered during the course of the budget cycle can be classified into four major types:

Revenue Receipts: Revenue receipts comprise receipts that do not result in the creation of a liability on the government. The total revenue receipts include State’s Own Tax and Non-Tax revenues and Grants-in-Aid and Share in Central Taxes from the Government of India. The non-tax revenues consist mainly of interest and dividends on investments made by the Government, fees and other receipts for services rendered by the Government.
Capital Receipts: The capital receipts are loans raised by the Government from the public (these are termed as market loans), borrowings by the Government through the sale of Treasury Bills, the loans received from Central Government and bodies, disinvestment receipts and recoveries of any loans and advances given.
Revenue Expenditure: Revenue expenditure is for the normal running of different Government Departments and for the rendering of various services, making interest payments on debt, meeting subsidies, grants in aid, etc. Broadly, the expenditure which does not result in the creation of assets for the Government of India is treated as revenue expenditure. All grants given by the State are also treated as revenue expenditure even though some of the grants may be used for the creation of capital assets.
Capital Expenditure: Capital payments consist of capital expenditure on the acquisition of assets like land, buildings, machinery, and equipment, as also investments in shares, etc., and loans and advances made by the State Government to boards, corporations and other institutions.

Fiscal Event - Sub-Types

Further within each major type of fiscal event, there are varied types of events. To enable information exchange using an easily understandable and standardised format, subtypes of fiscal events are identified based on the similarity in nature of fiscal information generated due to these events.

Application of Fiscal Event Framework to As-Is-Processes

Budget Cycle - Overview

Budget Cycle comprises the following stages:

Budget Planning
Budget Preparation
Budget Approval
Budget Allocation
Budget Execution
Budget Accounting
Budget Auditing

Additionally, Budget Planning is an activity that sits outside of the Budget Cycle and takes place throughout the year based on need. Examples:

A scheme/project announced by a state government official can happen at any point of the year, the planning for which begins right after the announcement. Thereafter, all the required approvals happen and estimates are prepared accordingly which then feed into the budget preparation phase of the budget cycle
Planning for already approved projects and planning to get approval

Inferring Fiscal Events from As-is-Process Flows

Budget Planning

Process for Planning for the New Projects/ Schemes (for Revenue and Capital Expenditure)

Budget Preparation

Budget Preparation for Revenue Receipt

Budget Preparation for Revenue Expenditure

Budget Preparation for Capital Expenditure - Capital Outlay

Budget Approval

Budget Approval from Legislature (Same process for Revenue and Capital nature Receipts and Expenditures)

Budget Allocation

[5]Communication and Distribution of funds (Same process for Revenue and Capital nature Expenditure)

Budget Execution

Request for Release of Funds from State Treasury - Scheme-related Capital Expenditure

Release of funds to DDO

Work awarded to vendors

Work bill payment to vendors

₹Request for Release of Funds from State Treasury - Revenue Expenditure

Collection of Revenue Receipt into the State Treasury

Request for Supplementary Grants (Same process for Revenue and Capital Expenditure)

Surrender of Excess / Savings (Same process for Revenue and Capital expenditure)

Budget Accounting

Process for monthly budget accounting/reporting for Receipts (Same Process for Revenue and Capital Receipts)

Process for monthly budget accounting/reporting -Expenditure (Same Process for Revenue and Capital Expenditure)

Budget Auditing

Process for budget auditing (have to explore if there are variations for revenue and expenditure)

Definition Of Format Of Fiscal Event Sub-Types

Each fiscal event extracted above is defined in terms of

Header
Body
Array of Fiscal Line Items
Attachment
Signature

Technical Specification

Information Model

Government
Department
Department Entity (For example, Ropar Water Department)
Chart of Account
Expenditure
Project
Fiscal Event

APIs (v 0.1)

Business Services
Fiscal Event
- Post-Fiscal Event
- Search Fiscal Event

All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.

Fiscal Event

APIs

iFIX Fiscal Event Service APIs

iFIX Master Data APIs

Architecture

Platform architecture

Architecture Overview

The iFIX platform architecture and the interacting systems are divided into 3 parts:

iFIX Platform
External Agency Systems
Common Reference Data

iFIX Platform

Fiscal Event Service: It receives/sends fiscal events from/to the external systems.
Fiscal Event Store: After basic checks, the raw fiscal events are stored in the fiscal event store.
Fiscal Event Post Processor: Post Processor de-references the master data and flattens the object to store the event in the analytical data store.
Fiscal Event Analytical Store: Fiscal Events will be stored in a separate analytical store to run analytics queries.
Fiscal Event Analytical Service: All the analytics queries might not be able to run on the raw fiscal events, so a new fiscal event analytical service is developed to process the raw data and prepare it for the analytics queries.
Client Registry: All the registered clients of iFIX are maintained in this registry.

External Agency System

Fiscal Event Producer: They are the on-ground systems that generate new financial transactional information.
Producer Adapter: It helps the producer systems send the fiscal information to the iFIX Platform and link that transaction with some common reference data.
Fiscal Event Consumer: There are systems on the other end of the transaction that executes some process based on fiscal transaction information.
Consumer Adapter: It helps communicate fiscal events from the iFIX Platform to the consumer systems.
Reference Dashboard: Based on the consumed fiscal events, reference dashboards can be built with aggregated amounts by reference data.

Common Reference Data

We can link fiscal events with common reference data to derive more value from the fiscal events data. This allows us to run better analytics queries.

Administrative Registry: It will maintain the hierarchy of entities for a department integrated with iFIX.
Program Registry: It will maintain the master data for government missions/schemes.
Location Registry: It will maintain location reference data. This data is shared across all iFIX clients.
Chart of Account Registry: It will maintain the chart of account details.

Technology

Technology used for the platform

Java 8 ()
Apache Kafka ()
Keycloak ()
Postgres()
Zuul ()
MongoDB ()
Apache Druid ()
Metabase ()

All content on this page by is licensed under a .

Services

List Of Services

Tenant Management
Master Data Management (Chart of Accounts)
Fiscal Project Management
Immutable Fiscal events
- Type of events: Bill, Demand, Payment, Receipt (budgetary, cash and accrual events in the budget cycle)
- Deduplication Reversals, Adjustments - Planned
Fiscal Messaging and Subscription (coordination between different entities) - Planned
Fiscal reporting and analytics - Planned
Reference Adaptor
Reference Dashboard

All content on this page by is licensed under a .

Roadmap

Explore our iFIX (PFM) roadmap detailed view below.

Key Themes

Setup

iFix Infra Setup & Deployment

iFIX Service Setup

Infrastructure Setup

Introduction

iFIX/mGramSeva is a microservices-based distributed cloud-native application. The microservices streamline processes to meet outcomes at scale and speed. Each of the microservices is dockerized and deployed on Kubernetes infrastructure.

Pre-reads

It is essential to understand some of the key concepts, benefits and best practices of Kubernetes platform before we understand the deployment of the iFix/mGramSeva.

Know the basics of Kubernetes:
Know the commands
Know Kubernetes manifests:
Know how to manage env values, secrets of any service deployed in Kubernetes
Know how to port forward to a pod running inside k8s cluster and work locally
Know sops to secure your keys/creds:

1. Choose Installation Type

Choose the target infra type and follow the instructions to set up a Kubernetes cluster before moving on to the deployment.

2. Deployment

Before we begin the deployment, it is important to understand the deployment architecture that starts from the source code to the production-ready stage. Deploying and managing Kubernetes have emerged as a streamlined way to deploy containers in the cloud infrastructure. When running Kubernetes at scale, managing, operating, and scaling its infrastructure to maximize cluster utilization can be challenging. There are too many parameters the development team needs to manage and configure. This includes selecting the best instance type and size, determining when to scale up or down, and making sure all of the containers are scheduled and running on the best instances — and that is even before starting to think about cost resource optimization.

The simplest way to get started with the deployment process is to manage deployment configuration as code. Each service deployment configuration is defined as Helm charts and deployed into the Kubernetes cluster. We can collocate the deployment-as-code as source code, leveraging all the benefits of source control including change tracking and branching, and then package it. So below is the source code repo that contains all the deployment-as-code for iFIX.

1. mGramSeva Installation

2. iFIX-adapter Installation

3. iFIX Ref Dashboard Installation

3. Destroy the Setup

Clean up the cluster Setup using the command below, if required. This deletes the entire cluster and other cloud resources that were provisioned for the mGramSeva Infra Setup.

Conclusion

All done, the infra on local, cloud, and deployment of iFIX into the Kubernetes cluster is completed successfully.

Infrastructure Setup

Choose your infra type and provision the necessary infra before you actually deploy the services

Introduction

iFIX/mGramSeva is a microservices-based distributed cloud-native application. Each of these context-specific microservices is dockerized and deployed on Kubernetes infrastructure.

Pre-reads

It is essential to understand some of the key concepts, benefits and best practices of the Kubernetes platform before we understand the deployment of the iFIX/mGramSeva.

Know the basics of Kubernetes:
Know the commands
Know Kubernetes manifests:
Know how to manage environment values and secrets of any service deployed in Kubernetes
Know how to port forward to a pod running inside k8s cluster and work locally
Know sops to secure your keys/creds:

1. Choose the Install Type

Choose the target infra type and follow the instructions to set up a Kubernetes cluster before moving on to the deployment.

2. Deployment

The simplest way to get started with the deployment process is to manage deployment configuration as code. Each service deployment configuration is defined as Helm charts and deployed into the Kubernetes cluster. We can collocate the deployment-as-code as source code, leveraging all the benefits of source control including change tracking and branching and then packaging it. The source code repo below contains the deployment-as-code details for iFIX.

1. mGramSeva Installation

2. iFIX-adapter Installation

3. iFIX Ref Dashboard Installation

3. Destroy the Setup

Use the command below to clean up the setup cluster. This deletes the entire cluster and other cloud resources that were provisioned for the mGramSeva Infra Setup.

Conclusion

All done, the infra on local, cloud, and deployment of iFIX into the Kubernetes cluster is completed successfully.

Quickstart/Local Setup

mGramSeva Quickstart, this is not for a production

Quickstart Installation helps you jump-start with the mGramSeva basic installation with limited functionalities.‌

mGramSeva is a distributed microservice-based platform that comprises many services that are containerized. Depending upon the required features, the specific services can be run on any container-supported orchestration platform like docker-compose, Kubernetes, etc.‌

The Quickstart guide covers the installation steps for basic services to get the platform up. Before setting up mGramSeva, create a lightweight Kubernetes cluster called on a local machine with specified H/W requirements. The H/W requirements are listed below to ensure before we proceed further.‌

1. Infra Setup

To provision a lightweight Kubernetes cluster, please follow the instructions below in context to your OS and install the k3d on your machine.‌

H/W or VM Size

min 4 vCPUs (recommended 8)
min 8GiB of RAM (recommended 16)
min 30GiB of HDD (recommended 30+)

Tools

Linux distribution running in a VM or bare metal
- Ubuntu 18.04 or Debian 10 (VM or bare metal)
- Install
- on Linux
- Open terminal and Install k3d on Linux using the below command
OSX or Mac
- local Kubernetes cluster enabled
- on Mac
- Install k3d on Mac, on terminal use (Homebrew is available for MacOS) using the below command
Windows 10 or above
- need to be installed
- on Windows
- package manager for windows
- Install as an alternative command prompt that allows most of the Linux commands on windows.
- Open gitbash and Install k3d on Windows using the below command

Infra (Kubernetes Cluster) Creation

Once the above prerequisites are met, run the following tasks depending upon your OS.‌

login/ssh into the machine, go to terminal/command prompt and run the following commands as an admin user.
Create /Kube directory and change permission. To use this directory for persistent data mount. This means data from all container logs will be stored here.

Create a cluster with a single master node and 2 agents (Worker Nodes) and mount the pre-created directory (for data persistence).

‌When cluster creation is successful, get the kubeconfig file, that allows you to connect to the cluster at any time.

Verify the Cluster creation by running the following commands from your local machine where the kubectl is installed. It gives you the sample output as below

You can verify the workers' nodes created by using the following command.

‌Once the above steps are completed successfully, your Cluster is now up and running ready to proceed with the DIGIT Deployment.‌

2. mGramSeva Setup

‌Now that we have the Infra setup to proceed with the DIGIT Deployment. Following are the tools that need to be installed on the machine before proceeding with the DIGIT Services deployment.‌

What we'll deploy in Quickstart:‌

mGramSeva core platform services

Prerequisites

‌After cloning the repo CD into the folder iFix-DevOps and type the "code ." command that will open the visual editor and opens all the files from the repo iFix-DevOps

‌3. Deployment

‌Once the prerequisite setup is complete, go to the following repo, run the command and follow the instructions.

‌You can now test the DIGIT application status in the command prompt/terminal by using the below command.

On AWS

The is one of the AWS services for deploying, managing, and scaling any distributed and containerized workloads, here we can provision the EKS cluster on AWS from ground up and using an automated way (infra-as-code) using and then deploy the DIGIT-iFIX Services config-as-code using .

Pre-reads

Know about EKS:
Know what is terraform:

Pre-requisites

with the admin access to provision EKS Service, you can always subscribe to free AWS account to learn the basics and try, but there is a limit to , for this demo you need to have a commercial subscription to the EKS service.
Install on your local machine that helps you interact with the kubernetes cluster
Install that helps you package the services along with the configurations, envs, secrets, etc into a
Install version (0.14.10) for the Infra-as-code (IaC) to provision cloud resources as code and with desired resource graph and also it helps to destroy the cluster at one go.
on your local machine so that you can use aws cli commands to provision and manage the cloud resources on your account.
Install that helps you authenticate your connection from your local machine so that you should be able to deploy DIGIT services.
Use the credentials provided for the Terraform () to connect with your AWS account and provision the cloud resources.
- You'll get a Secret Access Key and Access Key ID. Save them safely.
- Open the terminal and run the following command. The AWS CLI is already installed and the credentials are saved. (Provide the credentials and you can leave the region and output format blank).
The above will create the following file In your machine as /Users/.aws/credentials

Before we provision the cloud resources, we need to understand and be sure about what resources need to be provisioned by terraform to deploy DIGIT. The following picture shows the various key components. (EKS, Worker Nodes, Postgress DB, EBS Volumes, Load Balancer)

Considering the above deployment architecture, the following is the resource graph that we are going to provision using terraform in a standard way so that every time and for every environment, it'll have the same infra.

EKS Control Plane (Kubernetes Master)
Work node group (VMs with the estimated number of vCPUs, Memory)
Node-pool's (mgramseva and ifix)
EBS Volumes (persistent volumes)
RDS (Postgresql)
VPCs (private network)
Users to access, deploy and read-only

Understand The Resource Graph In Terraform Script

Here we have already written the terraform script that provisions the production-grade DIGIT Infra and can be customized with the specified configuration.

Example:

VPC Resources:
- VPC
- Subnets
- Internet Gateway
- Route Table
EKS Cluster Resources:
- IAM Role to allow EKS service to manage other AWS services
- EC2 Security Group to allow networking traffic with EKS cluster
- EKS Cluster
EKS Worker Nodes Resources:
- IAM role allowing Kubernetes actions to access other AWS services
- EC2 Security Group to allow networking traffic
- Data source to fetch the latest EKS worker AMI
- AutoScaling Launch Configuration to configure worker instances
- AutoScaling Group to launch worker instances
Database
- Configuration in this directory creates a set of RDS resources including DB instance, DB subnet group, and DB parameter group.
Storage Module
- Configuration in this directory creates EBS volume and attaches it together.

The following main.tf with create s3 bucket to store all the state of the execution to keep track.

iFix-DevOps/Infra-as-code/terraform/sample-eks/remote-state

2. The following main.tf contains the detailed resource definitions that need to be provisioned, please have a look at it.

Dir: iFix-DevOps/Infra-as-code/terraform/sample-eks

Custom Variables/Configurations

Define your configurations in variables.tf. Provide the environment-specific cloud requirements and use the same terraform template to customize the configurations.

The values given below must be mentioned in the following files. The blank ones will be prompted for inputs while execution.

Important: Create your own key base key before you run the terraform

Run Terraform

Now that we know what the terraform script does, the resources graph that it provisions and what custom values should be given with respect to your env.

Let's begin to run the Terraform scripts to provision infra required to Deploy DIGIT on AWS.

First CD into the following directory and run the following command 1-by-1 and watch the output closely.

Upon Successful execution following resources get created which can be verified by the command "terraform output"

s3 bucket: to store terraform state.
Network: VPC, security groups.
EKS cluster: with master(s) & worker node(s).
Storage(s): for es-master, es-data-v1, es-master-infra, es-data-infra-v1, zookeeper, kafka, kafka-infra.

3. Verify that you are able to connect to the cluster by running the following command

On Azure

The Azure Kubernetes Service (AKS) is one of the Azure services used for deploying, managing, and scaling any distributed and containerized workloads. Here we can provision the AKS cluster on Azure from the ground up and using an automated way (infra-as-code) using and then deploy the DIGIT-iFIX Services config-as-code using .

This quickstart assumes a basic understanding of Kubernetes concepts. For more information, see .

If you don't have an , create a before you begin.

Pre-requisites

Use the Bash environment in .
If you prefer, the Azure CLI to run CLI reference commands.
- If you're using a local installation, sign in to the Azure CLI by using the command. To finish the authentication process, follow the steps displayed in your terminal. For additional sign-in options, see .
- When you're prompted, install Azure CLI extensions on first use. For more information about extensions, see .
- Run to find the version and dependent libraries that are installed. To upgrade to the latest version, run .
This article requires version 2.0.64 or greater of the Azure CLI. If using Azure Cloud Shell, the latest version is already installed.
The identity you are using to create your cluster has the appropriate minimum permissions. For more details on access and identity for AKS, see .
Install on your local machine that helps you interact with the kubernetes cluster
Install that helps you package the services along with the configurations, envs, secrets, etc into a
Install version (0.14.10) for the Infra-as-code (IaC) to provision cloud resources as code and with desired resource graph and also it helps to destroy the cluster at one go.

Note: Run the commands as administrator if you plan to run the commands in this quickstart locally instead of in Azure Cloud Shell.

AKS Architecture

Before we provision the cloud resources, we need to understand and be sure about what resources need to be provisioned by terraform to deploy DIGIT. The following picture shows the various key components. (AKS, Worker Nodes, Postgres DB, Volumes, Load Balancer)

AKS Architecture For iFIX Setup

AKS Azure (Kubernetes Service Master)
Work node group (VMs with the estimated number of vCPUs, Memory
Volumes (persistent volumes)
PostGres Database
Virtual Network
Users to access, deploy and read-only

Understand the Resource Graph In Terraform Script

Here we have already written the terraform script that provisions the production-grade DIGIT Infra and can be customized with the specified configuration.

The following main.tf contains the detailed resource definitions that need to be provisioned, please have a look at it.

Dir: iFix-DevOps/Infra-as-code/terraform/aks-ifix-dev

Custom Variables/Configurations

You can define your configurations in variables.tf and provide the environment-specific cloud requirements so that using the same terraform template you can customize the configurations.

Following are the values that you need to mention in the following files, the blank ones will be prompted for inputs while execution.

Run Terraform

Now that we know what the terraform script does, the resources graph that it provisions and what custom values should be given with respect to your env.

Let's begin to run the terraform scripts to provision infra required to Deploy DIGIT on AZ.

First CD into the following directory and run the following command 1-by-1 and watch the output closely.

Upon Successful execution following resources gets created which can be verified by the command "terraform output"

Network: Virtual Network.
AKS cluster: with nodepool(s), master(s) & worker node(s).
Storage(s): for es-master, es-data-v1, es-master-infra, es-data-infra-v1, zookeeper, kafka, kafka-infra.

Connect To The Cluster

- Downloads credentials and configures the Kubernetes CLI to use them.

3. Finally, Verify that you are able to connect to the cluster by running the following command

Functional Specifications

iFIX business specifications

Overview

Scope

State Finance Department (FD) and Central (National) Government
State Finance Department (FD) and Line Department(s) at the state level
State Line Department’s interactions with other line departments
State Line Department’s interactions with government autonomous bodies including local government and/or non-government agencies

Fiscal Events Based Approach

Step 1 - Define what is a fiscal event (and its types) or what is the scope of relevant fiscal information from an iFIX perspective (refer section)
Step 2 - Document the current public finance management processes at a generic level, i.e. defined using actors, verbs, inputs and outputs to ensure they are representative of all minor variants of the process at the level of various sub-national governments in India. (refer to tables in , columns 1-6)
Step 3 - Apply the definition of the fiscal event to the current processes to collapse or abstract the fiscal event essence of the whole process to a set of fiscal events. (refer to tables in , columns 7-9).
Step 4 - Extract the current data attributes used for fiscal information exchange to define the format for fiscal information exchange. (refer to tables in , columns 10)

Definition of Fiscal Event

Minimum Degree of Finality: A non-transactional event will be considered a fiscal event only when the action resulting from or the document produced from the event has definitive implications for the budgetary cycle. Examples:
1. A draft of the budget that has been prepared at the state line department level (DDO) and sent to the next competent authority (BCO) for approval will trigger a fiscal event. The reason for this is that it is assumed that the line department at its level has done the calculations for arriving at a final figure which then needs to be approved by the next competent authority.
2. With respect to any payments to be made out of state treasury, any verbal/ email-based intra-Finance department go-ahead (between State Treasury and Cash Planning Department) to make the payment will not be considered a Fiscal Event. Only the generation of Payment Advice to the concerned bank will trigger a fiscal event.
Change in ability to claim/ use/ dispose of a financial asset: A non-transactional event will be considered a fiscal event if it results in (de-)authorizing a certain individual or entity to claim/ utilize/ dispose of a financial asset. Examples:
1. Allocation of the budget by the department to respective DDOs authorises the DDOs to utilize the funds as planned in the budget and will trigger a fiscal event.

Types of Fiscal Events

Revenue Receipts: Revenue receipts comprise receipts that do not result in the creation of a liability on the government. The total revenue receipts include State’s Own Tax and Non-Tax revenues and Grants-in-Aid and Share in Central Taxes from the Government of India. The non-tax revenues consist mainly of interest and dividends on investments made by the Government, fees and other receipts for services rendered by the Government.
Capital Receipts: The capital receipts are loans raised by the Government from the public (these are termed as market loans), borrowings by the Government through the sale of Treasury Bills, the loans received from Central Government and bodies, disinvestment receipts and recoveries of any loans and advances given.
Revenue Expenditure: Revenue expenditure is for the normal running of different Government Departments and for the rendering of various services, making interest payments on debt, meeting subsidies, grants in aid, etc. Broadly, the expenditure which does not result in the creation of assets for the Government of India is treated as revenue expenditure. All grants given by the State are also treated as revenue expenditure even though some of the grants may be used for the creation of capital assets.
Capital Expenditure: Capital payments consist of capital expenditure on the acquisition of assets like land, buildings, machinery, and equipment, as also investments in shares, etc., and loans and advances made by the State Government to boards, corporations and other institutions.

Fiscal Event - Sub-Types

Application of Fiscal Event Framework to As-Is-Processes

Budget Cycle - Overview

Budget Cycle comprises the following stages:

Budget Planning
Budget Preparation
Budget Approval
Budget Allocation
Budget Execution
Budget Accounting
Budget Auditing

Additionally, Budget Planning is an activity that sits outside of the Budget Cycle and takes place throughout the year based on need. Examples:

A scheme/project announced by a state government official can happen at any point of the year, the planning for which begins right after the announcement. Thereafter, all the required approvals happen and estimates are prepared accordingly which then feed into the budget preparation phase of the budget cycle
Planning for already approved projects and planning to get approval

Inferring Fiscal Events from As-is-Process Flows

Budget Planning

Process for Planning for the New Projects/ Schemes (for Revenue and Capital Expenditure)

Budget Preparation

Budget Preparation for Revenue Receipt

Budget Preparation for Revenue Expenditure

Budget Preparation for Capital Expenditure - Capital Outlay

Budget Approval

Budget Approval from Legislature (Same process for Revenue and Capital nature Receipts and Expenditures)

Budget Allocation

[5]Communication and Distribution of funds (Same process for Revenue and Capital nature Expenditure)

Budget Execution

Request for Release of Funds from State Treasury - Scheme-related Capital Expenditure

Release of funds to DDO

Work awarded to vendors

Work bill payment to vendors

₹Request for Release of Funds from State Treasury - Revenue Expenditure

Collection of Revenue Receipt into the State Treasury

Request for Supplementary Grants (Same process for Revenue and Capital Expenditure)

Surrender of Excess / Savings (Same process for Revenue and Capital expenditure)

Budget Accounting

Process for monthly budget accounting/reporting for Receipts (Same Process for Revenue and Capital Receipts)

Process for monthly budget accounting/reporting -Expenditure (Same Process for Revenue and Capital Expenditure)

Budget Auditing

Process for budget auditing (have to explore if there are variations for revenue and expenditure)

Definition Of Format Of Fiscal Event Sub-Types

Each fiscal event extracted above is defined in terms of

Header
Body
Array of Fiscal Line Items
Attachment
Signature

All content on this page by is licensed under a .

CI/CD

CI/CD setup

The 2 Stages

Stage 1 : Jenkins Setup

Post infra setup (Kubernetes Cluster), We start with deploying the Jenkins and kaniko-cache-warmer.

Pre-requisites

Sub Domain to expose CI/CD URL
GitHub Oauth App
GitHub User ssh key
With GitHub user generate a personal read only access token
Docker hub account details (username and password)
SSL Certificate for the sub-domain

Prepare an <ci.yaml> master config file and <ci-secrets.yaml>, you can name this file as you wish which will have the following configurations.

credentials, secrets (You need to encrypt using sops and create a ci-secret.yaml separately)
Check and Update ci-secrets.yaml details (like github Oauth app clientId and clientSecret, GitHub user details gitReadSshPrivateKey and gitReadAccessToken etc..)
To create Jenkins namespace mark this flag true
Add your env's kubconfigs under kubConfigs like https://github.com/misdwss/iFix-DevOps/blob/mgramseva/deploy-as-code/helm/environments/ci-secrets.yaml#L19
KubeConfig env's name and deploymentJobs name from ci.yaml should be the same
Update the CIOps and DIGIT-DevOps repo name with your forked repo name and provide read-only access to github user to those repo's.
SSL Certificate for the sub-domain

cd iFix-DevOps/deploy-as-code/egov-deployer

kubectl config use-context <your cluster name>
go run main.go deploy -c -e ci 'jenkins,kaniko-cache-warmer,nginx-ingress'

You have launched the Jenkins. You can access the same through your sub-domain which you configured in ci.yaml.

The Jenkins CI pipeline is configured and managed 'as code'.

Example URL - https://<Jenkins_domain>

Stage 2: Continuous Integration (CI)

Since there are many services and the development code is part of various git repos, you need to understand the concept of cicd-as-service which is open-sourced. This page also guides you through the process of creating a CI/CD pipeline.

As a developer - To integrate any new service/app to the CI/CD below is the starting point:

Once the desired service is ready for the integration: decide the service name, type of service, whether DB migration is required or not. While you commit the source code of the service to the git repository, the following file should be added with the relevant details which are mentioned below:

Build-config.yml –It is present under the build directory in each repository

https://github.com/misdwss/punjab-mgramseva/blob/master/build/build-config.yml

This file contains the below details which are used for creating the automated Jenkins pipeline job for your newly created service.

config:
  - name: < Name of the job, foo/bar would create job named bar inside folder foo>
    build:
    - work-dir: < Working directory of the app to be built >
      dockerfile: < Path to the dockerfile, optional, assumes dockerfile in working directory if not provided >
      image-name: < Docker image name  >

While integrating a new service/app, the above content needs to be added in the build-config.yml file of that app repository. For example: If we are onboarding a new service called egov-test, then the build-config.yml should be added as mentioned below.

config:   
  - name: core-services/egov-test     
    build:     - work-dir: egov-test       
    dockerfile: build/maven/Dockerfile       
    image-name: egov-test

If a job requires multiple images to be created (DB Migration) then it should be added as below,

config:   
  - name: core-services/egov-test     
    build:     
    - work-dir: egov-test       
      dockerfile: build/maven/Dockerfile       
      image-name: egov-test     
    - work-dir: egov-test/src/main/resources/db       
      dockerfile: build/maven/Dockerfile       
      image-name: egov-test-db

Note - If a new repository is created then the build-config.yml should be created under the build folder and then the config values are added to it.

The git repository URL is then added to the Job Builder parameters

When the Jenkins Job => job builder is executed the CI Pipeline gets created automatically based on the above details in build-config.yml. Eg: egov-test job will be created under the core-services folder in Jenkins because the “build-config was edited under core-services” And it should be the “master” branch only. Once the pipeline job is created, it can be executed for any feature branch with build parameters (Specifying which branch to be built – master or any feature branch).

As a result of the pipeline execution, the respective app/service docker image will be built and pushed to the Docker repository.

Job Builder – Job Builder is a Generic Jenkins job that creates the Jenkins pipeline automatically which are then used to build the application, create the docker image of it and push the image to the docker repository. The Job Builder job requires the git repository URL as a parameter. It clones the respective git repository and reads the build/build-config.yml file for each git repository and uses it to create the service build job.

‌Check git repository URL is available in ci.yaml‌‌

If git repository URL is available build the Job-Builder Job

If the git repository URL is not available ask the Devops team to add it.

Continuous Deployment (CD)‌

The services deployed and managed on a Kubernetes cluster in cloud platforms like AWS, Azure, GCP, OpenStack, etc. Here, we use helm charts to manage and generate the Kubernetes manifest files and use them for further deployment to the respective Kubernetes cluster. Each service is created as charts which will have the below-mentioned files in them.

billing-service/   
# Directory – name of the service/appChart.yaml         
# A YAML file containing information about the chartLICENSE            
# OPTIONAL: A plain text file containing the license for the chartREADME.md          # OPTIONAL: A human-readable README filevalues.yaml        
# The default configuration values for this charttemplates/         
# A directory of templates that, when combined with values, will generate valid Kubernetes manifest files.

To deploy a new service, we need to create the helm chart for it. The chart should be created under the charts/helm directory in iFix-DevOps repository.

Github repository     https://github.com/misdwss/iFix-DevOps

We have an automatic helm chart generator utility that needs to be installed on the local machine, the utility prompts for user inputs about the newly developed service (app specifications) for creating the helm chart. The requested chart with the configuration values (created based on the inputs provided) will be created for the user.

‌ Name of the service? test-service Application Type? NA Kubernetes health checks to be enabled? Yes Flyway DB migration container necessary? No, Expose service to the internet? Yes, Route through API gateway [zuul] No Context path? hello‌

The generated chart will have the following files.

create Chart.yaml
create values.yaml
create templates/deployment.yaml
create templates/service.yaml
create templates/ingress.yaml

This chart can also be modified further based on user requirements.

The Deployment of manifests to the Kubernetes cluster is made very simple and easy. We have Jenkins Jobs for each state and are environment-specific. We need to provide the image name or the service name in the respective Jenkins deployment job.

Enter a caption for this image (optional)

‌The deployment Jenkins job internally performs the following operations,‌

Reads the image name or the service name given and finds the chart that is specific to it.
Generates the Kubernetes manifests files from the chart using the helm template engine.
Execute the deployment manifest with the specified docker image(s) to the Kubernetes cluster.

iFix Department Entity Service

Overview

Department Entity service manages the department and its hierarchies metadata. It deals with department entity and department hierarchy only. Department Hierarchy store only hierarchies definition like metadata for department level and department entity stores actual department data with its ancestry information.

Version History

Current Version: 2.0.0

Prerequisites

Before you proceed with the configuration, make sure the following pre-requisites are met.

Java 8
MongoDB instance
Required Service Dependencies - Adapter-Master-Data-Service

Features

Department Hierarchy

It defines the hierarchy definition for the department.

department id: It is the ID of the department from the department master
level: It defines the depth of hierarchy of department-level
parent: It provides details about department hierarchy parent (UUID)

Level Value Evaluation

Root level department hierarchy should not contain any parent value and the level value will be zero
When parent ID is having any value then we search parent in the department hierarchy record for hierarchy level evaluation.
Get level value from the parent department hierarchy and increment the current department hierarchy level value by one.

Department Entity

It contains department entity information along with its hierarchy level and also attaches master department information (department id - UUID). It keeps all child level information lists at every department node (department record). Leaf level department does not have any children info. Child list contains department entity ID list, which makes the current department entity parent of all children list (department ID list). This is how it maintains the department entity level.

Hierarchy Level Approach

Define the hierarchy level using the top to bottom because it has the parent's references. For department entity, create using the bottom-to-top approach. The leaf department entity does not have any child reference. When the department entity goes higher (parent) only then does it defines child reference in its child list.

Department Hierarchy Request Action

Create Department Hierarchy: We pass the current hierarchy level and its parent details along with master department and tenant information. It stores data as meta-information about hierarchy level for department entity data processing, it works as a reference meta index which will tell about hierarchy level information.
Search Department Hierarchy: It just provides a preview of department hierarchies by providing request parameters - tenant ID, hierarchy level or department hierarchy ID.

API List

Department Entity Request Action

Create Department Entity: It passes tenant Id, master department id, hierarchy level, its children list with department entity name and code. Tenant, hierarchy level and the master department is root info about the department entity. If the department entity does not contain any child, that means it is a leaf department entity it can only seek for its parent.
Search Department Entity: It can make search requests based on any department entity attribute but can't skip tenant information, it returns the whole department entity details along with its child information. It finds all ancestry information of the current department entity.

API List

Interaction Diagram

Environment

There will not be any environment variables required specific to the environment (migration).

Configurations and Setup

Update the DB and URI configurations in the dev.yaml, qa.yaml, prod.yaml file.

References and Notes

Department Hierarchy API With Example

Department Hierarchy defines the definition(Meta- Data) for actual department entity creation.

In the above image, the second row contains the actual Department Entities. Department Entity Create API - follows Bottom to Up approach.

In the above example data, the very first Department Entity will be created for “BARUWAL” with code “7278”. Below are the Steps to create Department Entity :

The first Department Entity will be created for “BARUWAL” (Since the Department Hierarchy has been defined from “Department” to “GPWSC”. Please refer Department-Hierarchy-API-With-Example.)
The details that need to be passed in Department Entity Create API is -
- tenantId: This will be from Ifix Master Data Service
- departmentId: This will be from Adapter Master Data Service
- code: For the first Department Entity, as per the above data image, it is “7278”
- name: For the first Department Entity, as per the above data image, it is “BARUWAL”
- hierarchyLevel: For the first Department Entity, as per the above data image and defined Department Hierarchy, It will be “6”.(Bottom to Up)
- children: For the first Department Entity, as per the above data image, it will be an empty set
For the next Department Entity Creation - repeat step 2 by making sure the subsequent request has - next Department Entity - Code, name, hierarchyLevel (this will decrement by one for every next Department entity), children (this will contain all or at least one previously created Department Entity Id(s)).

For reference, the Bottom to Up request & response of Department Entity Create API will look like :

Request :[For Department Entity at Bottom - “BARUWAL”]

 {
    "requestHeader": {
    "ts": 1627193067,
    "version": "V1",
    "msgId": "Unknown",
    "signature": "NON",
    "userInfo": {
        "uuid": "e4fd96e8-3b6b-4e36-9503-0f14a01af39d"
    }
  },      
  "departmentEntity": {
    "tenantId": "pb",
    "departmentId": "3d9ef18a-361a-40cf-b142-dd6f998e1ad2",
    "code": "7278",
    "name": "BARUWAL",
    "hierarchyLevel": 6,
    "children": []
  }
  }

Response:

{
    "responseHeader": {
        "ts": 1627193067,
        "correlationId": "4f3d17a1-9608-4471-8fb0-dda7d02e79e8",
        "msgId": "Unknown",
        "status": "successful",
        "signature": "NON",
        "version": "V1"
    },
    "departmentEntity": [
        {
            "id": "7bdf9514-e2e5-4563-bfea-f5aaa41b2137",
            "tenantId": "pb",
            "departmentId": "3d9ef18a-361a-40cf-b142-dd6f998e1ad2",
            "code": "7278",
            "name": "BARUWAL",
            "hierarchyLevel": 6,
            "auditDetails": {
                "createdBy": "4faa912d-d531-485b-ad9b-0a9878f792b0",
                "lastModifiedBy": "4faa912d-d531-485b-ad9b-0a9878f792b0",
                "createdTime": 1637563256539,
                "lastModifiedTime": 1637563256539
            },
            "children": []
        }
    ]
}

Subsequent Request: [For Department Entity - “Kiratpur Sahib”]

 {
    "requestHeader": {
    "ts": 1627193067,
    "version": "V1",
    "msgId": "Unknown",
    "signature": "NON",
    "userInfo": {
        "uuid": "e4fd96e8-3b6b-4e36-9503-0f14a01af39d"
    }
  },      
  "departmentEntity": {
    "tenantId": "pb",
    "departmentId": "3d9ef18a-361a-40cf-b142-dd6f998e1ad2",
    "code": "S557",
    "name": "Kiratpur Sahib",
    "hierarchyLevel": 5,
    "children": [
      "7bdf9514-e2e5-4563-bfea-f5aaa41b2137"  //This will be the previously created Department Entity Id(“BARUWAL”).
    ]
  }
  }

Response:

{
    "responseHeader": {
        "ts": 1627193067,
        "correlationId": "aba27b23-e5ab-4b64-a634-942553393f2a",
        "msgId": "Unknown",
        "status": "successful",
        "signature": "NON",
        "version": "V1"
    },
    "departmentEntity": [
        {
            "id": "7ae82e0e-5575-4fac-9b39-d12eead75c65",
            "tenantId": "pb",
            "departmentId": "3d9ef18a-361a-40cf-b142-dd6f998e1ad2",
            "code": "S557",
            "name": "Kiratpur Sahib",
            "hierarchyLevel": 5,
            "auditDetails": {
                "createdBy": "ba28ebe8-ed9c-4cdb-9328-b8e227eb0342",
                "lastModifiedBy": "ba28ebe8-ed9c-4cdb-9328-b8e227eb0342",
                "createdTime": 1631122344993,
                "lastModifiedTime": 1631122344993
            },
            "children": [
                "7bdf9514-e2e5-4563-bfea-f5aaa41b2137"
            ]
        }
    ]
}

And so on for the next Department Entity(ies) ...

Note: Below is the observation from the above example :

Tenant Id and Department Id will be created before creating the Department Entity hence before Department Hierarchy Create. Tenant Id and Department Id will be the same in all hierarchy levels for a Single Department Hierarchy and corresponding Department Entity(ies).
In the children attribute, we can pass a set of previous Department Entity Ids (or at least one or empty in case of Bottom level Department Entity).

Update Existing Children List

When we have to update the existing children list of Department Entity then update the existing children list using mongodb command like below

Find the parent department entity where the new children need to be added. We should know which is the parent Department Entity beforehand. For the same, Do search by name and hierarchy level and find the corresponding parent department entity’s id (UUID).

db.departmentEntity.find({"name" : "<parent_department_entity's_name>","hierarchyLevel": <parent_department_entity_hierarchy_level>});

Append the department entity id at the end of the parent department entity children's list that we got from step 1. And count the length of the parent department entity children’s list (it is 0 based indexing ) that we are calling as ‘n’ here (it could be any integer number as per the children’s list size ) and then set it as
"children.n": "<picked_from_step_1_query_department_entity_id>"
e.g.

 db.departmentEntity.update({"_id": "<new_child_department_entity_id>"},{$set:
      {"children.n": "<Resulted_department_entity_id_1>",
      "children.n+1": "<Resulted_department_entity_id_2>"}
      })

Create(publish) new fiscal event on iFix

Create the new fiscal event

POSThttps://<server_address>/fiscal-event-service/fiscal/events/v1/_publish

Body

Details for the new fiscal event + RequestHeader (meta data of the API).

requestHeader*RequestHeader (object)

RequestHeader should be used to carry meta information about the requests to the server as described in the fields below. All eGov APIs will use requestHeader as a part of the request body to carry this meta information. Some of this information will be returned back from the server as part of the ResponseHeader in the response body to ensure correlation.

tsinteger (int64)

time in epoch

versionstring

The version of the API

msgIdstring

Unique request message id from the caller

userInfoUserInfo (object)

Capture the user information

uuidstring

System Generated User id of the authenticated user.

rolesarray of string

List of roles assigned to a user

itemsstring

tenantsarray of string

List of tenants assigned to a user

itemsstring

attributesobject

correlationIdstring

signaturestring

Hash describing the current RequestHeader

fiscalEventarray of FiscalEvent (object)

versionstring

Version of the Data Model Definition

Example: "1.0.0"

idstring

System generated UUID.

Example: "fecbbf1d-d6e3-4f24-9935-02c33b9248e0"

tenantId*string

Tenant Id

Example: "pb"

senderstring

Client id of the registered source system(Get the client id from the request header)

receiversarray of string

Client ids of the registered data receivers system

itemsstring

eventType*string

Captures the event type (eg- 1.a. DEMAND, 1.b. BILL, 2.a. RECEIPT, 2.b. PAYMENT, 2.c. INTER_TRANSFER, 2.d. INTRA_TRANSFER, 3.a. SANCTION, 3.b. APPROPRIATION, 3.c. ALLOCATION)

Example: "Appropriation"

eventTimeinteger (int64)

when the event occured at source system level

Example: 1628177497000

ingestionTimeinteger (int64)

when the event arrived in ifix

Example: 1628177497000

referenceId*string

reference unique id(transaction id) of the caller system

Example: "013e9c56-8207-4dac-9f4d-f1e20bd824e7"

linkedEventIdnullable string

If this is a follow up event then it will refer to the parent event using this reference id.

Example: "7d476bb0-bc9f-48e2-8ad4-5a4a36220779"

linkedReferenceIdnullable string

If this is a follow up event then it will refer to the parent event in source system using this reference id.

Example: "77f23efe-879d-407b-8f23-7b8dd5b2ecb1"

amountDetails*array of Amount (object)

idstring

System generated UUID

Example: "51c9c03c-1607-4dd5-9e0e-93bbf860f6f7"

amount*number

Transaction Amount

Example: 10234.5

coaCode*string

Chart of account code. Publish request should contain coaCode, but search response will not contain it.

Example: "1234-123-123-12-12-12"

coaIdstring

Unique system generated Chart of Account UUID

Example: "e9f940d4-69aa-4bbb-aa82-111b8948a6b6"

fromBillingPeriodinteger (int64)

Start date of the billing period for which transaction is applicable

Example: 1622907239000

toBillingPeriodinteger (int64)

Start date of the billing period for which transaction is applicable

Example: 1628177643000

auditDetailsAuditDetails (object)

Collection of audit related fields used by most models

createdBystring

UUID (preferred) or userid of the user that created the object

lastModifiedBystring

UUID (preferred) or userid of the user that last modified the object

createdTimeinteger (int64)

epoch of the time object is created

lastModifiedTimeinteger (int64)

epoch of the time object is last modified

locationLocation (object)

Capture the location where fiscal event happened. This object represent geographical hierarchy

codestring

location code

hierarchyTypestring

location hierarchy type

Example: "State, District etc"

namestring

location name

childLocation (object)

Capture the location where fiscal event happened. This object represent geographical hierarchy

Circular reference to Location (object) ↩

auditDetailsAuditDetails (object)

Collection of audit related fields used by most models

createdBystring

UUID (preferred) or userid of the user that created the object

lastModifiedBystring

UUID (preferred) or userid of the user that last modified the object

createdTimeinteger (int64)

epoch of the time object is created

lastModifiedTimeinteger (int64)

epoch of the time object is last modified

attributesobject

Capture the extra information as a json

Response

Event published successfully

Body

responseHeaderResponseHeader (object)

ResponseHeader should be used to carry metadata information about the response from the server. apiId, ver and msgId in ResponseHeader should always correspond to the same values in respective request's RequestHeader.

tsinteger (int64)

response time in epoch

correlationIdstring

unique response message id (UUID) - will usually be the correlation id from the server

msgIdstring

message id of the request

statusenum

status of request processing

SUCCESSFAILED

signaturestring

Hash describing the current Request

versionstring

The version of the API

fiscalEventarray of FiscalEvent (object)

versionstring

Version of the Data Model Definition

Example: "1.0.0"

idstring

System generated UUID.

Example: "fecbbf1d-d6e3-4f24-9935-02c33b9248e0"

tenantId*string

Tenant Id

Example: "pb"

senderstring

Client id of the registered source system(Get the client id from the request header)

receiversarray of string

Client ids of the registered data receivers system

itemsstring

eventType*string

Captures the event type (eg- 1.a. DEMAND, 1.b. BILL, 2.a. RECEIPT, 2.b. PAYMENT, 2.c. INTER_TRANSFER, 2.d. INTRA_TRANSFER, 3.a. SANCTION, 3.b. APPROPRIATION, 3.c. ALLOCATION)

Example: "Appropriation"

eventTimeinteger (int64)

when the event occured at source system level

Example: 1628177497000

ingestionTimeinteger (int64)

when the event arrived in ifix

Example: 1628177497000

referenceId*string

reference unique id(transaction id) of the caller system

Example: "013e9c56-8207-4dac-9f4d-f1e20bd824e7"

linkedEventIdnullable string

If this is a follow up event then it will refer to the parent event using this reference id.

Example: "7d476bb0-bc9f-48e2-8ad4-5a4a36220779"

linkedReferenceIdnullable string

If this is a follow up event then it will refer to the parent event in source system using this reference id.

Example: "77f23efe-879d-407b-8f23-7b8dd5b2ecb1"

amountDetails*array of Amount (object)

idstring

System generated UUID

Example: "51c9c03c-1607-4dd5-9e0e-93bbf860f6f7"

amount*number

Transaction Amount

Example: 10234.5

coaCode*string

Chart of account code. Publish request should contain coaCode, but search response will not contain it.

Example: "1234-123-123-12-12-12"

coaIdstring

Unique system generated Chart of Account UUID

Example: "e9f940d4-69aa-4bbb-aa82-111b8948a6b6"

fromBillingPeriodinteger (int64)

Start date of the billing period for which transaction is applicable

Example: 1622907239000

toBillingPeriodinteger (int64)

Start date of the billing period for which transaction is applicable

Example: 1628177643000

auditDetailsAuditDetails (object)

Collection of audit related fields used by most models

createdBystring

UUID (preferred) or userid of the user that created the object

lastModifiedBystring

UUID (preferred) or userid of the user that last modified the object

createdTimeinteger (int64)

epoch of the time object is created

lastModifiedTimeinteger (int64)

epoch of the time object is last modified

locationLocation (object)

Capture the location where fiscal event happened. This object represent geographical hierarchy

codestring

location code

hierarchyTypestring

location hierarchy type

Example: "State, District etc"

namestring

location name

childLocation (object)

Capture the location where fiscal event happened. This object represent geographical hierarchy

Circular reference to Location (object) ↩

auditDetailsAuditDetails (object)

Collection of audit related fields used by most models

createdBystring

UUID (preferred) or userid of the user that created the object

lastModifiedBystring

UUID (preferred) or userid of the user that last modified the object

createdTimeinteger (int64)

epoch of the time object is created

lastModifiedTimeinteger (int64)

epoch of the time object is last modified

attributesobject

Capture the extra information as a json

Request

Response

Get the list fiscal events.

Based on the criteria get the list of events.

POSThttps://<server_address>/fiscal-event-service/fiscal/events/v1/_search

Body

RequestHeader meta data.

requestHeader*RequestHeader (object)

tsinteger (int64)

time in epoch

versionstring

The version of the API

msgIdstring

Unique request message id from the caller

userInfoUserInfo (object)

Capture the user information

uuidstring

System Generated User id of the authenticated user.

rolesarray of string

List of roles assigned to a user

itemsstring

tenantsarray of string

List of tenants assigned to a user

itemsstring

attributesobject

correlationIdstring

signaturestring

Hash describing the current RequestHeader

criteriaCriteria (object)

The object contains all the search criteria of the fiscal events

Idsarray of string

List of event ids

itemsstring

tenantId*string

Tenant Id

eventType*string

Captures the event type(eg- bill, receipt, expenditure)

fromEventTimeinteger (int64)

Search events b/w transaction time(Start date)

toEventTimeinteger (int64)

Search events b/w transaction time(End date)

referenceIdarray of string

itemsstring

receiverstring

Client id of the registered data receiver system

Example: "mGramSeva"

fromIngestionTimeinteger (int64)

Search events b/w ingestion time(the time when event published)

toIngestionTimeinteger (int64)

Search events b/w ingestion time(the time when event published)

Response

Successful response

Body

responseHeaderResponseHeader (object)

tsinteger (int64)

response time in epoch

correlationIdstring

unique response message id (UUID) - will usually be the correlation id from the server

msgIdstring

message id of the request

statusenum

status of request processing

SUCCESSFAILED

signaturestring

Hash describing the current Request

versionstring

The version of the API

fiscalEventarray of FiscalEvent (object)

versionstring

Version of the Data Model Definition

Example: "1.0.0"

idstring

System generated UUID.

Example: "fecbbf1d-d6e3-4f24-9935-02c33b9248e0"

tenantId*string

Tenant Id

Example: "pb"

senderstring

Client id of the registered source system(Get the client id from the request header)

receiversarray of string

Client ids of the registered data receivers system

itemsstring

eventType*string

Captures the event type (eg- 1.a. DEMAND, 1.b. BILL, 2.a. RECEIPT, 2.b. PAYMENT, 2.c. INTER_TRANSFER, 2.d. INTRA_TRANSFER, 3.a. SANCTION, 3.b. APPROPRIATION, 3.c. ALLOCATION)

Example: "Appropriation"

eventTimeinteger (int64)

when the event occured at source system level

Example: 1628177497000

ingestionTimeinteger (int64)

when the event arrived in ifix

Example: 1628177497000

referenceId*string

reference unique id(transaction id) of the caller system

Example: "013e9c56-8207-4dac-9f4d-f1e20bd824e7"

linkedEventIdnullable string

If this is a follow up event then it will refer to the parent event using this reference id.

Example: "7d476bb0-bc9f-48e2-8ad4-5a4a36220779"

linkedReferenceIdnullable string

If this is a follow up event then it will refer to the parent event in source system using this reference id.

Example: "77f23efe-879d-407b-8f23-7b8dd5b2ecb1"

amountDetails*array of Amount (object)

idstring

System generated UUID

Example: "51c9c03c-1607-4dd5-9e0e-93bbf860f6f7"

amount*number

Transaction Amount

Example: 10234.5

coaCode*string

Chart of account code. Publish request should contain coaCode, but search response will not contain it.

Example: "1234-123-123-12-12-12"

coaIdstring

Unique system generated Chart of Account UUID

Example: "e9f940d4-69aa-4bbb-aa82-111b8948a6b6"

fromBillingPeriodinteger (int64)

Start date of the billing period for which transaction is applicable

Example: 1622907239000

toBillingPeriodinteger (int64)

Start date of the billing period for which transaction is applicable

Example: 1628177643000

auditDetailsAuditDetails (object)

Collection of audit related fields used by most models

createdBystring

UUID (preferred) or userid of the user that created the object

lastModifiedBystring

UUID (preferred) or userid of the user that last modified the object

createdTimeinteger (int64)

epoch of the time object is created

lastModifiedTimeinteger (int64)

epoch of the time object is last modified

locationLocation (object)

Capture the location where fiscal event happened. This object represent geographical hierarchy

codestring

location code

hierarchyTypestring

location hierarchy type

Example: "State, District etc"

namestring

location name

childLocation (object)

Capture the location where fiscal event happened. This object represent geographical hierarchy

Circular reference to Location (object) ↩

auditDetailsAuditDetails (object)

Collection of audit related fields used by most models

createdBystring

UUID (preferred) or userid of the user that created the object

lastModifiedBystring

UUID (preferred) or userid of the user that last modified the object

createdTimeinteger (int64)

epoch of the time object is created

lastModifiedTimeinteger (int64)

epoch of the time object is last modified

attributesobject

Capture the extra information as a json

Request

Response