Architectural overview

At the core of the Zenoo Hub is a workflow engine that executes Hub DSL scripts.
The DSL scripts are used for orchestrating digital-onboarding processes as a series of pages, data transformations and external calls.

The DSL-based approach makes it possible to specify digital-onboarding processes in a concise manner. It enables developers to focus on the business logic rather than the complexities of distributed systems.

The Zenoo Hub is built on top of Apache Kafka using event-streaming and micro-service architecture.
It makes the Hub highly scalable and fault-tolerant.

Each workflow execution produces a detailed log of Execution events that can be used for troubleshooting, as well as, analytic purposes.

DSL execution engine

At the core of the Zenoo Hub is the DSL execution engine.
It executes the Hub DSL scripts that are used for orchestrating digital-onboarding processes. The host language for DSL is Groovy.

The DSL scripts are versioned and stored in a Component repository as Hub Components.
The Hub employs a component model to facilitate reusability, testability and configurability.
Making it possible to build new components from existing ones.

Each workflow execution is assigned an Execution Context that stores the current state of the execution.
The execution contexts are persisted and retrieved using a Kafka Streams state store.
Leveraging Kafka fault-tolerance capabilities, a replicated changelog topic is maintained to track any state updates.

Each workflow execution produces a detailed log of Execution events.
These include life-cycle events, execution requests, responses, errors, executed commands, results etc.
The execution events can be very useful for troubleshooting, as well as, analytics purposes.

More details can be found here.

Hub Client

A Hub Client facilitates an interaction between the Hub and an end user.
From a Hub Client perspective, a customer journey is a series of pages. It relies on the Hub to determine what page to display next.
Apart from that, it gathers user input and submits data back to the Hub via Hub Client API.

A Hub client uses the Hub Client API for the following

• to start a new execution using a target or sharable token
• to submit user input and resume the execution
• to query execution state and current route
• to upload files using File cache
• to execute route functions

Component repository

The Hub DSL scripts are stored in a Component repository as Hub Components with the support for versioning.

A component model is employed to facilitate reusability, testability and configurability of Hub components, enabling a development model where new components are built from existing ones.

The Admin API makes it possible to register, query and validate Hub components on-the-fly. This enables making changes without the need to rebuild and redeploy the Hub.

Connector exchanges

Connectors are the integration points of the entire workflow orchestration. They are wrapped by exchange commands used within the DSL.

Throughout the workflow execution, external/internal providers can be called by means of exchanges that trigger the connectors. The connectors fetch results and decide in each step what to do with the provider responses accordingly.

• Exchange processor
  • processes connector requests
  • handles connector failures using retries with different retry strategies and timeouts
  • produces execution requests with connector responses
  • connectors with reactive interface

Monitoring

The Zenoo Hub employs Micrometer—a vendor-neutral application metrics facade—to integrate with the most popular monitoring systems.

Micrometer has a built-in support for AppOptics, Azure Monitor, Netflix Atlas, CloudWatch, Datadog, Dynatrace, Elastic, Ganglia, Graphite, Humio, Influx/Telegraf, JMX, KairosDB, New Relic, Prometheus, SignalFx, Google Stackdriver, StatsD, and Wavefront.

More details can be found here.