Event Logging

Event Logging can be valuable for operational auditing and is also an important tool for troubleshooting Logi applications. This topic introduces developers to the use of the Event Logging elements in Logi Studio.

• About Event Logging
• For Logi Info Versions Earlier Than v9.5.37
• Add Event Handling to Your Application
• The SessionStart Event
• The BuildReport Event
• The AuthenticateUser Event
• The RunSQL Event
• The RunSP Event

Event Logging is not available in Logi Report.

About Event Logging

Events, which are internal notifications, are triggered, or "fired", when specific actions occur. In the context of a Logi application, developers can define event handling, using Action.Process elements, so that designated processing occurs when events are fired.

In Studio, an Action.Process element is associated with an event and points to a Process definition task. When the event fires, program flow will be directed to that task and specific parameters will be automatically passed to it. These parameters communicate event-specific information to the task, which can then be designed to log the event by writing it to a database table, displaying it in a report, or taking other task actions.

For Logi Info Versions Earlier Than v9.5.37

If you're using a Logi Info version earlier than v9.5.37, to enable event processing the following lines of code must be added manually to your Logi application's Global.asax file, which is in your application root folder. Any text editor, such as Notepad, will work fine for the purpose.

Note that the second line shown below (beginning with "Private" and ending with "MyBase.PostRequestHandlerExecute") may wrap into two lines in your display but should be entered as one line in the file.

If you're using Logi Info version v9.5.37 or later, you do not need this addition to the file.

Add Event Handling to Your Application

Event logging requires that you include appropriate elements in your application definitions:
 

1. Open your application's _Settings definition in Studio and add an Event Logging element, as shown above. Set its Log Events attribute to True. This attribute can be used to toggle event logging on and off. Note that tokens will not work here.
   


 

2. Below the Event Logging element, add a Log Event element and set its Event Name attribute to the type of event to be logged, as shown above. The Event Name attribute value has a drop-down list of the valid events, which are discussed in detail later in this topic. Multiple Log Event elements can be added in order to provide logging of different types of events.
   
   The optional Event Element ID Filter attribute allows you to "zero-in" on the behavior of a specific element. You identify the element, by its ID, as the only element for which events of this type should be handled. Events of this type generated by other elements will then be ignored.

3. Add a standard Action.Process element below each Log Event element, as shown above. The Process Definition File and TaskID attributes identify the definition file and task, respectively, that will be called when the event fires.

5. The final step is to create a process task to handle the information provided when the event fires. A sample task is shown above.
   
   This is an example of an SQL statement that adds the logging information to a database. Notice the tokens used in the VALUES clause:

INSERT INTO myLog (EventName, ElementID, EventTime, SPName)
VALUES ('@Request.EventName~', '@Request.ElementID~', @Request.EventTime~, '@Request.SP~')


The records generated by such a statement might look like the following example:


 

The @Request parameters that are automatically passed when the event fires vary depending on the event type; they are discussed in the following sections.

The SessionStart Event

The SessionStart event fires when the web server session starts for the current user. The parameters that are automatically passed by an associated Action element include:

The BuildReport Event

The BuildReport event fires when the ReportID is determined and ends after the final output HTML is created. The parameters that are automatically passed by an associated Action element include:
 

The AuthenticateUser Event

Logi Security must be in use in order for the AuthenticateUser event to occur. In that case, the event fires when a user's Rights and Roles are determined. The firing of the event is therefore dependent on the setting of the Security element's CacheRights attribute. If the attribute is set to False or left blank, the event will fire with every request; if it's set to Session, the event will only fire at the beginning of the session. The parameters that are automatically passed by an associated Action element include:
 

The RunSQL Event

The RunSQL event fires when a DataLayer.SQL or Procedure.SQL element runs. The parameters that are automatically passed by an associated Action element include:

The RunSP Event

The RunSP event fires when a DataLayer.SP or Procedure.SP element runs. The parameters that are automatically passed by an associated Action element include: