Search

Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Adeptia Connect (AC) is an enterprise-class application that is designed for reliable, scalable, and secure operations in mission-critical use cases. Large organizations such as many Fortune 500 companies rely on Adeptia Connect to handle important data exchanges with external customers and partners as well as within internal systems and applications.

Adeptia Connect version 4.0 is a cloud-native application with microservice architecture. It uses Docker to containerize different microservices and uses Kubernetes for container orchestration and management. The application provides the following advantages:

  1. It can run as a cloud-native application.
  2. High scalability. Different microservices can be scaled as per need.
  3. High availability.
  4. Automated deployment and upgrade through CD pipeline.
  5. Centralized monitoring and logging.

The Application Architecture diagram for Adeptia Connect is shown below.


Key components

Component

Description

webapp-gateway

  • Microservice to serve as single entry point for communicating with all the Microservices
  • Invokes multiple Microservices and aggregates the results.

portal

  • Microservice for serving GUI to configure entities and view logs.

web-runner

  • Microservice for serving UI data.

event

  • Microservice for scheduling of events

runtime

  • Microservice for Process Flow and Transaction execution

rest-api

  • Microservice to publish and serve all the REST API

soap-api

  • Microservice to publish and serve all the SOAP API

listener

  • Microservice for the execution of listeners (Only one instance/Pod will run at a time).
    The following Listeners are the part of this microservice. For more details on how to work with these Listeners, refer to their respective pages.
  1. JMS (Topic)
  2. Spazio MFT
  3. MLLP
  4. SAP

aimapper

  • Microservice for AI based auto mapping.

license

Microservice to Register and enforce licensing

api-gateway

Microservice to serve as a single entry point for all the REST and SOAP API calls.

archival-and-cleanup

Microservice for log cleanup and archival.

rabbitmq

  • For facilitating asynchronous inter-service communication.
  • Back pressure handling: queueing jobs, routing to dedicated pods, Auto scale based on queue size.

PV/PVC

  • Repository for persistent storage of run-time temporary files and archiving.

Database

  • Backend Database – Stores all metadata related to users, transactions, configurations, partners.
  • Log Database – Stores all run time execution details, log information, and audit trails.

External communication 

Adeptia Connect has two ways to communicate over the public internet using REST over https and SOAP (Refer to blue arrows in the diagram).

Browser client : User will access Adeptia Connect using web GUI in Browser. Any user request from this UI is routed via webapp-gateway to portal microservice and web-runner microservice. This is a synchronous communication REST over https.

API Client: A user can access API published on Adeptia Connect using API client. The request is routed via api-gateway to rest-api or soap-api microservice depending on API using REST (HTTPS) or SOAP protocol.

Inter-service communication

The inter-service communication happen in two ways Synchronous using REST over https (Refer green arrows in diagram) and Asynchronous way via using RabbitMQ Message broker.

  1. Synchronous using REST over https (Refer green arrows in diagram): There are two type of request where this is being used
    1. web-runner micro-service :  All the GUI actions are API calls to web-runner micro-service which further do the inter service communication with all the micro-services connected using green arrow to execute the GUI actions.
    2.  API Microservice: rest-api and soap-api micro-services call runtime micro-service to execute the process flow published as API or Transaction published as web hook.
  2. Asynchronous way via using RabbitMQ Message broker: There are three type of communication happens using this method (Refer orange arrow in diagram)
    1. Queue Transaction and Trigger Transaction: As listener and event micro-services find new data to processed, they create a Job in RabbitMQ. Runtime service is listening on this queue and trigger Process flow or Transaction Execution.
    2. Maintenance Tasks: Any update in the application settings raises an event in the dedicated maintenance queue in RabbitMQ. All the microservices are the consumer of this maintenance queue and gets notified when the application setting is updated. This ensures automatically reloading of the application settings in the corresponding microservice.

Persistence

There are two types of data in Adeptia Connect that require persistence(Refer dotted arrow in diagram).

  1. Shared volume using PV/PVC
    1. Metadata files and dependencies
    2. Repository for persistent storage of run-time temporary files and archiving
  2. Database
    1. Backend Database – Stores all metadata related to users, transactions, configurations, partners.
    2. Log Database – Stores all run time execution details, log information, and audit trails.

Scalability

Individual micro-service in AC 4.0 are scalable and can scale up or down based on their respective scalability criteria and threshold.

  1. Runtime micro-service is scalable based on number of the messages in the RabbitMQ queue. If the number of messages in the queue exceeds the threshold (default 5) then new runtime pod is spin-up by the autoscaler. This threshold value can be configured in the values.yaml by changing the environment variable MAX_QUEUE
  2. All other Microservices are scalable based on the CPU and Memory utilization percentage . Autoscaler will spin-up a new pod if the CPU or Memory utilization of pod increases the threshold value. This threshold value can be configured in values.yaml by changing the targetCPUUtilizationPercentage and targetMemoryUtilizationPercentage under autoscaling section of the micro-service.

    listener and license micro-service will have only 1 replica set (single instance).
  3. Dependency Scaling

    An application that is architected, built, and run to be perfectly scalable in every way still faces scalability challenges if its dependencies cannot scale with it. Ensuring that all dependencies will scale with a microservice’s expected growth is essential for building production-ready services.

    As you scale microservices in the Adeptia application, you need to ensure that the underlying database is scalable and performant. With an increase in the number of microservices and the incoming requests, the interaction with the database increases. Therefore, the database shall be able to handle the surge in the requests by allowing more concurrent active connections and be able to return the result promptly.

    Similarly, with an increase in the number of microservices, the application interaction with the shared volume provisioned in the Kubernetes cluster through PV/PVC increases. As you scale the microservices in the Adeptia application, you need to ensure that the shared volume(PV/PVC) is sized to a correct value and configured for high performance for I/O intensive workloads.

Fault tolerance 

Circuit breaker prevents the cascading effect of a malfunctioned micro-service to other healthy microservices and provides fault-tolerance capability to the application architecture.

AC4 supports circuit breaking from the following three components of Adeptia Connect microservices architecture:

  • webapp-gateway
  • api-gateway
  • rabbitmq

How it works

With the help of the circuit breaker the Webapp Gateway/API Gateway/RabbitMQ is able to make or break the communication with a failed microservice. To determine whether a microservice is up or not, the Webapp Gateway/API Gateway/RabbitMQ allows twenty consecutive requests to the microservice – if the response to all the twenty requests fails, it instructs the circuit breaker to open the circuit and thereby break the communication.

After the circuit remains open for sixty seconds, the Webapp Gateway/API Gateway/RabbitMQ once again allows a few requests (in this case, five) to check whether the faulty microservice has started responding or not. In such a condition the circuit breaker is said to be in half-open state.

  • If the microservice responds to any of the five requests, the Webapp Gateway/API Gateway/RabbitMQ instructs the circuit breaker to close the circuit and thereby start the communication.
  • If the microservice doesn’t respond to any of the five requests, the Webapp Gateway/API Gateway/RabbitMQ instructs the circuit breaker to keep the circuit open and thereby break the communication for the next sixty seconds.

    This cycle continues until the microservice starts responding to the requests.

Technology Stack

Technology Stack section is still in progress and it's going to have content as we proceed to the GA release of the application.
You may be interested in...
  • No labels