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

Compare with Current View Page History

« Previous Version 4 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

Webapp Gateway
  • Microservice for providing custom API to each client to connect with the requested Microservice.
  • Invokes multiple Microservices and aggregates the results.
  • Microservice for serving GUI to configure entities and view logs.
Web Runner
  • Microservice for serving UI data.

  • Microservice for scheduling of events

  • Microservice for Process Flow execution


  • Microservice for web service provider execution.

  • 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
AI Map
  • Microservice for AI based auto mapping.
LicenseMicroservice. TBD
API GatewayMicroservice for handling Webservices calls.
Archival and cleanupMicroservice for log cleanup and archival.
  • For facilitating asynchronous inter-service communication.

  • Back pressure handling: queueing jobs, routing to dedicated pods, Auto scale based on queue size.

  • Repository for persistent storage of run-time temporary files and archiving.
  • 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 prevents the cascading effect of a malfunctioned microservice to other healthy microservices.
  • Provides fault-tolerance capability to the application architecture.

Where it is applied

It rests and operates 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.

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

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