These test cases can serve as benchmark tests for any breaking changes in case any modification is done on top of existing services.

to access the Test Scenarios.

to access the Postman Collection for Automation Scripts.

Overview

This guide provides step-by-step instructions for installing DIGIT using GitHub Actions within an AWS environment.

Pre-requisites

• AWS account

• Github account

Steps

Prepare AWS IAM User

1. Create an IAM User in your AWS account.

2. Generate ACCESS_KEY and SECRET_KEY for the IAM user.

3. Assign Administrator Access to the IAM user for necessary permissions.

Configure GitHub Repository

1. Fork the Repository into your organization account on GitHub.

2. Navigate to the repository settings, then to Secrets and Variables, and add the following repository secrets:

   • AWS_ACCESS_KEY_ID: <GENERATED_ACCESS_KEY>

   • AWS_SECRET_ACCESS_KEY: <GENERATED_SECRET_KEY>

   • AWS_DEFAULT_REGION: ap-south-1

   • AWS_REGION: ap-south-1

Enable GitHub Actions

1. Open the GitHub Actions workflow file.

2. Specify the branch name you wish to enable GitHub Actions for.

Configure Infrastructure-as-Code

1. Navigate to infra-as-code/terraform/sample-aws.

2. Open input.yaml and enter details such as domain_name, cluster_name, bucket_name, and db_name.

Configure Application Secrets

1. Navigate to config-as-code/environments.

2. Open egov-demo-secrets.yaml.

3. Enter db_password and ssh_private_key. Add the public_key to your GitHub account.

Generate SSH Key Pair

Choose one of the following methods to generate an SSH key pair:

• Method a: Use an online website (Note: This is not recommended for production setups, only for demo purposes): https://8gwifi.org/sshfunctions.jsp

• Method b: Use OpenSSL commands:

  Copy

  openssl genpkey -algorithm RSA -out private_key.pem
  openssl rsa -pubout -in private_key.pem -out public_key.pem

Finalize Installation

After entering all the details, push these changes to the remote GitHub repository. Open the Actions tab in your GitHub account to view the workflow. You should see that the workflow has started, and the pipelines are completed successfully.

This indicates that your setup is correctly configured, and your application is ready to be deployed. Monitor the output of the workflow for any errors or success messages to ensure everything is functioning as expected.

DIGIT Infrastructure - Cleanup & Uninstallation

As you wrap up your work with DIGIT, ensuring a smooth and error-free cleanup of the resources is crucial. Regular monitoring of the GitHub Actions workflow's output is essential during the destruction process. Watch out for any error messages or signs of issues. A successful job completion will be confirmed by a success message in the GitHub Actions window, indicating that the infrastructure has been effectively destroyed.

When you're ready to remove DIGIT and clean up the resources it created, proceed with executing the terraform_infra_destruction job. This action is designed to dismantle all setup resources, clearing the environment neatly.

We hope your experience with DIGIT was positive and that this guide makes the uninstallation process straightforward.

Run the Terraform Infrastructure Destruction Job - Steps

To initiate the destruction of a Terraform-managed infrastructure, follow the steps below:

1. Navigate to Actions

2. Click DIGIT-Install workflow

3. Select Run workflow

4. When prompted, type "destroy". This action starts the terraform_infra_destruction job.

You can observe the progress of the destruction job in the actions window.

Note: For DIGIT configurations created using the master branch

If DIGIT is installed from a branch other than the main one, ensure that the branch name is correctly specified in the workflow file. For instance, if the installation is done from the digit-install branch, the following snippet should be updated to reflect that.

name: DIGIT-Install workflow
# Workflow branch creating cluster against the input.yaml file  
on:
  push:
    branches:
      - master
      - digit-install
  workflow_dispatch:
    inputs:
      destroyCommand:
        description: 'Type "destroy" to run the terraform_infra_destruction job.'
        required: true
        default: ''  

DIGIT 2.9 represents the most recent Long-Term Support (LTS) version, offering a stable and reliable foundation. This version emphasises enhanced security measures, improved system stability, streamlined deployment processes, simplified configuration, and comprehensive documentation. Periodic updates, encompassing both minor adjustments and significant enhancements, will be released as necessary. Support for this iteration of DIGIT will be available for the upcoming five years, with a clear migration guide available to facilitate the transition to subsequent LTS versions once the current support period concludes.

Long-Term Support Benefits

1. Extended Support: LTS versions come with an extended period of support, which includes security updates, bug fixes, and sometimes even minor feature enhancements. This extended support period will last for 5 years, which means that users do not need to upgrade to newer versions frequently to receive critical updates.

2. Stability: The LTS release is typically more stable than regular releases because it undergoes more extensive testing and bug fixing. Compatibility: With the extended support period, the LTS release ensures better compatibility with third-party applications and hardware over time. Developers and vendors have a stable base to target, reducing the frequency of compatibility issues.

3. Reduced Costs: For businesses, the reduced need for frequent upgrades can translate into lower IT costs. Upgrading to a new version often involves significant effort in testing, deployment, and sometimes even hardware upgrades. LTS releases help spread these costs over a longer period.

4. Predictability: LTS release provides a predictable upgrade path, making it easier for organisations to plan their IT infrastructure, training, and budgets. Knowing the support timeline in advance helps in strategic planning and resource allocation.

5. Focus on Core Features and Performance: Since the LTS release is not focused on adding new features aggressively, the bulk of efforts are spent on optimising for performance and reliability. This focus benefits users who need a solid and efficient system rather than the latest features.

6. Community and Vendor Support: LTS releases will often have a larger user base, which means a more extensive community support network is available.

What is new in LTS

• Infra/Backbone upgrade: - Postgres upgrade - Kafka upgrade - Redis upgrade - Kubernetes upgrade - Elasticsearch upgrade

• Use of helm file for deployment management

• Upgrade of core service dependencies

• Upgrade to DIGIT libraries

• Spring Cloud Gateway

• Test Automation script

• Single Click deployment using Github Actions

New Services in LTS

• MDMS V2

• Workbench (MDMS UI)

• Boundary Service (Beta)

New Functionalities

• Admin UI to configure Master Data

• Functionality to define schema and attribute validation for master data

• Maintain master data in the database

• Hot reload of MDMS data

• Configurable Rate limiting for services using helm

• Deployment of DIGIT without any local tool setup/configuration (via browser)

• Ability to create and link boundary nodes using UI/APIs

• Geospatial queries like proximity search to locate boundary nodes

Technical Enhancements & Fixes

• Filestore Service: Fixed flow to store and retrieve files from Azure blob storage.

• PDF Service: Fixed bug where _create API creates duplicate PDF for each request and fixed Kafka message getting pushed on a single partition.

• SMS Notification Service: Added API for SMS bounce backtracking.

• Mail Notification Service: Added support for attachments.

• User OTP Service: Added support for sending OTP via email by emitting email events.

• User Service: Added fallback to default message if user email update localization messages are not configured.

• Workflow Service: Introduced state-level business service fallback as part of v2 business service search API.

• Dashboard Analytics: Introduced feature to perform DIVISION operation on metric chart responses.

• Location Service: Fixed bug where search on root level boundary type yields empty search response.

• Privacy Exemplar: Data privacy changes for masking/unmasking PII data were introduced as part of this exemplar.

• Encryption Client Library: As part of privacy changes, the enc-client library was introduced to support encryption-related functionalities.

• Codegen: Enhanced codegen utility to support open API 3.0 specifications.

• Persister: Enhanced persister to make it compatible with Signed Audit Service.

• Human Resource Management Service: Fixed bug where employee search causes server error in single instance clusters.

• DIGIT Developer Guide: Backend and Frontend guides along with a sample birth registration spring-boot module, citizen and employee React modules were developed as part of this guide.

• DIGIT Installer Enhancement: DIGIT Installer was simplified and a detailed tutorial document was created for installing DIGIT services on AWS. (Note: Simplified DIGIT Installer has not been merged to master yet and is being released separately because many of our clusters are still running on legacy DevOps configurations)

• Upgraded all helm charts to support Kubernetes version upgrade from 1.20 to 1.28.

Bug Fixes

Document Resources & Links

1. Introduction:

This document provides step-by-step instructions on how to update the version of Amazon RDS (Relational Database Service) using both the AWS Management Console and Terraform.

2. Prerequisites:

• Access to an AWS account with permissions to manage Amazon RDS instances.

• Basic knowledge of AWS Management Console and Terraform.

• Create a RDS Snapshot Backup for Data Protection.

3. Updating RDS Version using AWS Management Console:

Step 1: Navigate to the Amazon RDS Console:

• Log in to the AWS Management Console.

• Go to the Amazon RDS service.

Step 2: Select the RDS Instance:

• From the list of DB instances, select the RDS instance for which you want to update the version.

Step 3: Initiate the Upgrade:

• From the given databases, select the database you wish to upgrade the Engine Version of and click on the “Modify” button.

• In the Modify DB Instance wizard, locate the "DB Engine Version" section. Select the desired version from the dropdown list. Review the other configuration settings and click on the "Continue" button.

• Select “Apply Immediately” and Review the summary of changes and click on the "Modify DB Instance" button to initiate the upgrade.

Step 4: Monitor the Upgrade Progress:

• Once the upgrade is initiated, monitor the upgrade progress from the RDS dashboard.

• The status of the instance will change to "modifying" during the upgrade process.

• Once the upgrade is completed, the status will change back to "available."

4. Updating RDS Version using Terraform:

Step 1: Define the Terraform Configuration:

• Create or update the Terraform configuration file (e.g., variable.tf) with the necessary settings to manage the RDS instance.

• Use the aws_rds_instance resource to define the RDS instance.

• Specify the desired version in the engine_version attribute.

Step 2: Apply the Terraform Configuration:

• Run terraform plan to preview the changes that will be applied.

• Run terraform apply to apply the changes and update the RDS instance with the new version.

Step 3: Monitor Terraform Execution:

• Monitor the Terraform execution for any errors or warnings.

• Once the execution is completed, verify that the RDS instance has been updated to the new version.

5. Conclusion:

This document has provided instructions on how to update the version of Amazon RDS using both the AWS Management Console and Terraform. Regularly updating the RDS version ensures that your database instance is up-to-date with the latest features and security patches.

Overview

This comprehensive documentation provides step-by-step instructions and best practices for smoothly migrating your DIGIT installation from version 2.8 to the v2.9 (LTS) release.

Pre-requisites

• Elasticsearch Upgrade

• Kafka Upgrade

• Postgres Upgrade

Steps

• To begin the migration process from DIGIT v2.8 to v2.9 LTS, it's crucial to first upgrade all prerequisite backbone services.

• Following this, scale down the Zuul replica count to zero using the provided command

kubectl scale deployment <deployment_name> --replicas=0 -n <namespace>

• Next, proceed with deploying the core service images as outlined in the attached release chart.

go run main.go deploy -e <env_file> <image_name>
# you can provide multiple images seperated by comma in the above command for multiple deployments

• Once all deployed services are confirmed to be up and running smoothly, the migration from v2.8 to v2.9 LTS can be considered complete.

• Note: If you encounter this (V20180731215512__alter_eg_role_address_fk.sql or version V20180731215512) flyway migration issue in egov-user service, follow these steps to resolve it

  • Connect to postgres pod of your server since we need to run few query to resolve it.

  • Run this SQL query : DELETE FROM egov_user_schema where version = '20180731215512';

  • Now run this SQL query : ALTER TABLE eg_userrole DROP CONSTRAINT eg_userrole_userid_fkey;

  • Restart the egov-user pod after successfullt executing these queries.

Overview

The page contains changes needed in code after Postgres is upgraded to version 14.

Steps

1. Update the postgresql library as given in the below snippet:

    <dependency>
       <groupId>org.postgresql</groupId>
       <artifactId>postgresql</artifactId>
       <version>42.7.1</version>
    </dependency>

1. Update the flyway client library as per details given below:

    <dependency>
       <groupId>org.flywaydb</groupId>
       <artifactId>flyway-core</artifactId>
       <version>9.22.3</version>      
    </dependency>

1. Update the flyway Dockerfile and migrate.sh file as given below:

COPY ./migration/main /flyway/sql
COPY migrate.sh /usr/bin/migrate.sh
RUN chmod +x /usr/bin/migrate.sh
ENTRYPOINT ["/usr/bin/migrate.sh"]

#!/bin/sh
flyway -url=$DB_URL -table=$SCHEMA_TABLE -user=$FLYWAY_USER -password=$FLYWAY_PASSWORD -locations=$FLYWAY_LOCATIONS -baselineOnMigrate=true -outOfOrder=true migrate

Overview

This document provides a comprehensive log of system upgrades, detailing the progression of various software components from older versions to their latest releases as of this update. This ensures transparency and provides a reference for the evolution of our system's infrastructure.

[Unreleased]

• No unreleased changes.

[2.9LTS] - 2024-MM-DD

Upgraded

• PostgreSQL: Upgraded from 11.2 to 14.10, enhancing database performance, security features, and compatibility with the latest extensions.

• Redis: Upgraded from 3.6 to 7.2.4, bringing improvements in processing speed, security patches, and new features for better data management.

• Elasticsearch: Upgraded from 6.6 to 8.11.3, which includes significant advancements in search capabilities, performance optimizations, and security enhancements.

• Kibana: Version updated from 6.6 to 8.11.3 to align with the Elasticsearch upgrade, improving data visualization and UI/UX enhancements.

• Kafka: Upgraded from 2.4 to 3.6.0, introducing improvements in scalability, reliability, and a set of new features that enhance message queuing capabilities.

• Jaeger: Upgraded from 1.18 to 1.53.0, significantly improving distributed tracing capabilities, UI improvements, and performance optimizations.

• Prometheus: Upgraded from 2.48.0 to 2.49.0, focusing on enhancements in monitoring capabilities and minor improvements in system performance.

• Grafana: Upgraded from 7.0.5 to 10.2.3, bringing a leap in visualization features, plugin ecosystem, and overall performance and usability improvements.

• Cert-Manager: Upgraded from 1.7.3 to 1.13.3, enhancing certificate management with new features and security improvements.

Deprecated

• Report

• egov-searcher

Removed

• Zuul

Fixed

• No fixes in this release.

Security

• Upgraded components include security patches and improvements to address known vulnerabilities.

[Previous Version Number] - YYYY-MM-DD

• Previous changes if applicable.

Overview

This document contains information about the code changes that will be required in the registries for upgrading Spring boot and client libraries

Steps

POM Updates

1. Upgrade the Java version in the module to Java 17 before upgrading the Spring Boot version to 3.2.2. Following is a sample snippet of the Java version upgrade:

<properties>
    <java.version>17</java.version>
    <maven.compiler.source>${java.version}</maven.compiler.source>
    <maven.compiler.target>${java.version}</maven.compiler.target>
</properties>

1. Upgrade spring-boot-starter-parent library to version 3.2.2. The code snippet of the dependency is shown below:

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.2.2</version>
    </parent>

1. Upgrade the Flyway library to version 9.22.3 for compatibility with Postgres 14. Below is the code snippet:

      <dependency>
         <groupId>org.flywaydb</groupId>
         <artifactId>flyway-core</artifactId>
         <version>9.22.3</version>
      </dependency>

1. Upgrade the postgresql library to version 42.7.1:

       <dependency>
           <groupId>org.postgresql</groupId>
           <artifactId>postgresql</artifactId>
           <version>42.7.1</version>
        </dependency>

1. The tracer library is upgraded to springboot 3.2.2. The updates are available in the library version 2.9.0-SNAPSHOT. If the module is using the tracer, upgrade the tracer version to 2.9.0-SNAPSHOT as shown below:

        <dependency>
            <groupId>org.egov.services</groupId>
            <artifactId>tracer</artifactId>
            <version>2.9.0-SNAPSHOT</version>
        </dependency>

1. The service-common library is upgraded and added in tracer. You don't have to explicitly upgrade the services-common library and remove it from POM if you upgrade the tracer. In case your module is using only services-common, you can directly upgrade the version to 2.9.0-SNAPSHOT

2. Use the below version of JUnit which is compatible with Java 17:

          <dependency>
               <groupId>junit</groupId>
               <artifactId>junit</artifactId>
               <version>4.13.2</version>
               <scope>test</scope>
          </dependency>

1. If you are using the MDMS client library update the dependency version to 2.9.0-SNAPSHOT as shown below:

            <dependency>
               <groupId>org.egov</groupId>
               <artifactId>mdms-client</artifactId>
               <version>2.9.0-SNAPSHOT</version>
            </dependency>

1. Update the Lombok version in the pom.xml to 1.8.22:

  <properties>
    <log4j2.version>2.17.1</log4j2.version>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    <java.version>17</java.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <lombok.version>1.18.22</lombok.version>
  </properties>

1. If you are using net.minidev library, upgrade the version to 2.5.0

    <dependency>
      <groupId>net.minidev</groupId>
      <artifactId>json-smart</artifactId>
      <version>2.5.0</version>
    </dependency>

1. To simplify dependency management and ensure version compatibility for Spring Kafka and Spring Redis dependencies use the spring-boot-starter-parent as your project's parent in the pom.xml. This ensures the spring-kafka or spring-redis dependency is included without specifying a version, Spring Boot will automatically provide a compatible version of the dependency. Following are code snippets of both the dependencies:

 <dependency>
      <groupId>org.springframework.kafka</groupId>
      <artifactId>spring-kafka</artifactId>
 </dependency>

 <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-data-redis</artifactId>
 </dependency>

Note: If a tracer library is implemented there is no need to explicitly import spring-kafka.

Registry Code Changes

1. Javax is deprecated and transitioning to Jakarta. Remove any Javax dependencies and update all Javax imports to Jakarta. For example, change imports like PostConstruct and valid to their Jakarta counterparts in all occurrences.
2. Remove the annotation @javax.annotation.Generated which is now deprecated.

3. Update the Dockerfile for flyway migration with the below content: FROM egovio/flyway:10.7.1

COPY ./migration/main /flyway/sql

COPY migrate.sh /usr/bin/migrate.sh

RUN chmod +x /usr/bin/migrate.sh

ENTRYPOINT ["/usr/bin/migrate.sh"]

1. Update the migrate.sh script: #!/bin/sh

flyway -url=$DB_URL -table=$SCHEMA_TABLE -user=$FLYWAY_USER -password=$FLYWAY_PASSWORD -locations=$FLYWAY_LOCATIONS -baselineOnMigrate=true -outOfOrder=true migrate

1. If you are using spring-redis, add the following configuration file:

import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.connection.RedisConfiguration;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.connection.RedisStandaloneConfiguration;
import org.springframework.data.redis.connection.jedis.JedisConnectionFactory;
import org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory;
import org.springframework.data.redis.core.StringRedisTemplate;

@Configuration
public class RedisConfig {

    @Value("${spring.redis.host}")
    private String redisHost;

    @Value("${spring.redis.port}")
    private int redisPort;

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        RedisConfiguration redisConfiguration = new RedisStandaloneConfiguration(redisHost, redisPort);
        return new LettuceConnectionFactory(redisConfiguration);
    }

    @Bean
    public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
        return new StringRedisTemplate(redisConnectionFactory);
    }

}

1. Remove @SafeHtml annotation from the fields in POJO models as it is deprecated.

2. Update the Junit dependencies in the test cases as shown below:

Overview

A comprehensive guide on running automated test scripts for various core services.

Pre-requisites

Before initiating automating DIGIT- LTS core services, ensure the Postman tool is installed.

Create an environment in Postman with a global variable BaseUrl and set its value per your environment configuration. For example - we have set https://digit-lts.digit.org as the base URL.

Import all the services you want to automate in the same environment.

Steps

Follow the steps below to run the egov-User service automation scripts.

1. Import user collection: Copy the User collection link from the provided document link: Collection Document and import the collection in Postman.

2. Port forward to DIGIT-LTS environment: Replace [userPod] with the relevant user pod name.

kubectl port-forward [userPod] 8081:8080 -n egov

Port-forward to the DIGIT-LTS environment to create the first user using the command above.

3. Run the user collection: Click on the Download CSV link to download the CSV file. Make sure to download the file in CSV format before proceeding with the User collection.

In the CSV file, each cell in the first row UserFIRST, UserName2, and UserName3 represents a unique user and each cell in the second row represents a name given to a specific user.

For example: The first cell in the first row that is UserFIRST represents the first user and USERDemoM1 represents the name given to user UserFIRST.

Open the User collection in Postman and click on the Run button.

Select CSV file - Select the downloaded CSV file by clicking on the Select File button.

Click on the Run User button to execute the collection.

Additional Notes

• The provided steps automate the creation of users in the DIGIT-LTS environment, which is essential for accessing all resources.

• Review and modify the CSV file as needed to include accurate user data.

• For further assistance or troubleshooting, refer to the Postman documentation or contact the relevant support channels.

• By following these steps, you can effectively automate the core services of DIGIT-LTS, starting with the User service, using Postman.

Test Automation - Localization Service

1. Import Localization Collection into Postman: Click here and copy the localization collection link (available in column B of the sheet). Open the Postman and import the collection.

2. Prepare CSV File: Click here to download the CSV file. Make sure the CSV file is in the correct format.

3. Run localization Collection in Postman: Open the localization collection in Postman by clicking on localization collection. Click on the Run button to execute the collection.

4. Select CSV File: When prompted, click on the Select File button to select the downloaded CSV file.

5. Run Collection: After selecting the CSV file, click on the Run Collection button to execute the collection.

In the CSV file, code1 represents the specific code for creating the message in the locale1.

The message "Punjab water park" is created in the locale/region/mohalla. A unique code "Alpha pgr 1" is associated with the created message.

The locale column in the CSV file represents the place/area to create the message (mandatory).

The code column represents the unique code associated with the message.

The above steps automate the localization services using Postman.

Test Automation - Egov-OTP Services

1. Import Egov OTP Collection into Postman:

• Click here to open the document and copy the Egov OTP collection link

• Open Postman and import the collection.

2. To Run Egov OTP Collection in Postman:

• Click on the Egov OTP collection in Postman to open the collection.

• Click on the Run button to execute the collection.

• Click on the Run Collection button to execute the collection.

Test Automation - MDMS Service

1. Import MDMS Collection into Postman:

• Click here to open the document and copy the MDMS collection link.

• Open Postman and import the collection.

2. To run the MDMS Collection in Postman:

• Open the MDMS collection in Postman by clicking on MDMS collection.

• Click on the Run button to execute the collection.

• Click on the Run Collection button to execute the collection.

Test Automation - URL Shortening Service

1. Import Url shortening Collection into Postman:

• Click here to open the document and copy the URL shortening collection link.

• Open Postman and import the collection.

2. To run the URL - shortening collection in Postman:

• Open the URL shortening collection in Postman by clicking on the URL shortening collection.

• Click on the Run button to execute the collection.

• Click on the Run Collection button to execute the collection.

Test Automation - egov-location Service

1. Import Location Collection into Postman:

• Click here to open the document and copy the location collection link.

• Open Postman and import the collection.

2. To run Location Collection in Postman:

• Open the Location collection in Postman by clicking on Location collection.

• Click on the Run button to execute the collection.

• Click on the Run Collection button to execute the collection.

Test Automation - access-control Service

1. Import Access control Collection into Postman:

• Click here to open the document and copy the Access Control collection link.

• Open Postman and import the collection.

2. To run the Access Control collection in Postman:

• Open the Access Control collection in Postman by clicking on Access Control collection.

• Click on the Run button to execute the collection.

• Click on the Run Collection button to execute the collection.

Test Automation - Filestore Service

1. Import Filestore Collection into Postman:

• Click here to open the document and copy the Filestore collection link.

• Open Postman and import the collection.

2. To run Filestore Collection in Postman:

• Open the Filestore collection in Postman by clicking on the Filestore collection.

• Click on the Run button to execute the collection.

• Click on the Run Collection button to execute the collection.

Test Automation - egov- Idgen Service

1. Import the ID gen Collection into Postman:

• Click here to open the document and copy the ID-gen collection link.

• Open Postman and import the collection.

2. To Run Id gen Collection in Postman:

• Before executing the Id gen collection, download the CSV file from https://docs.google.com/spreadsheets/d/1bB3R5faJFfRC0cGZbtPBhv1bmKm_MsH1upnuC3s2hso/edit?usp=sharing in CSV format.

• Open the Id gen collection in Postman by clicking on Id gen collection.

• Click on the "Run" button to execute the collection.

• Click on the "Run Collection" button to execute the collection.

Test Automation - Workflow Service

1. Importing WorkFlow Collection:

• Click here to open the document, copy the Workflow collection link and import the Workflow collection into Postman.

2. Running the WorkFlow Collection:

• Click here to download the CSV file before executing the WorkFlow collection.

• Open the WorkFlow collection in Postman and click on the Run button.

• Select the downloaded CSV file by clicking on the Select File button.

• Click on the Run Workflow button to execute the collection.

Additionally, you must update the columns BusinessIdFirst and BusinessIdTwo in your application for a successful transition.

Test Automation - Encryption Service

1. Importing Encryption Collection:

• Click here to open the document, copy the Encryption collection link and import the collection into Postman.

2. Port Forwarding to Digit-LTS Environment:

• Port-forward to the Digit-LTS environment to decrypt the Encrypted data. Use the following command:

• kubectl port-forward [Encryption] 8081:8080-n egov

• Replace [Encryption] with the relevant Encryption pod name.

3. Running the Encryption Collection:

• Click here to download the CSV file before executing the Encryption collection.

In CSV file , cell in first row "UserForEncy" represents unique user and cell in second row "EncUser1" represent name given to specific user.

• Open the User collection in Postman and click on the Run button.

• Select the downloaded CSV file by clicking on the Select File button.

• Click on the Run EncyptionApi button to execute the collection.

Overview

This document provides step-by-step instructions on how to take backups of PostgreSQL databases hosted on AWS.

Pre-requisites

• Access to an AWS account with permissions to manage Amazon RDS instances.

• PostgreSQL database hosted on Amazon RDS.

Steps

Step 1: Navigate to the Amazon RDS Console:

• Log in to the AWS Management Console.

• Go to the Amazon RDS service.

Step 2: Select the PostgreSQL Instance:

• From the list of DB instances, select the PostgreSQL instance for which you want to take the backup.

Step 3: Enable Automated Backups (Optional):

• If automated backups are not already enabled, navigate to the "Backup" tab of the RDS instance.

• Click on "Modify" and enable automated backups.

• Configure the backup retention period according to your requirements.

Step 4: Manually Trigger a Snapshot:

To create a manual snapshot, select the RDS instance you want to back up. Click on the Actions button in the right upper corner and select Take a snapshot.

This will redirect you to a page like the one below.

Provide a meaningful name for the snapshot and click “Create snapshot”.

This will create a manual snapshot of the DB instance that you created.

Step 5: Create a Manual Backup Using pg_dump:

• Connect to the PostgreSQL database using a PostgreSQL client tool or command-line interface.

• Use the pg_dump command to export the database to a file:

  Replace <hostname>, <username>, <database_name>, and <backup_file_name> with the appropriate values.

Step 6: Copy Backup Files to Amazon S3 (Optional):

• If desired, copy the backup files to Amazon S3 for long-term storage and redundancy.

• Use the AWS CLI or SDKs to upload the files to an S3 bucket.

Summary

This document has provided instructions on how to take backups of PostgreSQL databases hosted on AWS. Regular backups are essential for data protection and disaster recovery purposes.