# How to Inspect Session Data and Debug Extensions

Using a debugger to inspect session data is a good way to learn how to interact and extend application functionality. This guide explains how to inspect session state for events which allow you to insert custom event handlers. The Visual Studio debugger and Google Chrome javascript console are used in this demonstration, but other tools can be used as well.

Caution: These methods cause program halting, and are therefore not for use in a production environment.

Part 1 explains how to inspect server data for use with Server Events and Custom Functions.

Part 2 explains how to inspect client data for use with Action Events.

# Server Data

You can inspect server data by calling out to an assembly with a debugger statement in a Server Event or Custom Function. By attaching the process to a debugger you can see the object variables currently in use.

First, build an assembly that has a public method call to launch the debugger. This can be accomplished in only a few lines of code. The method should pass in the sessionInfo object as an argument.

Note: The assembly needs a reference to the WebReportsApi.dll file in the {Exago}\bin folder.

### Example

    namespace Extensions
    {
      public class ServerEvents
      {
        public static void LaunchDebugger(WebReports.Api.Common.SessionInfo sessionInfo)
        {
          System.Diagnostics.Debugger.Launch();
        }
      }
    }

You could also use an object array argument to make it easier to pass in any other session variables you want to inspect.

### Example

    public static void LaunchDebugger(params object[] args)

Compile the program as a .dll assembly in Debug mode. Then copy the .dll to the {Exago}\bin folder. Keep Visual Studio open in the background so that the debugger is recognized.

Code to launch the Visual Studio debugger

Next, open the Exago Administration Console and add a new Server Event or Custom Function. For a Server Event, set the Global Event type to the application state that you want to inspect.

Setting the event to fire at the start of a report execution

In the custom code window, add your .dll as a reference, and add the namespace if necessary. Then in the code field, call the debugger method, passing in the sessionInfo object and any other variables relevant to the session state.

Note: Make sure to use the correct return value for the Global Event.

### Example

    ServerEvents.LaunchDebugger(sessionInfo);
    return null;

Click the green check mark to verify that the code is valid. Then click OK to save the event.

Calling the debugger method from the Server Event

Next, launch the Exago interface and cause the Server Event or Custom Function to fire. An exception will occur and Visual Studio will ask you to debug the process. Select the instance of Visual Studio with your assembly code and click Yes.

Visual Studio exception handler

Finally, if an Attach Security Warning appears, click Attach.

Attach the debugger to the Exago process

The Visual Studio debugging and diagnostics tools will launch for this program instance. There are many tools available, but for now focus on the Autos window. This shows all of the variables in use for the application at the moment. Any arguments passed into the debugger method, including sessionInfo, are available to inspect. This is a great way to see how variables are used at different points in the application, and to learn about how the API is structured.

Inspecting sessionInfo data

Click the Continue or Stop buttons to exit the debugger when you are finished.

# Client Data

You can inspect client data by inserting a debugger statement into the page's javascript using an Action Event. This lets you use your browser's javascript console to inspect the client objects, such as application DOM and report output data. Unlike Server Data, debugging client data requires no external software.

The javascript code can be implemented in an assembly, imported into the Exago home page, or written directly in the Administration Console. This example uses an assembly.

First, use the proper method formatting to add an Action Event which simply calls the javascript debugger. The encapsulating C# method must pass in the sessionInfo object, and return sessionInfo.JavascriptAction which contains the client-side javascript.

### Example

    using WebReports.Api.Common;
    using WebReports.Api.Programmability;

    namespace Extensions
    {
      public class ActionEvents
      {
        public static JavascriptAction LaunchConsole(SessionInfo sessionInfo)
        {
          sessionInfo.JavascriptAction.SetJsCode("(function() { debugger; }())");
          return sessionInfo.JavascriptAction;
        }
      }
    }

Note: Using an anonymous function wrapper is not required for all action events, but it is more broadly compatible, and thus recommended.

The javascript code is the string argument of JavascriptAction.SetJsCode

If you are using an assembly, compile the program as a .dll, then copy it to the {Exago}\bin folder. If your javascript is in a separate .js file, copy that as well.

Next, open the Exago Administration Console and add a new Action Event. Set the Event Type to Click or Load if you want to attach the event to a specific occurrence in the Report Designer or on a Report. Set the Global Event Type if you want to attach the event to a general application action.

"Click" events can be attached to report items or buttons in the Report Designer

In the custom code window, add the assembly .dll as a reference. In the code field, return the Action Event method, passing in sessionInfo as an argument.

### Example

    return ActionEvents.LaunchConsole(sessionInfo);

Click the green check mark to verify that the code is valid. Then click OK to save the event.

Calling an Action Event in an assembly

Next, launch the Exago UI. If you are using a Local action event, with a type Click or Load, then attach the event to an item in the report designer or on a report.

Press F12 to open the browser's Developer Tools. Finally, cause the Action Event to fire. The browser will load the object state in the debugger. Click the Sources tab and focus on the right-most pane. Expand the Scope pane to see the client object data. The clientInfo object contains the data most relevant to the application session. You can see the current state variables, and you can browse the structure of the client data to learn how to develop Action Events for your Exago environment.

Examining clientInfo variables

Press F8 to continue or F12 to close the debugger when you are done.