Each time a session is added or updated in the User repository it is re-analyzed.  During this process built-in evaluations are performed (like recalculating the operating system version information and recording the errors and warnings in the data).  You can create your own analyzers to extend this process.  When you do, your custom analyzer be presented with all of the information in the session as well as the results of the built-in analysis. Because this is all done on a background thread on the Server no user interface can be displayed. 

What You Need to Implement

To extend the Session Analysis pipeline, you need to create a class that:

• Is Public
• Implements the ISessionAnalyzer Interface
• Is added by your IExtensionDefinition during its Initialize method by calling the RegisterSessionAnalyzer Method.

For more information on how classes are evaluated and loaded see Loupe Extensions - Deploying Extensions.

The Processing Cycle

When a new or updated session is being analyzed, the following steps happen:

1. The intrinsic analysis is performed.  This updates the OS version information and populates the rest of the SessionAnalysis data structure.  This includes quick access to each of the unique errors and warnings in the session.
2. Each extension is called that applies to the session.  If your extension is enabled and your custom analyzer was initialized successfully it will be called.
3. The session is marked as analyzed.

The order that custom analyzers are called is not deterministic.

If your extension throws an exception it will be logged in the Loupe Server Service log and execution will continue.  This means the session will still be marked as analyzed.  You can view the exception using Loupe Desktop on the server.

Session Analyzer Lifecycle

1. Each session analyzer has to be registered by an extension when that extension is initialized.  An extension must be enabled to be initialized.
2. The first time a session is being analyzed each custom analyzer is initialized by calling its Initialize method.  If it returns without throwing an exception it will be eligible to process sessions.  Then it is eligible to be invoked for processing. 
3. Each time a session needs to be analyzed the Process Method will be called.  This method must be threadsafe and re-entrant because multiple sessions can be processed at the same time.
4. Whenever any part of the extension's configuration is changed the ConfigurationChanged Method will be called.  Calls may still be made to the Process Method during this time so it's necessary to protect any internal state from multithreading.
5. When the session analyzer is no longer needed (typically because the repository it is related to is about to be dismounted) it will be shutdown by calling Dispose.  After this it will not be used again.

Notes and Best Practices

Caching Information

If it's useful to cache information to improve performance the best place to do this is in your Repository Controller.  This allows the cache to be shared between all of the extensions that make up your Extension.  Your session analyzer can cache information however it's important to do so in a thread safe manner because the Process method must be threadsafe and re-entrant.

Sharing with a Session Command

It's often useful to allow users to invoke your session analyzer directly outside of the session analysis sequence.  To do this, implement the ISessionCommand interface on the same object.  It will be loaded separately for each use, so any information that should be shared between them should be pushed into the Repository Controller.

Logging and Monitoring

While your session analyzer is running it's a good idea to log information about what it's finding using the ILog object provided by the Repository Context provided during initialization.  This is particularly useful in session analyzers since they can't display a user interface.

Analyzers relate to a Repository

A session analyzer is associated with exactly one repository.  Since a server is capable of loading multiple repositories that can all support analysis it's important that they are designed to support being loaded multiple times in the same process space.  They will be uniquely associated with a single Repository Context during initialization which can be used to share state.