Search

Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.
  6. Tenant boundary based on Partner and Process flows.

The Application Architecture diagram for Adeptia Connect is shown below.

Image RemovedImage Added

Anchor
Key Components
Key Components
Key components

Microservice for the execution of Listeners

Component

Description

Webapp Gateway

webapp-gateway

  • Microservice for providing custom API to each client to connect with the requested Microservice.to serve as single entry point for communicating with all the Microservices
  • Invokes multiple Microservices and aggregates the results.
Portal

portal

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

web-runner

  • Microservice for serving UI data.
Events

event

  • Microservice for scheduling of events.
Runtime

runtime

  • Microservice for Process Flow and Transaction execution
.

Webservices

  • Microservice for web service provider execution.

Listener

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 listeners are the part of this microservice. Only one instance/Pod of these Listeners is allowed to run at a time.
    For more details on how to work with these Listenerslisteners, refer to their respective pages.JMS (Topic)
    1. JMS
    2. Spazio MFT
    3. MLLP
    4. SAP
AI Map

ai-mapper

  • Microservice for AI based auto mapping.
License

license

  • Microservice to register and enforce licensing.
TBD
API Gateway

api-gateway

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

archival-and-cleanup

  • Microservice for log cleanup and archival.
RabbitMQ

rabbitmq

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

PV/PVC

  • Repository for persistent storage of run-time runtime temporary files and for 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

and inter-service

communication 

External and internal communication in Adeptia Connect happens in the following manner.

  • Synchronous external communication happens using REST protocol over https.
  • Synchronous inter-service communication happens using REST protocol over https.
  • Asynchronous inter-service communication happens using RabbitMQ Message broker.

Circuit breaker in Adeptia Connect environment

What and why

Circuit breaker

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 interface 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 using 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 whether the API uses REST (HTTPS) or SOAP protocol.

Inter-service communication

The inter-service communication happens in two ways – Synchronous using REST over https (Refer to green arrows in the diagram) and Asynchronous using RabbitMQ Message broker.

  1. Synchronous using REST over https (Refer to green arrows in the diagram): There are two types of requests where this is being used.
    1. webrunner micro-service: All the calls for GUI actions go to the webrunner microservice, and the webrunner in turn initiates the inter-service communication with the other microservice via webapp-gateway.
    2. API microservice: rest-api and soap-api microservices call runtime microservice to execute the process flow published as API or Transaction published as webhook.
  2. Asynchronous way using RabbitMQ Message broker: There are three types of communication that happen using this method (Refer to the orange arrows in the diagram).
    1. Queue Transaction and Trigger Transaction: As listener and event microservices find new data to process, they create a Job in RabbitMQ. Runtime service listens to this queue, and triggers the execution of the Process Flow or Transaction.
    2. Maintenance Tasks: Any update in the application settings raises an event in the dedicated maintenance queue in RabbitMQ. All the microservices are the consumers of this maintenance queue and get notified when the application setting is updated. This ensures automatic reloading of the application settings in the corresponding microservice.

Persistence

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

  1. Data in shared volume using PV/PVC
    1. Metadata files and dependencies.
    2. Repository files generated at runtime and their archive.
  2. Data stored in the database
    1. Backend Database – Stores all metadata related to users, transactions, configurations, partners.
    2. Log Database – Stores all runtime execution details, log information, and audit trails.

Scalability

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

  1. Runtime microservice 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), the autoscaler spins up a new runtime pod. This threshold value can be configured in the values.yaml by changing the value for the environment variable MAX_QUEUE.
  2. All other Microservices are scalable based on the CPU and Memory utilization percentage. Autoscaler spins up a new pod if the CPU or Memory utilization of the pod increases beyond the threshold value. This threshold value can be configured in values.yaml by changing the value for the environment variables targetCPUUtilizationPercentage and targetMemoryUtilizationPercentage under autoscaling section of the microservice.

    Info
    The listener and license microservices have only one replica set (single instance) each.


  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 results 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 

Fault tolerance is the capability that enables the application to continue operating properly in the event of the failure of some of its components. Adeptia Connect application provides fault tolerance capability using Circuit Breaker and Timeout.

Timeout

Any REST Https call from one service to another via gateway implements Timeout mechanism. If it takes longer than the configured timeout to respond to a REST Https call, the call is treated as failed. 

Circuit Breaker

Circuit Breaker prevents the cascading effect of a malfunctioned microservice to other healthy microservices

.Provides

and provides fault-tolerance capability to the application architecture.

Where it is applied

It rests and operates from In AC4, the circuit breaking is implemented using the following three components of Adeptia Connect microservices architecture:

  • Webapp Gateway
  • API Gateway
  • RabbitMQ
How it works

the application.

  • webapp-gateway
  • api-gateway
  • rabbitmq

How Circuit Breaker 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 20 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 60 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.

We need to mention this error message into the “troubleshooting runtime issues” document

Error 503 when sending request to a failed microservice is logged in application logs. The error message is...

Technology Stack

Note
Technology Stack section is still in progress and it's going to have content as we proceed to the GA release of the application.


Panel
borderStylesolid
titleYou may be interested in...
What's new
Key terms
Install
Usage scenarios