Note

This version of the .NET API documentation is deprecated. A new version can be found at https://www.exagoaccess.com/api-docs/.

The Exago interface consists of two primary elements:

• the User Interface, and
• the API

The User Interface is built directly onto the .NET API. This means that .NET applications can interface directly with Exago. Non-.NET applications use the REST Web Service API.

This guide will walk through the process of integrating Exago into a .NET-based web application.

This example will demonstrate:

• referencing the API in the project
• loading an existing report
• modifying that report's run time filters
• executing the report in a browser window

Referencing the API

First reference the Web Reports API and Puppeteer Rasterizer library. This is usually located in the <WebApp>\bin folder, where <WebApp> represents the install directory of the Exago Web Application. The file is named WebReportsApi.dll and ExagoPuppeteerRasterizer.dll.

Include the following namespaces for now:

• WebReports.Api: Contains the Api class which is the main interaction class between Exago and your application.
• WebReports.Api.Reports: Contains the Report class, for creating and managing reports.
• WebReports.Api.Roles: Contains classes for managing role security settings.

Create an Api Object

An Api Object is the main class you need to create in order to interact with Exago. It contains the first and last points of entry for each instance of your application.

Create an Api Object using the following overloaded constructor:

Api myApi = new Api(AppPath, ConfigFile);

• AppPath is the physical or virtual location of your Exago installation.
• ConfigFile is an optional configuration file name. If left out, it will default to WebReports.xml.

Caution

Always call the constructor with a minimum of the AppPath argument. Only one Api object should ever be opened per thread.

Load a Report

Now let's load the report we want to modify.

The ReportObjectFactory is the collection class for report management methods—creating, loading, copying, saving, renaming, and deleting report files. It can be used to work within a repository or a temporary browser session, or both if necessary. In this example we're simply loading an existing report into the Api object.

Reports called from the ReportObjectFactory are ReportObject objects, which is a general class representing the various report types.

• WebReports.Api.Reports.Report objects — Advanced, CrossTab and Express Reports
• WebReports.Api.ExpressView.ExpressView objects— ExpressViews
• WebReports.Api.Composite.Chained.ChainedReport objects — Chained Reports
• WebReports.Api.Composite.Dashboard.DashboardReport objects — Dashboards

We are casting the ReportObject called from the factory to a Report, because we know it is an Advanced Report. Report objects inherit several methods from ReportObject, but greatly expands the management capabilities. If we loaded a Dashboard or a Chained Report, we would cast it to DashboardReport or ChainedReport respectively.

Report myReport = (Report)myApi.ReportObjectFactory.LoadFromRepository(@"TestReport");

Note

Several methods reference an Active report by default. This is usually the last report accessed, but can be specified by the ReportObjectFactory.Active property.

See Loading Reports in the .NET API for more information.

Retrieve the Role Security

Let's see if the current user has access to the database object we want to filter for.

if (myApi.Roles.ActiveRole.Security.DataObjects.GetDataObject("Customers") != null)

{ Permission Granted!; }

else Permission Denied!;

The Roles object allows for accessing and modifying the elements found within the Admin Console. Changing or adding Role settings will only persist for the current session, and will not modify the config file.

We can also set some additional security and restrict the user from seeing specific data object rows:

DataObjectRow dataObjectRow = myApi.Roles.ActiveRole.Security.DataObjectRows.NewDataObjectRow();
dataObjectRow.ObjectName = "SSN";
dataObjectRow.FilterString = "false";

Modifying the Report

Now that we have loaded and declared our Report object, we can begin to modify its contents. Let's clear out the pre-existing runtime filters, and add one of our own:

foreach (Filter oldFilter in myReport.Filters)
 { myReport.Filters.Remove(oldFilter); }

Filter myFilter = myReport.Filters.NewFilter();
myFilter.DbName = "Customers.CompanyName";
myFilter.Operator = wrFilterOperator.NotEqualTo;
myFilter.Value = "Exago Inc.";
myFilter.AndOrWithNext = wrFilterAndOrWithNext.And;

Note that all these modifications will take place within the current session, and will not modify the report definition itself unless you specifically overwrite it.

Closing the Session and Executing

Let's execute the altered report. First, some administrative action is required.

Set the report execute type to HTML, so it runs in the browser:

myReport.ExportType = wrExportType.Html;

And hide the application tabs to avoid clutter:

myApi.ShowTabs = false;

Now save the changes we've made to the Api. This will load the report into a temporary space in the Api to prepare for execution.

myApi.ReportObjectFactory.SaveToApi(myReport);

And we're all set! Calling the following method will end the session, perform the specified action, and return the session URL. The session URL is an alphanumeric single-use identifier for the session. Append it to your Exago application URL.

Since we loaded a report into the Api, the action defaults to Execute.

string url = @"//MyDomainServer/Exago/" + myApi.GetUrlParamString(ExagoHome);

Note

The ExagoHome parameter can be used to specify the Web Application's home page. It will default to ExagoHome.aspx.

Now redirect your browser to the generated URL and see the results!