Expanded Logging for LiquidOffice eForms
If you have ever been tasked with administrating or monitoring eForms and processes published by Autonomy Process Administration (formerly known as LiquidOffice), the default events leave a bit to be desired.
The events that are displayed give the very base information needed to let an administrator know that something un-good has happened.
A classic example of the types of errors you get to work with would be “[Cardiff][SQLServer JDBC Driver][SQLServer]Syntax error converting the varchar value ‘UsingSomeValueHere’ to a column of data type int.”, and the date/time this event took place. That error is only slightly better than the above listing of errors “TypeError: Cannot call method “getFirstName” of null”. Really, these types of errors don’t give ya a whole lot to work with. Nothing telling the administrators what user generated the error, or what form/process the error is attached to, etc. Once you have 5-6 processes active with multiple forms, determining the Who, What, Where, and Why can turn time consuming fairly quickly. All of this frustration can be eliminated by adding a few code snippets for Server Side Processing.
Inside the APA Scripting editor, there are two main sections that you can create scripting code for, Client Side and Server Side. Client Side scripting is generally used for events/actions that take place during Form Runtime (user access the Web Form) or run on the Server (workflow routing and events, DB Look Up’s and the like).
After we open the Scripting editor, navigate to the Server Side OnComplete event. Looking through the APA/LO Scripting Guide will get you the syntax needed to write the to server logs (Event Viewer). Your other option would be to copy the following code snippet: CSServer.Log(“Your Message”).
The two main events that we are going to use are the OnComplete() and OnOpen(). For most forms I’ll add the OnComplete() logging a record of all the submitted forms with a DateTime stamp and a UserID. The OnOpen() event can similarly be used, but this even is thrown every time a form is opened and can lead to a lot of unnecessary entries, as this event fires even if the form is not submitted. After these minor changes have been implemented your Event Viewer will start looking like this (minus the redactions), making it actually a usable tool for administrators monitoring the system.