Understanding The Three-tiered Architecture

Overview

Izenda is split into three levels: the Front End (UI), the Back End (API),and the User Store (database layer). These three components can be configured to support a fully standalone instance of Izenda as well as seamless, fully-integrated instances.

../_images/Architecture.PNG

Fig. 1 High-level User & API Interaction

The high-level interaction between these components is detailed below:

  1. The user navigates to the front end site.
  2. The Izenda UI is downloaded to the user’s browser.
  3. The Izenda UI makes requests directly to the API from the user’s browser. The network requests will originate from that user’s IP address. The API must be accessible to the user from their network location.
  4. The Izenda Config DB and reporting database(s) are only accessible to the API site. These databases do not have to be public, they can be on the same internal network as the API server.

For more informaton about embedding Izenda, please refer to our Developer Guide.

  • Izenda offers a number of Integration Options.

    • 0 : All Stand Alone
    • 1 : Back End Stand Alone, Front End Integrated
    • 2 : Back End Integrated, Front End Stand Alone
    • 3 : Fully Integrated

  • After deploying Izenda, ensure that the IzendaSystemSettings table in your Izenda Configuration Database contains the correct deployment mode value. For more about the SystemSetting table, click here.

  • The table below groups our current kits available according to their deployment method. These kits are provided for demonstration purposes and should not be used as production-ready solutions.

    Note

    Click on an thumbnail or scroll down to see more detailed versions of each diagram

Framework Deployment Mode 0 Deployment Mode 1 Deployment Mode 2 Deployment Mode 3
Standalone Application
../_images/Slide1.PNG
     
MVC  
../_images/Slide2.PNG
 
../_images/Slide4.PNG
Web Forms      
../_images/Slide5.PNG
Angular 2  
../_images/Slide3.PNG
   

Deployment Mode 0: Standalone Deployment

  • The Standalone Deployment style features a standalone front end and back end. The goal for this deployment is to quickly disseminate the Izenda platform as outline throughout the documentation.
    • Page layouts are immutable.
    • CSS Stylesheets and basic logo replacement available.
../_images/Standalone.jpg

Fig. 2 A diagram of Izenda’s standalone architecture.

BI Platform Implementation

../_images/Slide1B.PNG

Fig. 3 A diagram of implementation

Deployment Mode 1: Back End Standalone, Front End Integrated

  • The Back End Standalone Deployment syle features a seamless front end with a remote back end. This deployment is useful when you can devote a lightweight server to your integrated front end and a “meatier” server for all API calls which would include requesting queries from your reporting database(s).

MVC 5 BESA Implementation

  • Requirements:
    • API
    • Embedded UI
    • Empty database
  • MVC Starter Kit Back End Standalone found here
../_images/Slide21.PNG

Fig. 4 A diagram of implementation

Angular 2 Implementation

  • Requirements:
    • API
    • Embedded UI
    • Empty database
    • Angular 2 Starter Kit found here
../_images/Slide31.PNG

Fig. 5 A diagram of implementation

Deployment Mode 3: Fully Integrated

  • The Fully Integrated Deployment style features an integrated front end and back end. The goal for this deployment is to create a seamless experience for your user while making the code intuitive and maintainable.

    • Allows for Single Sign-On Authentication through your application.
    • Allows for full-page renders of Izenda as well as granular element renders to allow unique page configurations within your application.
    • Allows for tenant-level white labeling of colors, graphics, and page schemes.
    ../_images/Fully_Embedded.jpg

    Fig. 6 A diagram of Izenda’s fully integrated architecture

MVC 5 Implementation

  • Requirements:
    • API
    • Embedded UI
    • Empty database
  • MVC Starter Kit found here
../_images/Slide41.PNG

Fig. 7 A diagram of implementation

Webforms Implementation

  • Requirements: - API - Embedded UI - Empty Database
  • Webforms Starter Kit found here
../_images/Slide51.PNG

Fig. 8 A diagram of implementation

Switching Between Deployment Styles

While it is possible to switch between deployment styles, it is discouraged for a long-term deployment strategy.

  • The database layer is accessed differently in different modes and some values within the configuration database are unique to a particular deployment style. To switch a deployment from one style to another, a database administrator must update these values.
  • Izenda has a Console Application that will allow you to copy reports from one Configuration Database to another. This can help remedy potential data corruption and can be modified to schedule migrations. Nevertheless, the results may be extremely server intensive depending on your server resources and your data size. Please refer to the Izenda Copy Console for more information.

Alternative:

  • If you like the setup of the standalone style for report/dashboard designers but would like the seamless nature of the embedded style for end users, you can create a “designer” tenant in an embedded deployment with access to a fully rendered Izenda BI Portal. Reports and dashboards can then be copied from one tenant to another via Copy Management page.