Platform dependencies

Mobiz development setup and mocking capabilities.

Service Dependencies

Service dependencies are subsystems which Mobiz Platform requires to have running and accessible to be able to operate.

External data from ERP is stored in ElasticSearch.

Elastic Search is a key service component for the Mobiz Platform to deliver fast response to all client read calls.

We utilise Elastic Search for basic data navigation as well as doing complex search. In addition we are heavily utilising the surprisingly deep data-aggregation functionality provided by ElasticSearch which can be used for all kinds of calculations and data mining operations across huge datasets.

In general we look at all data in ElasticSearch as disposable since it should be possible to rebuild all indexes from scratch by running the bootstrapping process. However, with many TB in the index you probably would not want to go down that route. Therefore we provide lots of infrastructure support for managing and migrating the data index.

Service Dependency: PostgreSQL

PostgreSQL serves as the master store for all control data. This includes storing security information, permission authorization, Organizations, Users, Membership, Settings, etc.

This makes the PostgreSQL storage the single most vital and sensitive point of data storage in our architecture.

Service Dependency: Redis

Redis is used for caching and cluster-wide notification deliveries via its Pub/Sub mechanism.

Software Dependencies

Software dependencies are packages / libraries / projects utilised in the Mobiz Platform codebase which are important enough to be awarded honorable mention as software dependencies.

Dependency: .NET CORE Platform

The backend service platform and all derived modules are built on .NET CORE architecture.

We follow latest development on the platform and ensure the platform is up to date with best practices in the .NET World.

Some basic details about the .NET implementation:

  • Backend services are implemented as WebAPI Controllers.
  • Notification subscription endpoints are SignalR hubs powered by Redis for cluster-wide delivery.
  • We build on the ServiceCollection DI pattern adding support for scoping services against Mobiz Platform concepts like: Organization, User, AdminDomain.
  • Database access is via Dapper and DapperExtensions. We prefer Dapper over Entity framework given how ultra-lightweight it is and fast.
  • Database migrations are managed via FluentMigrator project.
  • ElasticSearch and Redis clients are standard .NET official clients.
  • Mobiz Authentication is built on ASP.NET Identity infrastructure.

Dependency: Hangfire

Hangfire is a powerful .NET library for managing and running tasks.

https://www.hangfire.io/

Hangfire is included in the deployed artifacts of the platform.

Our plan for 2021 is to replace Hangfire with our own Agent based job execution engine.

.NET: Microsoft Orleans

Orleans is used for providing the pillars for event driven architecture.

Concepts like:

  • Stream
  • Grains / Virtual Agents

This is exactly what we need to build a powerful stack of services around the flow of data coming from the external ERP system which can be managed in a powerful, event driven model using Orleans constructs.

Deployed Artifacts

Looking at the artifacts of a Mobiz Platform based solution on the backend server, it is most straightforward to consider the system layout from the perspective of Docker instances / images.

A Mobiz Platform system deployment on AWS will consist of the following components / Docker images:

  • Mobiz.Web (clustered)
    • In other installations this might be named by the installation identifier, example: Posturinn.Web
    • Includes the Mobiz Platform and all installed extensions.
  • Mobiz.OrleansHost (clustered)
    • Host for Microsoft Orleans Grains and related logic.
    • Includes the Mobiz Platform and all installed extensions.
  • Mobiz.CDC (not-clustered)
    • Change Data Capture logic for synchronizing between SQL Server and Mobiz Platform Installation.
  • Mobiz.AdminConsole (not-clustered)
    • Administration Console for managing Mobiz Platform Installation.
  • Mobiz.MigrationRunner (not-clustered)
    • Database initialization and migration management. Only executed on cluster startup.
  • Sentry (not-clustered)
    • (Optional) for managing logs and feature tracking.
  • Grafana (not-clustered)
    • (Optional) for providing dashboards against ElasticSearch and other data sources in production.

Docker images will contain the required extensions for the given deployment.

AWS Cognito integration from Mobiz.Platform

The Mobiz Platform has a built in identity provider supporting oauth 2.0, and providing APIs for managing user accounts (e.g., create account/confirm email/confirm identification number/ change password etc). The Mobiz Platform is able to synchronize user accounts in Cognito. However, the main user store for logging in, changing user attributes is still in Mobiz. The mobiz platform makes sure to always synchronize basic user attributes to Cognito when these are changed in Mobiz: full name, email, phone number, password.

Flow for creating new users in Cognito:

  • user creates an account and logs in the Mobiz Platform
  • once it succeeds, the Mobiz Platform invokes the log-in in Cognito
  • the user will not exist in Cognito, and therefore the User Migration Lambda will be invoked
  • the user migration lambda connects to the Mobiz User Repository and returns back the user by username
  • Cognito will create the returned user from the Lambda function
  • once the log in call to Cognito finishes successfully, user gets access/refresh tokens issued by the Mobiz Platform When users re-authenticate, they will also exist in Cognito. They will always be in sync in Cognito with the Mobiz User repository through a sync mechanism implemented in the Mobiz Platform.

Login with Audkenni

  • bundled within the Mobiz Platform (for Cognito there is no difference between users that log in with static credentials vs e-certificate)
  • The Mobiz Platform receives an API Call for logging in for a phone number; the platform requests the authentication in Audkenni, and waits until the user approved manually via the popup he sees on the phone
  • once approved, the Mobiz Platform received a signed response with a certificate, containing the user’s identification number and full name;
  • the Mobiz platform creates or updates the user in the Mobiz User Repository and triggers the login in Cognito, which has the same flow described above
← Mobiz Development