Installation and Setup Videos

BI Portal Installation

A comprehensive walk through of installing a BI Portal instance of Izenda.
Who Should Watch: Individuals setting the system up for BI Portal instances for trial or deployment purposes.
What You Will Learn: Everything from download to logging into the application for the first time.

Video Transcript

This video is a step-by-step guide to installation of an independent BI Portal instance of Izenda. This guide will work under the assumption that the user has downloaded the appropriate file directories from the Izenda download site.

This includes the Izenda front-end package which has the default name of “App”, and the Izenda back-end package with the default name of “API”. Additionally, for the hosting server for this instance, the user should utilize Windows Server with Internet Information Services, or IIS, Web Server for setup. Also, be sure to open the Installation guide from the Izenda Wiki as an additional resource that can be useful as you follow along.

The user will notice that the front- and back-end packages are currently compressed. Extract the contents of these packages into an easy to find location. Izenda recommends something like C:\inetpub\wwwroot\izenda\App and Izenda\API.

Izenda can be installed in a number of configurations including as a new application to an existing website or a new virtual application under an existing website. In this case, the user will right click the local connection and select the “Add Website” option from the menu. Then the user will give the new website a name, in this example, we’ll name the site “IzendaApp”. In this walkthrough, we will leave the Application pool name the same as the website’s name.

Next, click the ellipses next to the Physical Path and then browse to locate your extracted Izenda front-end Package. Point this Physical path to the App directory. In this example, that would be the Izenda\APP folder. Then, select a Port number for this site to utilize. For this example, we will leave the port number as 80.

Optionally, a user can enter a website address here into the host name box. If this is done, the user will need to go into C:\WINDOWS\System32\drivers\etc\hosts and make the following modifications to that file:

Once this setup is complete, hit the “OK” button to proceed.

This same process will need to occur to properly set up the back-end package (API) with the only difference being the port number. So, once again, the user will right click to Add Website, enter in IzendaAPI as its name, change its port to 81, and select “OK” to move on.

Now that the sites are set up, it is important to ensure these sites have the proper permissions. To set folder permissions, right click on the newly created website and select the “Edit Permissions” option from the menu to open folder properties.

In the Security tab, click the edit button to open the Permissions dialog box. Click the “Add” button to enable a new group or user name to be added, and then type IUSR (eye-user). Once you are back in the Permissions dialog box, tick the Modify checkbox for IUSR. Repeat this process and instead of IUSR, add “NETWORK SERVICE”, tick the Modify checkbox, and select “Apply”. Once this is done, click OK to close all dialogs.

Like the website setup, we will also need to do this for the other package. Select the second website, navigate to folder permissions and add IUSR. Make sure to tick the Modify checkbox prior to applying these modifications.
Now that the sites are setup properly, we need to make sure that they can communicate with each other. For this, we’ll need to update the backend API URL in the front-end package. This file is located in the App package in the file named “Izenda_config.js”. Open the file in order to edit its contents. Here, we will change the line “WebApiUrl” to point at our API site we just set up. In this example, we will relocate it to point at localhost and our API port number; 81.

There are also additional options for increased security on your newly setup site. To view those options, please refer back to the Wiki’s installation guide.

Once all of these settings and configurations have been set, IIS needs to be reset prior to launching the new site. For this, open up a Command line in Administrator mode. Once this is open, type “iisreset”. After a few moments, IIS should be reset, and your websites should be ready to open. To open a website, navigate back to IIS and select the App website. With it selected, on the right side of the screen, there should be a “Browse(PORT NUMBER)” option. Clicking this should open up an instance of Izenda in your preferred web browser.

Once this is open, we can now gather our connection string to the database we will use as Izenda’s Configuration database. Here, we can use the connection string builder, or if we know our connection string already, simply enter it in. Once in place, the user should hit the “Connect” button and if successful will be prompted back to the login page. If this happens with no errors, then we have successfully installed an independent BI Portal instance of Izenda and can begin loading in connection strings of reporting databases to begin using the self service BI Platform.

BI Portal Next Steps

This video covers the steps taken after initially setting up Izenda in the BI Portal Installation video.
Who Should Watch: Individuals setting the system up for BI Portal instances for trial or deployment purposes.
What You Will Learn: How to initially set your license key, token, reporting databases, tenant/role/user setup, and various security settings.

Video Transcript

Once you have successfully installed your independent BI Portal instance of Izenda, there are additional steps that need to be taken in order to have the deployment report-creation ready. This includes setting up connection strings to reporting databases and pulling in those relevant data sources, creating tenants, users and roles, assigning various permission rights to those tenants, roles and users, and optimizing data sources through constructing data source categories and aliasing.

For the purposes of this video, we will be using a deployment of Izenda that has already linked to the configuration database as seen in the Standalone Installation guide video.

The initial sign in to the deployment will utilize the default Izenda login credentials in order to begin doing some system level administration. This login uses the username “IzendaAdmin” and the password “IzendaAdmin123”.

The first step to make sure our license is valid, and we can use the system is to enter and test our license key. The license key runs in two modes: offline and online. For online mode, we will just need our license key, copy it into the box, and then hit the validate button. For offline mode, we will also need a token, but the steps will remain mostly the same. Once we hit validate, if the system approves of the key, we can now see how long the license will last and see all of the modules we have access to. For the purposes of this demo, we will set this instance up in multi-tenant mode before moving on.

Once in the system, we will need to create a couple of tenants in order to begin adding reporting data sources. Navigate to the “Settings” tab and select the Tenant Setup option on the left side of the screen. With this tab open, select the “Add Tenant” button above the search bar. Here, you will enter in a desired Tenant ID, Tenant Name, and optional description for your tenant. As well, there are various options from this visualization to manage a tenant’s access to interact with various modules of the application.

Clicking the “Permissions Tab” will allow a system level administrator to go into more depth as to what their tenant’s will be able to access. This includes the ability to manage a tenant level administrator’s access to certain self-administration rights within the system. For instance, if a system level administrator wants sole ownership of the system’s Role Setup functionality, the system admin could select the “Tenant Access” checkbox in order to remove self-administration around Role Setup from that tenant. Once a tenant’s setup meets the desired setup, make sure to hit the “Save” button at the top of the screen before moving on.

With one or more tenants setup, we can now move into adding reporting data sources to our deployment. Most management of data sources can be handled inside the “Data Setup” section on the left side of the screen. To begin bringing in these data sources, we will need to start in the “Connection String” sub tab under the Data Setup area. This is where connection strings to reporting data sources will be entered in and Izenda will go through each database and pull out any tables, views, stored procedures, or user defined functions, as well as automatically create joins based on primary and foreign key relationships.

For a system level administrator, it is important to pay attention to what setting level they are currently working under. If the setting level drop down says “System” and data sources are added, these will be added at a “System” level and be inaccessible to individual tenants. Therefore, in order to add connection strings to reporting databases for specific tenants, we will utilize the system level drop down to impersonate the newly constructed tenant. Now, we can select what type of database we are about to point to, enter a connection string to that database, and then hit the “Test” button to ensure our database connection string was accurate. If we get a successful response from the system, we can then hit the “Connect” button for Izenda to begin sorting through the various Tables, Views, Stored Procedures, and user defined functions within the database.

Those values will be populated in the Available Data Sources area below. This is where a system level administrator could come in and begin choosing what specific data sources will be eligible for reporting purposes by moving them into the Visible Data Sources area. To do this, simply expand out one of the categories and click on a desired item to move it over. Once everything looks good, be sure to hit the “Save” button prior to moving on to avoid losing any changes.

With this all in place, management around the data model can be done in the “Data Model” area. This is where data sources can be grouped into data source categories, tables/views/ and stored procedures can be aliased to make them more accessible to end users, and even field names can be aliased to make it easier to build reports. This is also where decisions around whether or not fields will be filterable or visible for users of the system. From this area, prebuilt relationships can be seen in the relationships tab, and new relationships between data sources can be built through the “Add Relationship” functionality.

Once the data setup fully meets expectations, BI Portal instances of the system allow for the setup of roles and users. Roles share much of the same permissioning functionality that was observed in the Tenant setup area, but here, individual roles can be granted or restricted access to the data model on a very granular level. Utilizing a similar mechanism to the Connection String area, here, decisions can be made as to whether or not users of a specific role will be able to access various data sources for reporting purposes. To grant a role access to manipulate a data source, they would simply need to select the desired object, and use the arrows to move it to the appropriate side.
Outside the realm of Available Data Sources, there is also a very granular breakdown of various report, dashboard, and miscellaneous permissions that can be managed from this area.

User setup is a fairly straight forward concept for users in a BI Portal instance. Various data will need to be entered in to create a user, and a role must be selected in order to move forward. For demo purposes, it may be beneficial to check the “System Administrator” checkbox in order to give someone full access to the system. But, once this setup is complete, hitting the save button will lock all of that data in for that user. Then, to activate the account, the “Configure Password Option” button can be used to generate a URL for that user to navigate to in order to complete the setup process and make that user “active”.

If desired, from the administration UI in this section, password complexity, security questions, and various other settings can be manipulated to further lock down the system.

Permissions: Categories/Access/Sharing

This video analyzes some of the different permission capabilities around dashboards, reports, and other internal users of the system.
Who Should Watch: System and Tenant level administrators.
What You Will Learn: Category management. Sharing rights and access defaults between internal users of the system. Administration UI permission elements.

Video Transcript

Izenda offers a wide range of options for customizing an end user’s experience within the self-service platform. One of the most important examples of this is the ability to customize a user’s access to features, data, reports, and dashboards. Through Izenda’s vast permission setup options, an administrator can make decisions to maintain data security and fully mold a tenant, user, or role’s experience in the platform. For the purposes of this video, we are going to use an independent BI portal instance to explore some of the functionality surrounding permissions offered in Izenda.

Category permissions are a way to keep reports and dashboards organized, while limiting accessibility to only desired roles. When managing category permissions, an administrator can determine what report or dashboard categories a given role will have access to view or save into. Anything in the Available Category column will be hidden to the selected role and inaccessible for any viewing or customizations.

In addition to assigning category permissions to roles, there is also a concept of assigning permissions to individual reports and dashboards. This comes in many different permission levels and methods of assigning these permissions. From the Role Setup screen in the Administration UI, an administrator can set up access defaults and limits in regards to sharing.

Access Limits give administrators the opportunity to decide what other roles or users a given role will have access to share with. For instance, if the administrator is setting up the Manager role’s Access Limits, only those roles or users in the “Role/Users allowed to share with” panel will be available for the Manager to share reports and dashboards with. In this case, if the administrator decides that the Manager role should have access to share with the Accounting role or users within that role, they would merely need to select the role itself and move it into the proper panel. Once the role is saved, these changes will immediately be applied to the Manager role and any users contained in that role will be able to share reports and dashboard with the Accounting role.

Any criteria added to the Access Defaults area within this role will create a system where anything constructed will be automatically shared with the assigned access rights to whatever role or user is specified. For example, if the administrator wants to create a rule where everything the Manager role creates is automatically hidden from the Accounting role, the admin would select the Add Access Default button, select the desired Role or User, and then choose the “No Access” option from the Report or Dashboard Access Rights drop down. This same functionality can be seen on the report designer or dashboard view with the same values seen in the Access Defaults area.

Each Access Rights type has a specific function. Full Access gives complete access to the base report allowing the role or user to edit and save over the baseline report. No Access hides a report or dashboard from a role or user’s environment. Quick Edit gives users a nice way of interacting with a report with limited options for customization, while only allowing for users to save their own copy without disturbing the underlying base report. Save As gives roles or users the opportunity to make full customizations – including manipulating the data sources on the report – while also preventing saving over the baseline report. The last two options are both a great way to utilize templates to be interacted with and manipulated in order to create quick, custom, ad-hoc reports and dashboards. View Only would be useful for canned report viewers as it allows them to interact with filters to adjust the data populating a report or dashboard without the need to save or export. While Locked merely grants roles and users access to observe a report, without actually interacting with it.

Izenda offers the tools for administrators to ensure their permissions setup suits their business rules and desired use case perfectly. For more information surrounding permissions within Izenda, please watch some of the other videos in the permissions series for more details.

Permissions: Tenant Access

A deep dive into tenant access permissions and how to manage a tenant’s self administration capabilities.
Who Should Watch: System level administrators managing tenant setup.
What You Will Learn: How to restrict modules of the application to tenants and how to allow tenant self administration capabilities.

Video Transcript

Izenda offers a wide range of options for customizing an end user’s experience within the self-service platform. One of the most important examples of this is the ability to customize a user’s access to features, data, reports, and dashboards. Through Izenda’s vast permission setup options, an administrator can make decisions to maintain data security and fully mold a tenant, user, or role’s experience in the platform. For the purposes of this video, we are going to use an independent BI portal instance to explore some of the functionality surrounding permissions offered in Izenda.

The Administration UI gives System Level Administrators an unparalleled ability to manage a multi-tenant environment straight from the UI of the platform. As the system level administrator, setting up, managing, and impersonating tenants is as easy as using a drop down menu at the top of the screen.

For managing a tenant’s access to various self-administration capabilities, a system level administrator can navigate to the Permissions tab on the tenant access panel in the Administration UI. This is where a system level administrator can determine what modules a tenant can have permission to, but more importantly, what modules the tenant level administrators will be able to have admin capabilities over.

For instance, if a system level administrator decides that a tenant administrator should not have the ability to manage role setup, the “Tenant Access” checkbox can be unchecked in order to remove that capability. The checkbox on the right side of screen is all encompassing per module, but more specific decisions can be made in the center here.

So now, if we log in as a tenant level administrator for that tenant, we can see that the change has already taken effect. If we navigate to the settings panel, we no longer see the Role Setup tab on the left side of the screen. This would be useful for use cases where an end user base is not going to be required to perform any maintenance on roles or should not have the ability to manipulate this module of the application.

This is a small example of what can be accomplished with this type of permission management. It is up to the system level admins to determine how much freedom their end user base administrators should have to administrate their own environments. For more information surrounding permissions within Izenda, please watch some of the other videos in the permissions series for more details.

Permissions: UI Restrictions

This video demonstrates how, through the administration UI, administrators can limit a role’s permission to various UI elements including report part types, buttons, etc.
Who Should Watch: Tenant or System Level Administrators looking to manage user base access to various UI elements of the application.
What You Will Learn: How to restrict or enable UI elements of the application to users and roles.

Video Transcript

Izenda offers a wide range of options for customizing an end user’s experience within the self-service platform. One of the most important examples of this is the ability to customize a user’s access to features, data, reports, and dashboards. Through Izenda’s vast permission setup options, an administrator can make decisions to maintain data security and fully mold a tenant, user, or role’s experience in the platform. For the purposes of this video, we are going to use an independent BI portal instance to explore some of the functionality surrounding permissions offered in Izenda.

From a more granular level, within each role is the opportunity to limit functionality down to a data model access or even button level. Some of the key uses of this would consist of restricting a role’s access to create or consume specific report part types, removing the option of exporting or emailing reports or dashboards to prevent distribution to external users, or even removing entire modules of the application like hiding the ability to view or create Dashboards.

To demonstrate this, we will select a specific role that we want to be limited to only interacting with a limited number of report part types. For this, as either a tenant level administrator with self admin rights or a system administrator, we will go into the Role Setup area of the Administration UI. Here, we can select the role we want to edit and then select the “Permissions” tab under that role. This is where we will limit report part types a user within this role will have access to create or modify. It is important to note, however, that if someone shares a report or dashboard containing a report part with a restricted type, they will still be able to view the contents.

In this example, we will remove the Manager role’s access to create Maps, Gauges, and Forms as these are three of the more advanced report part types to create. Once we have made the desired selections, we will hit the save button to confirm our changes. Now if we log in as a user under the Manager role and navigate to create a new report, we will see that on the design real estate, our ability to build report parts of the Gauge, Map, or Form type is now inaccessible. This method of managing permissions to individual report part types has parity with limiting down a role’s access to just about everything within Izenda.

The ability to quickly limit down what users see on their screen can be an extremely useful tool in sculpting the differences among power users, canned report viewers, and everyone in between. For more information surrounding permissions within Izenda, please watch some of the other videos in the permissions series for more details.

BI Portal Upgrade

Description: This video will demonstrate the process that is taken to upgrade the standalone instance set up through the install video to the latest version of Izenda.
Who Should Watch: Administrators of Izenda deployments looking to upgrade to the latest version.
What You Will Learn: How to properly backup and upgrade an Izenda deployment with the latest releases.

Video Transcript

Izenda offers frequent updates to its software that need to be monitored, managed, and performed by a system level administrator. With millions of end users using white labeled Izenda within applications they use, it is important to continuously upgrade to add features and functionality that enhance the product.

Upgrading can seem like a tedious task, but Izenda makes it simple and straightforward to move to new versions of the product without losing anything out of your current environment. This video will serve as a guide to walk a user through the upgrade process of an independent BI Portal instance of Izenda similar to the one set up in our Initial Install video. For a refresher on the information contained in that video, feel free to rewatch the install video as many of the same concepts, file structure, and process will be similar to what was in that video. Also, be sure to follow along on our Upgrade guide that can be found on the wiki.

Prior to beginning the upgrade process, there are a couple of items, tools, and permissions that are required for this process that you want to make sure you have ready prior to moving on. This includes Izenda’s installation packages including any Izenda System Database Upgrade Scripts, Izenda’s front and backend packages like the ones used in the installation video, as well it will be important to have the database client GUI to connect to Izenda’s system database, an Administrator account to this database, Izenda web server administration account, and maintenance notice during the upgrade process.

With everything in place, the user will now need to do an Izenda system database backup in order to make sure that no important information is lost. In order to do this, login to the server that contains the Izenda System Database with an Administration account. Once this is opened, right click the Izenda database, then click “Tasks” and then “Back Up”. In the newly popped out window, choose the backup type of “Full” and backup component “Database”. Be sure to name the backup something useful that can be easily located and referenced at a later date. In this case, perhaps the date of the backup would be the most beneficial.

Select the destination disk for the backup and then select “Add”. Then select the file name and file path. With all of this in place, you will need to hit the “OK” button three times to move through alert boxes. Once these steps are completed, your Izenda System Database has been successfully backed up.
Next, we will need to make sure that any useful files out of our Izenda Web deployment are backed up. This is important as we do not want to lose some of the more important files associated with our deployment.

To do this, we will need to have the Izenda deployment folder in IIS open so we can manipulate the directories contained within. To back up these directories, we will simply need to copy the current API and UI folders from this directory and then paste them into a safe location that will not be wiped during our upgrade process. Also, to avoid overwriting important configuration folders, copy the API\izendadb.config, API\Web.config, and UI\izenda_config.js.
Now with our old files secure, we are free to move onto upgrading the system database with any changes in the new release. First, we will need to identify the current Izenda System Database version by right clicking the Izenda database then selecting “New Query”. Then, we will run the query named “select Version from IzendaDBVersion”. The result of this query should display the current database version running.

We will also need to ensure that our Izenda System Database is gradually upgraded to the latest version. This means that if there are multiple versions from your current version to the latest, each upgrade’s upgrade scripts will need to be run prior to moving on to the next. For example, if the current version is version 3, then all of version 1 and 2’s scripts will need to be run prior to finalizing the upgrade to version 3. To do this, open the Izenda System Database upgrade script folder. Then, through SQL Server Management Studio, open the script in the folder that upgrades from the old version to the next version above that. Continue this process until all update scripts have been run, in order, all the way to the current version.

Finally, we will need to take the configuration files from the newly downloaded directories and place those contents into the existing directories. Be sure to make copies of these directories prior to moving on as this process could potentially overwrite everything within these directories. At this point, remove the files from the API and UI folders until they are empty. Then, with the freshly downloaded App and UI directories, place the contents of the new files into the cleaned out directory.

Then, to bring in data from your deployment, in the StandaloneUI folder, make sure to copy over the izenda_config.js and Web.config files from the back up. For the API folder replace the default files with your backed up copy of the izendadb.config and Web.config files.

Once these steps are completed, make sure to do an IIS restart through the command line, start the website up again, and browse to it. The environment should now be upgraded to the latest version of Izenda.

In case of error, make sure to replace the existing file structure with the backed up files. This way, Izenda can continue running and the user can then troubleshoot issues without losing uptime on the deployment. Also, be sure revert your database as these components need to match up to work properly.
Izenda offers regular upgrades to continue evolving the product while resolving any issues that may arise. Maintaining an up to date version of Izenda serves as the best practice for optimizing the Izenda experience. Be sure to check out some of the other videos offered by Izenda to learn more about the product and how Izenda can best serve any company’s business intelligence needs.

Data Model Management

Description: This video will dive into the Administration UI capabilities surrounding concepts of data model management.
Who Should Watch: Administrators of the system looking to customize the data model to fit specific use cases, business rules, or levels of complexity.
What You Will Learn: How to easily navigate the Administration UI in regards to data model management and discover functionality contained within the tool.

Video Transcript

Managing the Data Model directly through the UI is one of the more impressive and useful features of Izenda’s 7-series product. It allows unprecedented control over the data sources that are going to be used for reporting purposes throughout the product. This is where a system or tenant level administrator can make alterations and customizations to the data objects within reporting databases to shape the data to fit specific business rules and make it easier for end users to navigate the system. This includes everything from aliasing tables, views, and stored procedure names, to making data source categories, or even determining which columns are visible to them.

In order to start making customizations to the data model, the environment must first have reporting data sources loaded into the system. This method is covered in the initial setup video as well in case you need a refresher on how to accomplish this. But, once these reporting data sources are in place, the user can then navigate to the “Data Model” tab to begin making alterations to the data model. As seen here, the data model is broken out into the various tables, views, stored procedures, user defined functions, and relationships built on primary and foreign key relationships.

Starting with the Tables tab within the data model management area, the administrator can begin building groups in which to lump data sources together. For instance, if we wanted to put everything related to sales within the same group, we would merely need to type into the Category area “Sales” and this will automatically construct a directory in which these data sources will live during report creation.

Then, still using the Tables tab as an example, if an individual data source has a name which reflects more of a development naming convention, it may be beneficial to rename these tables to something more appropriate and legible for basic business end users to interact with. To do this, simply use the “Database Source Alias” entry field to type a new name for the selected table. In this case, we will rename the dbo.day_OfWeek table to “Day of Week” table. Once the save button is pressed, the changes will be locked in and immediately accessible by any user within the system.

To view an individual data object’s structure, the user can click on the Database Source Name itself and the lower panel will be populated with the columns contained within the data source itself. This includes the column name, its data type, a visible and filterable checkbox, and a column alias entry box. This area gives administrators the capability to choose whether or not a field is visible to those creating reports or usable for filtering on reports and dashboards. The aliasing feature here functions similarly allows the administrator to take often developer-centric naming conventions and alter them to fit into a less technical user base’s expectations.

Also, within this area an administrator can construct additional fields to be used for reporting directly from the UI. This can be done through the Add Calculated Field functionality at the top of this panel. Clicking on that button will open a Calculated Field expression builder tool. This allows for users to develop individual fields through database friendly functions and operators that work throughout any supported relational database. The field requires a name and then in the Expression area, the user can click on the light bulb in order to open up a dialogue box with a Field Names tab and a Functions/Operators tab. This is where through pointing and clicking, a user can basically construct a custom field that will be understood with this common syntax throughout any system.

For a quick example, we will make a total price field using this tool. In order to do this, we will name the field “TotalPrice” and then, using the light bulb, select our Quantity field, a multiplication operator, and then our UnitPrice field. We will assign the “money” data type and then select the preview option to ensure our function worked.

The Views and Stored Procedures tabs share a majority of the same data management capabilities covered in discussion of the Tables tab. Stored procedures, however, have the capability of changing from being dynamic. Doing this will remove the current schema surrounding the stored procedure, but allow for further customization to the stored procedure itself straight from the UI.

By allowing the Stored Procedure to remain dynamic, the schema of the stored procedure will be determined at report design time and by user-supplied input values. Otherwise, the stored procedure will not be used. Filter values can also be manually adjusted from this area based on either Key-Value lookups or defined explicitly through User Defined Filter values.

User defined functions also have their own area within the Data Model setup area. This is where an administrator can see what input parameters a given user defined function require and allow for a decision to be made as to what level the function will respect. Field level determines whether the function will be allowed to be used at the field level in the Report Designer and Expression Level would allow the function to be used during the creation of calculated columns.

The Relationships tab will present the administrator with any pre-defined relationships between data sources within the database that Izenda picked up on with Primary and Foreign key relationships. Additionally, this area allows for data blending capabilities. For example, if an environment has multiple reporting databases, even of alternate types, this is where an administrator can make cross database relationships between those data sources through the Add Relationship functionality. This gives convenient drop down boxes that can be used to select what fields in which the relationship will be built and saved into the tenant’s data model configuration.

A schema diagram can also be referenced in case a more visual representation of the data is desired.

Izenda’s Administration UI offers unparalleled Data Model management access in order to perfectly mold the data model to fit any desired business rules or level of complexity. Be sure to visit Izenda’s documentation in order to dive deeper into some of the concepts discussed in this video. Also, feel free to watch additional videos to get a more complete understanding of all of the concepts in Izenda’s self-service Business Intelligence platform.

Copy Management

Description: This video describes the Copy Management feature in the Izenda Administration UI, its uses, and how it can be best deployed into multi-tenant environments.
Who Should Watch: Those setting up multi-tenant environments looking to replicate work done in one tenant out to others.
What You Will Learn: How to properly utilize the Copy Management system and tips on how to best utilize the tool.

Video Transcript

Izenda’s copy management tool in the Administration UI gives administrators of the system an intuitive method of extending work done in one environment out to others in the system. Repeating work multiple times in extensive multi-tenant environments can be a tedious and frustrating task. Izenda is equipped to alleviate this issue. Copy management is a powerful tool, so it is important to explore its usefulness and different ways to exploit the feature to increase efficiency while using Izenda.

The copy management tool can be found nested in the Data Setup area of the Administration UI. This is where a System Level administrator can begin taking work done in one tenant or at the system level and replicating it to other tenants throughout the deployment. The first selection that would need to be made is to determine from what source the desired items are going to be copied from. As a System Level administrator, this list will include every tenant within the environment as well as a “system” tenant. A typical use case for some users is to create templates, common reports and dashboards, or set up common roles at the System level and then as new tenants are created, simply copying these items into the newly created tenant.

With the source tenant selected, the user can then select the destination in which items are going to be copied. For this example, we will copy the desired items across all tenants. An example of this use case would be for system level administrators looking to copy a new report or role out to each tenant in the system without having to individually modify each tenant and replicate the work effort.

Once the destination is selected, the user can then begin selecting from the various Items to Copy checkboxes in order to start building what exactly is to be copied over. Selecting Data Model will open a panel in which the user can choose from various tables, views, stored procedures, and user defined functions that are available within each reporting database contained within the Source’s environment. In this case, the Source has access to a wide range of reporting data sources, therefore, we can scroll through each database and see the contents of each data source. We can make specific selections as to what is going to be copied.

If Advanced Data Settings are selected, there will not be any specific breakdown of options as this copy will be all inclusive.

For dashboards and reports, the user will be presented with a list similar to what was shown for the Data Model option. The difference being that, rather than options being broken up by Tables, Views, Stored Procedures, and User Defined Functions, it will be broken up by Report and Dashboard Categories.
Selecting Tenant Permissions would only be available while impersonating a tenant or logged in as a tenant level administrator. This is where perhaps using a template tenant for copy management needs might be a more efficient way of delivering out to new tenants of the system. Just like the Advanced Data Settings, this is an all-inclusive copy and does not require specific options or settings to be chosen.

Roles and permissions can be explicitly selected, however, if the Role and Permissions checkbox is marked and selections are made through that method, there will be no option to granularly select options. The permissions associated with the selected role will be automatically copied over to the destination.

For the Data Model, Reports, and Dashboards copy, the user will need to ensure that the data contained with the reports, dashboards, and data model are being copied to a place that can properly receive them. In order to accomplish this, the database connection or schema of the source tenant must be mapped to the connection or schema of the destination tenant. This can be done by selecting the “Add Mapping” button, then choosing the FROM Database Name, Type, and Object, and then assigning the same values over to the “TO” options of the destination tenant. There are a few rules associated with this mapping. For instance, tenants without database mapping established will be copied with or to the same database connection. Additionally, each schema without mapping will be copied to a schema with a common name.

After this data mapping, it may be necessary to validate the consistency between the source data sources and the destination’s. To do this, once the selections have been made, select the “Validate” button at the top of the screen. If there are no errors, the copy process is ready to be run.
For tenants that have the status “Ready to Copy” next to them, the user will then be able to press the “Run Copy” button at the top of the screen. For options that deal with the data model, there also may be an alert requesting permission to overwrite the existing data model of the destination.

The copy management system is a useful tool to minimize the work effort required to setup and manage a multi-tenant environment. Properly understanding how to utilize this mechanism is essential to using Izenda more efficiently. For more information on how to optimize the Izenda experience, feel free to watch some of the other videos offered on our website, or dive into the Wiki for more detail on everything Izenda.

MVC5 Starter Kit Installation

Description: A comprehensive walkthrough of installing the MVC Starter Kit.
Who Is This For: Anyone setting up the MVC Starter Kit for Izenda either for trial use or other purposes.
What You Will Learn: Everything from download to logging into the application for the first time.


The MVC Starter Kit offered by Izenda is a useful way for developers to observe an example of how Izenda integrates into a live example first hand. The kit utilizes Microsoft’s out of the box MVC application example code. With the MVC 5 Starter Kit downloaded, a user can take the infrastructure required to have Izenda as a part of the whole offering and mesh the Embedded UI within the provided MVC application. Much of the heavy lifting from a code perspective has already been handled within this kit and will enable easy exploration into some of the concepts around integrating code bases. This video will be an initial walkthrough of how to get the MVC 5 Starter Kit set up, connected to a configuration database, and prepared for reporting purposes.

To begin the process, the user needs to download the latest version of the Izenda API and the Embedded UI from the Izenda downloads site. Additionally, the user will need to download the MVC5StarterKit from the Izenda GitHub site. Also for the purposes of this installation, we will need an instance of SQL Server Management Studio to create a new database.

Unzip the MVC5StarterKit zip into an easy to access directory where the user is going to host the platform. Then, unzip the compressed EmbeddedUI and API directories into an equally easy to access location. To begin meshing the directories, we will open the MVC5StarterKit project in Visual Studio. Now open the API directory in a file explorer. Then, we will take all the files and folders contained within the API\bin directory into the Mvc5StarterKit\IzendaReferences directory. Once this is complete, we can then navigate back to the API home directory to begin moving files from here. Specifically, we will move the API\Content, API\EmailTemplates, and API\Export templates into the Mvc5StarterKit\IzendaResources directory. As the previous step directed the user to move the files and folders of a specific directory, this step requires the entire folder to be copied.

Finally, the user should move the entire contents of EmbeddedUI folder to the Mvc5StarterKit\Scripts\izenda directory. Once this is completed, the results of the copy should be reviewed and match the structure being shown on screen.

Next, we will need to open SQL Server Management Studio. First, we will need to create a new database that we can potentially run reports against. To do this, we will right click on the Databases dropdown and select New Database. Name this new database “Retail”. Then, locate the Retail database script contained within the Mvc5StarterKit directory in the SQLScript folder. Once the user finds the RetailDbScript.sql file, we will run that script on the newly created Retail database.

With these steps completed, the application should be in a runnable state within Microsoft Visual Studio With the project open, run the application to a desired browser, in this case we will launch the application to Google Chrome.

While there are few minor issues that may cause the application not to run properly at this point, typically there is a simple fix to most. Some permissioning issues can be resolved by going into the structure of the application and remove the applicationhost.config file from the mvc5Starterkit/.vs directory, cleaning the application, recompiling, and running again. Also, it is possible that the Izenda Configuration database can be out of sync with the current version of the application. This can be checked through querying the Izenda config database and seeing what version number it is currently on. If it is out of sync with the downloaded version of the API, the user may need to run a series of update scripts to get it up to the proper version. It is also a best practice to run the application through incognito mode on Chrome or clearing the browser cache prior to running to ensure the issue is not related to the cache.

Using the default login credentials, log into the system as the System Administrator. Once logged in, navigate to the Settings tab at the top of the screen. This is where the user will need to enter in their license key and token to gain access to all the modules offered within the application.
With this in place and full access to the application granted, the final step in the setup process is to load that Retail database into the Connection String tab of the data model tab. The connection string will need to be generated off specific data in relation to where that database is being stored including server name, database name, user and password information. Once this is generated, the user can build that connection string with the connection string builder or enter it in manually into the text box. To verify the database connection is valid, the user can click the “Test” button. If given a green check mark, the Connect button can now be selected to connect to the database for reporting purposes.

This MVC Starter Kit contains some other themed environments within it for different tenants. Logging into each one of these tenants can show some examples of white labeling and how the Izenda experience can be molded to fit specific use cases from tenant to tenant.

Once the application is up and running, feel free to navigate through the code to discover how many of these concepts are handled and how they can be implemented during the integration into your application. For additional details on the MVC Starter Kit, please consult the readme contained within the kit or navigate to the Wiki for a deeper dive into many of the concepts covered in this video. Additionally, for details on report creation, dashboards, and everything Izenda, please visit our documentation and videos.

HTML Starter Kit Setup

Description: A comprehensive walkthrough of setting up the HTML Starter Kit
Who Should Watch: Anybody looking to setup the HTML Starter Kit and explore concepts around embedding using the deployment.
What You Will Learn: Everything from download to initial launch.

Video Transcript

The HTML Starter Kit is a great way for Izenda users to interact with some of the embedding concepts that make Izenda the leader in embedded self-service analytics. This video will serve as a guide to get the HTML Starter Kit running locally and embedded into an existing application. For the purposes of this video, all that will be required is the latest version of IIS, Visual Studio, and the downloaded HTML Starter Kit.

With the downloaded HTML Starter Kit zip file, extract the contents into an easy to access location. Once extracted, open the directory to reveal its contents. The contents of the zip should contain an APIStarterKit, a website, a solution file, a DB directory with an Izenda configuration database creation script, and other directories and files.

Now open the solution contained within to have the project open into Visual Studio.

The APIStarterKit is essentially a deployment of the standard API with a spoofed authentication model. In the IzendaConfig.cs file is where Izenda names the token that is used. In this case of this kit, it will be called Impersonated Admin Token. Basically, here we are telling Izenda that the user is IzendaAdmin (the default admin user) with no associated tenant. When this token is leveraged, Izenda treats every interaction with the API impersonated as an Administrator.

The database that the user will need to connect to can either be a fresh Izenda database or a copy of an existing configuration database. Provided in this kit is a database script that will create a new Izenda Database from scratch. The database can be created by opening up SQL Server Management Studio and running this script. Once it successfully executes, it will create an IzendaSampleDB. Make sure the new database has the proper credentials for connecting via connection string. If using an existing Izenda Configuration database, make sure inside the IzendaSystemSettings table the DeploymentMode field is set to “3”.

We now need to make sure that the izendadb.config file from the extracted directories has been properly carried over into the project opened in Visual Studio. If it is not shown in the structure of the APIStarterKit directory, we will need to manually add that file from where these files are extracted to the visual studio project. Then, we will need to open the izendadb.config file and make an adjustment to the Izenda Database Connection String value. Clear out the default value associated with this variable and enter in the connection string to your configuration database. If the connection string has a backslash contained within it, make sure to double the backslash to avoid Visual studio escaping it out. Be sure to save the file prior to moving on.

The user will also need to modify the index.html file under the website directory in visual studio. In here, the user will need to modify the WebAPIUrl value to reflect whatever will be set up later in IIS. In this case, we will change the value to say http://localhost:82/api/ . When we setup the API’s site in IIS, it will be important to remember what port number we associated with this url.

In Visual Studio, we now need to publish the contents of the APIStarterKit directory and Website to be used to create sites in IIS. To do this, right click on the directory and select “Publish”. Then, select Custom in order to specify where exactly we want to publish. Give this profile a name and select “OK”. Then in the publish method drop down, select File System. Finally, select the location in which these contents will live and press “Publish”. With this done for both the APIStarterKit and Website, the user can now move on to setting up sites in IIS.

In IIS, right click on the sites button and select “New Site”. For the API, we will call the site “API” and point to the directory that the APIStarterKit was published to. Also, be sure to assign to Port number according to what was modified in the index.html file. In our case, that port number was “82”. Once this is setup, we need to ensure that this site has the proper permissions. In this case, we will give “Everyone” the ability to interact with this site to ensure that everything deploys smoothly. This value can be changed later to add extra security if desired.

This step is important in ensuring that the deployment will work properly and deserves its own step for troubleshooting. To test to see if the API setup was successful, navigate to the URL for the API to test. In this case, we will navigate to http://localhost:82/api/. If our setup was successful, we should see a little cartoon 404 error. If we do not see this, we will need to work back through the setup steps for the API and make sure that our port number is open and accessible, we’ve referenced the correct files, and added the proper security roles.

Next, we will do the same for the published Website directory. Right click to add a New Site in IIS and name the site HTML Website. Point to the directory in which the website was published and assign a port number different from what was assigned in the previous step. Add the “Everyone” permission to the security roles and select Apply to move on.

Now we can test our deployment to see if it runs. Reset IIS from the application or administrator command prompt. Once this is complete, select the HTML Website in IIS and select the “Browse” option on the right side of the screen. If everything was setup correctly, the site should open up in your default browser and take the user into the application.

From here, the user will need to navigate to the settings page and drop in their license key and token to validate the deployment, and then can begin moving through the process of adding connection strings to reporting databases and building out reports and dashboards.

Report parts can be easily embedded into existing applications by setting up a reference to the Izenda deployment, grabbing the GUID associated with the desired Report Part, and then using that GUID to build that Part into an existing page.

Entire pages can also be brought into existing pages. This means that the report designers, lists, dashboards, and administration pages can be layered in on top of existing pages in a very similar way to individual report parts.

For more information on the HTML Starter Kit, Front End APIs that could be beneficial in trialing this deployment style, or anything else Izenda, please visit our documentation online or watch additional videos.

Embedding/White Labeling

Description: This video will demonstrate and explore embedding and white label concepts. While these concepts are on par with a full integration, the kits used in this video are designed for trial and demonstration purposes only.
Who Should Watch: Developers looking to trial Izenda and explore embedding and white labeling.
What You Will Learn: How to use the APIs and documentation provided in order to white label and embed Izenda into an existing application.

Video Transcript

Izenda’s embedding ability in unparalleled to any other platform in the Business Intelligence space. This video will cover concepts of embedding and white labeling into an existing application. For this video, we will use an Angular JS template application to show off some of these concepts. Also, we will be using the dev tools feature out of Google Chrome frequently to find where some of the CSS and HTML is being set and can be modified. Finally, this video assumes that the user successfully setup a HTML Starter Kit application in the HTML Starter Kit Install video as we will leverage that environment in our embedded example.

The first thing we need to do is bring over the Izenda directory from the HTML starter kit that has been set up from the last video. Also, we will need to copy over the Web.config and index.html files. In this case, we need to make sure that our Izenda index.html file does not conflict with the index.html contained within this template application. We will need to rename the Izenda index.html to Izenda.html.

Also, this video is intended to demonstrate and explore embedding and white label concepts. While these concepts are on par with a full integration, the kits used in this video are designed for trial and demonstration purposes only.

To embed we will need to bring the Izenda deployment and any required structure into scope so it can be embedded within our Angular JS pages. We can see the structure required to bring Izenda into an existing page by looking at the Izenda.html page we brought over. From this file, we can see how the JavaScript needed for Izenda to render the entire platform. From this template, we can then use the numerous APIs provided in the documentation to embed bits and pieces of the platform all the way down to the report part level.

There is a page in this template that has been left intentionally blank as a canvas to work with the application. Using this blank HTML page, we will begin by embedding the entire platform into a page and explore white labeling concepts. We will open our blank.html source code and begin removing some of the unnecessary features from this page. Then, we will grab the JavaScript sources and config function from the Izenda.html file and paste them into the blank.html file at the bottom. In the HTML at the top of this directory, we will reference the Izenda-root object we just brought into scope and use that ID in the div referencing the Izenda-container class. With what is being shown on screen, we can expect the blank.html page to render the entire Izenda deployment using the System Admin user through the Impersonated security model setup in the HTML starter kit.

Also, for this application, we will need to make sure that we are referencing the right directories and resources in the main.js file. In this case, we will look to see where the blank.html page is being referenced and be sure to add the file structure for the Izenda-ui.css and jquery url that is used in the Izenda.html and blank.html files.

One of the first things that can be done to white label this deployment, is to remove the Izenda logo from the top of the screen. This is the only place where Izenda’s logo would show up in this deployment as it impersonates authentication and does not allow the user to reach the login screen where another Izenda logo would be located. Using the dev tools provided in Google Chrome, we can use the element selector to point and click at the Izenda logo and then be presented with the underlying source code to show where the icon is in the project. In this case, removing the .izenda-TopMenu-logo from the Izenda-ui-blessed1.css class will completely remove the icon from view.

Using this concept of identifying where specific pieces of CSS are in the code, we can begin modifying to look and feel of this deployment at a high level to make sweeping changes that will have an effect throughout the entire platform. For instance, determining where color values are getting set and changing the header color from blue to red will change that same header throughout each page of Izenda. This same concept can be used for button color (on its unselected and selected modes), background, fonts, font color, and much more. This is how a user can begin meshing Izenda into the pre-established UI and UX provided in the existing application that Izenda is being embedded into.

As for individual pages being embedded, like the report designer or report list, specific functions can be used to embed those specific pages. They will be called similarly to how the IzendaSynergy render function was called on the blank.html page, but will be named per the type of page. In the Izenda documentation, there is a comprehensive listing of these functions that can be used to accomplish this with sample code to assist. For a quick example, we will embed the report designer into the blank page we have been working with just to show this example. All the developer would need to do is change the function and parameters from render to match one of the APIs listed in the documentation. This is how we would embed the report designer.

Finally, embedding report parts to embellish existing pages is a great way to use Izenda’s modern visualizations. For this example, we will embed a chart and a grid onto the landing dashboard of the Angular JS template application to explain these concepts. Like how we embedded entire pages, Izenda will need the proper JavaScript in scope to create definitions for these report parts to be layered in the underlying HTML. Using the renderReportPart function, we can bring specific report parts into scope to be referenced in the HTML code above. For this, the user will need to give the report part a custom ID and reference the desired report part’s GUID from the Izenda Configuration database. These GUIDs for Report Parts can be found in the IzendaReportPart table of the configuration database. The user can query that database to find a listing of any report parts contained within the deployment. If none have been created at this point, the user will need to go to the fully embedded platform and build out some reports prior to attempting to embed report parts.

With the custom ID value set and the report part brought into scope using the renderReportPart function with the corresponding GUID, the user can then reference the custom ID value in a div tag to embed the report part anywhere on the page that they desire. In this case, we will embed the report part into one of the Portlets provided by this Angular JS kit.

During this entire process, using the element selector in Chrome’s dev tools will be a valuable asset in adjusting the values that the user desires in order to achieve a truly white labeled experience or make quick code level changes to correct any discrepancies between asset libraries, locate specific bits of code, and navigate through the process of embedding Izenda into your offering. Be sure to frequently reference the documentation as it will be an asset in successfully embedding Izenda into your platform. Keep in mind that this HTML starter kit is strictly for trial purposes and testing embedding concepts. The security contained within this deployment is impersonated so a security layer does not need to be configured.

Once the basics of embedding are understood, it is very simple to embed any piece of Izenda into an existing application and white label it to fit any desired look and feel. For more information on embedding, white labeling, or anything Izenda, please reference our documentation, our website, or watch additional videos for more information.