Authentication can be performed within applications built on the Genesis low-code platform through many techniques. All of these techniques support Multi-factor Authentication (MFA) to bring additional security.
Types of control
Authorisation
The Genesis low-code platform has a collection of access control mechanisms to limit usage of your application and access to specific data and functions dynamically.
Single sign-on (SSO) authentication uses the underlying SSO technology. SSO is a mechanism that allows a user to be authenticated against a single system, and use that authenticated id across multiple applications - including those built on the Genesis low-code platform. This has the advantage that a user is required to log in only once, rather than once per system.
This page describes the various configuration options available for authentication. These are located in your application-name-auth-preferences.kts file.
Automatic import
Apache Camel integrations are defined within your application's jvm/-script-config/{app-name}-camel.kts file.
System definitions
Reading from an SFTP server
The Genesis low-code platform supports the use of Apache Camel in order to integrate with external systems, using its plethora of components.
To create integration tests for your Apache Camel routes, you need to create service tests by extending the AbstractGenesisTestSupport class and specifying the relevant application-name-camel.kts file as the scriptFileName.
The authorisation API consists of two main classes that enable you to add permission checks to your custom component.
Genesis supports some of the key annotations from javax.annotation and javax.inject, defined in Java Platform Enterprise Edition, using Google Guice as the internal dependency injection mechanism. In addition, Genesis provides some of its own annotations.
In most cases, you will create Event Handlers in a kts file using GPAL. This offers a method with succinct code and a good degree of flexibility.
Use these APIs to send and receive messages between micro-services.
Genesis is a low-code solution for financial markets. We try to provide as much of the platform via GPAL as possible, while allowing you to extend the platform with more powerful custom components and functionality.
In this page, we look at details of the functions that enable you to interact with the Genesis services that can be specified in the service-definition.xml file.
The system-definition file is the basis of all configurations. In this page, we describe the different functions available to get properties specified in the system-definition.kts file. Default methods have implementations to provide default values for each property.
In this page, we look in more detail at the functions that are the building blocks of the select statement in a Consolidator specification.
You define a Consolidator service in a consolidator.kts file. Within the file, you can define as many Consolidators as you like. Each one is specified in a Consolidator block of code.
For your Consolidator to run, it must be defined as a process and included as a service definition. Make sure you update the following files in your application:
Here is an example Consolidator file that defines two Consolidators:
A Consolidator exists to aggregate data or perform calculations whenever the underlying data is changed.
Integration testing
A more advanced example of custom endpoints
Custom endpoints are defined within their own submodule of the project, using classes implementing the WebEndpoint interface provided by Genesis-Router.
Configure Genesis Router
The example below is a collection of custom endpoints supporting SAML authentication. The LoginPostEndPoint, LoginUrlRequestEndPoint, LogoutEndPoint, and MetadataEndPoint all extend this AbstractSamlEndPoint.
The Genesis low-code platform provides a series of REST endpoints.
Integration testing
Enriching data from the Genesis database
Where to define
Configure processes.xml file
Here is a full example of ingesting trades:
Genesis Data Pipelines is a feature that allows you to stream data in and/or out of your Genesis application.
To test a data pipeline you need:
Client-enriched data
Let's make things really simple.
There are two important files in your application that contain configuration information:
Enriching a query
Data Servers monitor specific tables or views in the database. When a change in data occurs, the Data Server sends the updates to all its subscribers.
Integration testing
The generateSQLToRDB script
Configuration
GenesisToDb must be configured in your application-processes.xml file. The following is an example of how to do this:
Oracle Sample
The GenesisToDb module enables you to stream data from the Genesis low-code platform to classic RDBMS databases, such as Oracle or MSSQL.
You can not programmatically test integrations configured using the GenesisToDb module. However,
Dynamic rules
Enabling the Evaluator
You can see an example of a dynamic rule being configured in our tutorial.
It is often useful to run tasks periodically - for example to schedule the production of EOD reports, or to send a warning when a defined limit is reached. For such purposes, the Genesis low-code platform provides a feature called the Evaluator.
To see a working example of both static and dynamic Evaluators, please go to the Setting Genesis Rules page, where there is a working example of both.
Custom reply message type
Let's make things really simple.
There are two important files in your application that contain configuration information:
On this page, you can find useful examples of code for an Event Handler. We start with a very basic example, and then we provide further examples to cover key functions, such as exception handling and permissioning.
The Genesis low-code platform has a real-time event-driven architecture.
Integration testing
The following Excel functions are currently supported by ExcelToGenesis.
The Genesis low-code platform enables you to convert existing Excel spreadsheets into Genesis data models.
While the standard architecture of the FIX gateway is more than sufficient for most use cases, it is not ideal for more demanding architectures.
Streamer example:
The FIX Xlator is a plugin for the Streamer and Streamer client, which enables type-safe handling of FIX messages. It also gives access to a set of vital integration features, such as FIXIN, EXECUTIONREPORT and CUSTOM_FIX.
If your application needs to integrate with external systems, you need to be able to interpret incoming messages in the format of the external system and you need to be able to reformat information from the Genesis database when you send messages out to that system.
This page shows you how to create a Streamer.
This page shows you how to create a Streamer Client. It also looks at the syntax of the two types of Streamer Client that are available:
Genesis Platform Abstraction Language (GPAL) is our own scripting language, which plugs into IntelliJ.
GenesisSet is a generic message format used to send data between Genesis processes. The information in the messages must be stored as key-value pairs. A GenesisSet can store integers, booleans, text, etc. Importantly, it can also contain other GenesisSets.
In this area, we'll look at the standard message format sent between Genesis processes.
The following annotations are found in the package global.genesis.message.core.annotation and can be applied when defining Kotlin data classes to be used as input I message types.
The Genesis low-code platform uses type-safe messages to perform message serialisation and deserialisation. In addition, it automatically extracts relevant metadata to expose this to the front end in the shape of a Json Schema definition that is compliant with the 2019-09 specification. These messages will be validated automatically in the back end, based on their definition.
Event Handlers can be written in Java using Event Handler APIs. On this page, we look at Event Handlers written using the Rx3 Event handlers
With a database and two modules (a Data Server and an Event Handler) in place to supply data to the front end, we can now build our server.
There are some simple commands that enable you to start and stop your server.
This page gives details of the configuration requirements common to adaptors for all vendors.
Installation
The Genesis Notify module enables you to configure an application to send and receive messages to and from various messaging services.
Email configuration
The Genesis low-code platform provides a mechanism for creating pop-up toast notifications on screen in app. Any notifications sent to the Genesis Screen will be sent as a toast pop-up notification either on a company-wide or profile basis.
Microsoft Teams provides a mechanism for exposing its channels to a remote system via webhooks. A webhook url can be created as described here
Symphony is a secure instant messaging service focused on financial companies.
DbMon is the Genesis database client. It provides an interface to the underlying database and hides the details about the specific database technology. Generic database clients can be used with the Genesis low-code platform, but we recommend that you use DbMon. This page gives details of all the DbMon commands and provides practical examples of how you can use them.
Genesis has numerous built-in commands that have their own individual functions.
The application has three files that contain vital configuration information:
Pre-processing a request
Let's make things really simple.
There are two important files in your application that contain configuration information:
Below is a fairly simple requestReply codeblock with standard request and reply statements. The where block below filters out any data that does not meet the conditions. All data that is returned will have an instrumentCode equal to the request parameter INSTRUMENT_CODE.
Request Servers, (otherwise known as request/replies and often shortened to reqrep) retrieve a snapshot of data from a table or a view on demand and serve it up to the requesting client. They are predominantly used for serving the UI.
Integration testing
Authentication
Authentication
There are two important files in your application that contain configuration information:
The Genesis low-code platform automatically exposes all configured resources as REST endpoints via the Genesis Router. Unless configured otherwise, all requests require a valid SESSIONAUTHTOKEN HTTP header. A SESSIONAUTHTOKEN is retrieved after successful user authentication.
The REST Endpoints created by the Genesis low-code platform reflect your application's business logic. These endpoints can be configured through the Genesis Router.
Database caching on local microservices is supported out of the box. You can configure a caching layer for any Genesis module. The cache can reduce the database workload for tables that contain static data.
The Genesis low-code platform supports the following database technology:
Genesis Router is responsible for all communication between front end and back end.
Some files are essential to the development and running of your application. You need to know what they are for and how to configure them. The pages in this section provide the details.
Your application must have a -processes.xml file. This contains the configuration of each module in the application (Data Server, Request Server, Event Handler, etc). It is created automatically when you start a new Genesis project using GenX CLI tool, but you might well want to update it - and you certainly want to take a good look at it.
Every application must have a -service-definitions.xml file. This is where you specify the ports of the various processes. These are used to communicate internally between processes.
The system-definition file genesis-system-definition.kts is the main configuration file for your application. This section explains all the different items that can be contained in the file.
Set-up
This document describes the recommended uses of config management with Genesis frameworks. It is written for a reader with some
This section describes installing an application built on the Genesis low-code platform. Readers need to have some experience of Linux system administration .
This section describes preparing a host to run applications built with the Genesis low-code platform. Readers need to have some experience of Linux system administration.
The following code snippets can be imported into IntelliJ to speed up repetitive development tasks, mainly around the declaration of Genesis scripts and configuration.
The Genesis Intellij plugin allows developers to run the full stack of a Genesis application locally within IntelliJ, in order to better test their development work.
The State Machine can be injected to the Event Handler script or API.
You define your State Machine as a specific type of Event Handler.
State Machines are defined as Event Handlers in your application's eventhandler.kts file. Ensure that your Event Handler is correctly configured for runtime.
The following example of a State Machine defines five events that control the transition of trades from one state to another.
One of the key things you need to define in your data model is the various states that your financial entities (such as orders or trades) can go through - for example, new, amended, completed or cancelled.
Integration testing
Integration testing