Skip to main content

106 docs tagged with "server"

View All Tags

Access Control - Authentication Overview

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.

Access Control - Introduction

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.

Access control - SSO authentication

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.

Consolidator - basics

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.

Consolidator - configuring runtime

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:

Custom Endpoints - examples

The example below is a collection of custom endpoints supporting SAML authentication. The LoginPostEndPoint, LoginUrlRequestEndPoint, LogoutEndPoint, and MetadataEndPoint all extend this AbstractSamlEndPoint.

Custom Endpoints - introduction

The resources you create via the Request Server, Data Server and Event Handler are exposed to the front end as a series of REST endpoints.

Data Server - introduction

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.

DB Streaming Out - introduction

The GenesisToDb module enables you to stream data from the Genesis low-code platform to classic RDBMS databases, such as Oracle or MSSQL.

DB Streaming Out - testing

You can not programmatically test integrations configured using the GenesisToDb module. However, you can manually reproduce changes by inserting, modifying or deleting data in Genesis and then querying the target RDBMS.

Evaluator - introduction

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.

Evaluator - testing

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.

Event Handler - examples

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.

FIX Gateways and Streamers - FIX-Xlator

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.

FIX Gateways and Streamers - introduction

If your application needs to integrate with external systems through a FIX gateway, 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.

Inter-process messages - GenesisSet

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.

Inter-process messages - type-safe messages

The Genesis low-code platform uses type-safe messages to perform message serialisation and deserialisation. In addition to this, it automatically extracts relevant metadata to expose this to the front end. These type-safe messages are most commonly used in Request Servers, GPAL Event Handlers and Event Handlers that have been implemented as a set of classes.

Java Event Handlers

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

Notify - Configuration

The Genesis Notify module enables you to configure an application to send and receive messages to and from various messaging services.

Notify - Microsoft teams

Microsoft Teams provides a mechanism for exposing its channels to a remote system via webhooks. A webhook url can be created as described here

Notify - Symphony

Symphony is a secure instant messaging service focused on financial companies.

Request Server - examples

You define your application's Request Server in a kotlin script file called application-name-reqrep.kts.

Request Server - introduction

Request Servers (otherwise known as request/replies and often shortened to reqrep) provide snapshot data from a table or view in response to a request from the front end. Once the response is received, the transaction is over (unlike a Data Server, which stays connected to the client and pushes updates).

REST endpoints - introduction

The Genesis low-code platform automatically exposes all the resources you have configured 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.

REST endpoints - testing

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.

Server configuration - Cache

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.

Server Configuration - Introduction

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. These pages provide the details.

Server Configuration - Processes

Each application must have a -processes.xml file. This contains the configuration of each module (data server, request server and event-handler etc). It is generated automatically when you create a new Genesis project using GenX CLI tool.

Server Configuration - Service Definitions

Just as each application must have a -processes.xml config file, it must also 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.

Server Configuration - System Definitions

The system-definition file genesis-system-definition.kts is the basis of all configurations, scripts, data model, etc. This section explains all the different items that are contained in the file.

Server set-up - config management

This document describes the recommended uses of config management with Genesis frameworks. It is written for readers with some Linux system administration experience.

Server set-up - host preparation

This section is for users with experience of Linux system administration. Here we describe preparing a host to run applications built with the Genesis low-code platform.

Server tooling - code snippets

The following code snippets can be imported into IntelliJ to speed up repetitive development tasks, mainly around the declaration of Genesis scripts and configuration.

State Machine - Configuring runtime

State machines are defined as Event Handlers in your application's eventhandler.kts file. Ensure that your Event Handler is correctly configured for runtime.

State Machine - examples

The following example of a state machine defines five events that control the transition of trades from one state to another.

State Machine - introduction

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.