Levels of Coexistence

Owned by Elzan Mathew
Last updated: Jun 10, 2019
4 min read

Coexistence of ERP applications with the platform can be achieved at different levels. This document is based on the philosophy laid out in the coexistence strategy paper (https://docs.google.com/document/d/13GhdnIkoeeT-t94jb61nB3WY-ZKUk--EQzFnvheWW0E/edit#) published a year back.

Level 1

Only a basic level of integration with the platform will be there at this level. Some of the platform services like the user service, MDMS service, tenant service and access control services will be used here. Main integration points are-

  1. Single Sign-on/out with the platform
    1. A common set of user, citizen and employee registries
    2. Sign in and sign out will be done from the platform.
  2. Authorization to menu links from the platform
    1. Role-based access control will be done using the access control service in the platform
    2. Menu links for platform modules as well as ERP modules will be listed in the same menu tree link
    3. On click of any menu links, the page will open in the right iframe.
  3. Referring to the common masters from the platform
    1. Platform level masters like -Department, Tenant, Designation and boundary to be accessed from the platform in the ERP
  4. All finance-related masters will be referred to in the platform using REST API calls.
    1. Master data like bank, bank account, Fund, chartofaccounts will be accessed using a REST API call from the Finance server.
  5. Elastic search index to be created in the same ES server where the platform is pushing the data. This way the dashboards can have an integrated view of things.
    1. Offline the data will be pushed to the Elastic search server using the ES REST APIs in the platform.
    2. Using the ES service in the ERP data can be pushed online to the ES server.
  6. Inbox items to be available in a single place for different applications across platform and ERP
    1. The platform is using a role-based workflow and ERP is using position based workflow. 
    2. Inbox for will be two different lists, one for the platform entities and another one for ERP entities. (There is scope for making both the list into one list)

Level 2

This is a special case where all ERP applications will be clubbed into a single package and deployed. For instance, Finance and Water & Sewerage are two applications that are running as separate ERPs. Keeping Finance ERP as the base ERP add the W&S application into this one. This way there will be only one application server hosting both the modules. Also, the code base will be a single one. Here the main integration points with the platform will remain the same as that of Level 1 except the integration with Finance is not required. Instead, there will be direct API calls for Finance masters.

Level 2

This will be a closer level of integration with the platform. All the platform services will be used in the ERP, just the core application related stuff will remain in the ERP. UIs will be rendered from the ERP itself. Beyond Level 1 coexistence billing and collections will be covered at this level.

  1. Integrate with platform demand and billing services
    1. Any demand generated from the ERP application will be done using the demand and billing services of the platform. 
    2. The billing cycle will be configured in the platform for these services.
  2. Integrate with platform collection service including payment gateway integrations
    1. Any collections made in the ERP application should use the collection service in the platform and receipts are to be created in the platform.
    2. Receipt print will be rendered from the collection service.
    3. Online payments where payment gateway is involved will use the same services as that of the platform.

Level 3

This level will integrate with the workflow engine of the platform. 

  1. Integrate with the platform workflow service
    1. Call the workflow service from the platform for any workflow in the application. This way the position based workflow in the ERP will be replaced with the role-based workflow from the platform.
    2. Render the workflow items of various entities in the platform and ERP together in the Inbox.
    3. All features of the platform workflow like the SLA and escalation can be utilized for the ERP entities also.
  2. Using MDMS service for defining the configuration and master data in the ERP
    1. State-level and ULB level configurations and master data can be kept in the platform using the MDMS service

Level 4

This level will actually try to reuse all the core services in the platform over and above Level 3. Few of the integrations can be-

  1. Use the File store service from the platform
    1. Instead of using the ERP document management feature, use the file storage service from the platform for uploading and tracking of all documents.
    2. This way all the documents will reside in the same location and management and tracking becomes easier.
  2. Integrate with platform Indexer Service
    1. Use the indexer yaml file to define the ES index and push the data to the ES server using the platform indexer service.
  3. PII data handling (data security and privacy) 
    1. Enhanced services of the platform like the data masking can be easily accommodated for any ERP entities using the platform service.
  4. Other core services like notification services, encryption service, telemetry service etc, can be used from the platform.