Architecture
Last updated
Last updated
The TIVITY platform is designed as a mobile-first single page application. The requirements of a SPA were implemented on client-side using the libraries require.js, knockoutjs and crossroads.js. The implementation was developed with the architecture pattern MVVM. The UI has been implemented on the server side with the ASP.NET MVC framework. It uses the MVC Views (almost) not at all, because the task of presentation is done with the client-side MVVM contents. Communication between client and server takes place using AJAX requests. The parameters in query objects and data in the response object are transmitted over the network in form of JSON objects.
Requests are forwarded from the routing engine of the MVCs to the correct actions in the controllers and processed there. The actions instantiate a worker, from whom the action knows the type. This means that the action does not have to worry about the actual work but serves only as a interface to arbitrary clients. Therefore this interface is easily exchangeable. With the worker classes the accesses to the business logic are made possible by different adapters.
API Service is the programmer interface of the TIVITY platform and serves to connect external systems to the platform. The API is available as REST service. Components are the ApiController that process requests and send the results back.The API providers access the business logic.
The adapter and all inherited adapters (from AdapterBase) are the interface between the source framework (data access layer) and the presentation layer. These adapters are part of the business logic (BusinessLogic/Application Layer).
The Package Manager handles the export and import of app packages (as PACK files), for later installation, update and uninstallation of apps. For all functions, the package and the individual components in the package are validated. During installation, migrations are performed so that old packages can be installed in new platform versions.
The source framework is a component in the data access layer that encapsulates access to the source (persistent data / information sources) and the techniques used. The framework includes the source adapters and the query processing (processor) as well as the capability operations
The query engine is a TIVITY platform component that expects a query as input. This query is translated into the target data source that supports the query. The fields in the query hold the required columns/properties that were retrieved from the target data source. Conditions provide the filter criteria to get the desired results from the target source.
For example, the target data source is a database (e.g. MSSQL Server). In this case the query is translated into SQL (for MSSQL Server T-SQL). The data source executes the translated query and returns a list of models as a result. Finally, the models are edited in the selection engine - by pagination and enrichment of meta information.
The Source Adapter is a component for generalized access to information sources, such as databases (MSSQL), objects (Exchange) or documents. In addition, a generalized result is returned by the respective adapter (Key-Value Format). The individual adapters can be used for several data sources of the same type, i.e. one adapter insert per data source.
The Source Adapter analyses a data source and returns available structures of the data source. The available structures allow a user of an adapter to query or manipulate instances. This is achieved by basic operations of persistent storage (CRUD - Create, Read, Update, Delete), e.g. you can query a table at a database source and delete entries. The available structure of a data source can display possible actions in the presentation layer for Business Logic.
The implementation was based on a Microsoft .NET Technology Stack. The OS used is Windows Server 2012. The platform is hosted on an Internet Information Server (IIS). An MS SQL Server is used as a persistent data storage. Builds and deploys are then performed using Azure DevOps services. On the client side, knockout and bootstrap are used. Kendo JS is used for various UI components. Markup Language of the SPA (Single Page Application) is HTML5 and stylesheets are used in the version CSS3.
There are currently two physical servers. The release candidate and development server is the Dev / Stage Server. The production environment is the Productive Server
The apps are configured centrally via a master database. On the one hand, so-called "Migration Steps" are used to import Config-Master-DB extensions that affect the code and app configuration. On the other hand, apps can be developed via the admin interface of the (master) platform. These configurations of the Config-Master DB are synchronized/adjusted with the Stage-Config DB the staging platform is going to. When deploying to the production platform, the StageConfig DB is synchronized. The current configurations of master and staging are located there. At the same time the website is published on Production.
