Log Files

The information below does not apply to Forms Builder 3.5.2 and later in an Azure environment. For information about logging and debugging workflows in an Azure environment, see Logging in Azure.

Enhanced Logging in Forms Builder 3.4 and Later

Additional logging capability is provided in Forms Builder 3.4 and later:

WorkflowinstanceId

The FormBuilderLogService has been enhanced so that whenever it logs the user name and workflowdefinitionid, it now also logs the workflowinstanceid, if available.
Fatal exceptions

If a final exception is caught in the FormInstanceController (which essentially aborts the web service call), the exception is now logged as Fatal, since it is not just an error. A Fatal exception essentially terminates a workflow and causes aborts on further attempts to access it.
Entire DocuSign return envelope

The WebhookController used in DocuSign sequences has been enhanced to log much more info. This code is executed when DocuSign returns a Completed status for a sequence with multiple signers. The entire return envelope from DocuSign is now logged at the Debug level. There is also more Info available as it starts up the previous workflow.

In Forms Builder 3.5.1 and later, the ability to set NLog levels in the Settings workspace of Form Designer is removed to prevent conflicts with Azure log configurations. Azure logs are stored in customer-specific tables. If your Forms Builder deployment is in an Azure environment, contact Anthology Inc. obtain access to the Azure log tables or to request changes in the NLog settings.

In Forms Builder 3.6., several logger.debug statements and client-side logs are modified to Info level to make them available to help debug issues in an Azure environment since in an Azure environment the log level is set to Info level for all products. The Info level is set for logs related to:

Site Warmup
LookupUser
Account Controller
PDF creation and e-sign documents
Payment processing for PayPal, ACI, and IATS

NLog Levels
NLog Level	Hierarchy	Description
Fatal	1 - Only fatal messages will be logged.	A web service call has thrown an exception. The username, workflowdefintionid, and workflowinstanceid are logged.
Error	2 - Logs include the first two levels.	Any exceptions that are not being handled by the application.
Warn	3 - Logs include the first three levels.	Messages about potential oddities from which the application automatically recovers or about variable/property values that may be close to being out of the acceptable range.
Info	4 - Logs include the first four levels.	Reserved for customer logging in workflows (see LogLine/LogObject Activities).
Debug	5 - Logs include the first five levels.	All additional Forms Builder logging.
Trace	6 - Logs include all messages.	Extensive additional Cmc.Core logging for use by developers.
Note: When a bookmark is not found (unknown cause), Forms Builder no longer tries to unload the workflow twice and log twice. This exception was previous only seen in the Trace logs. In Forms Builder 3.4 and later, it is moved to the Debug level.

Best Practices for Logging

	Important
	Log files may contain confidential information such as user names and passwords, account information, etc. It is your responsibility to protect sensitive user and system data. To mitigate the risks of exposing sensitive data, observe the following best practices: Set the log level in production environments to the lowest, least detailed log level. Increase the log level in test environments only when needed. Reset the log level when testing is complete. The default logging provider used by Anthology Inc. products is NLog. NLog allows you to configure log targets, levels, rules, layouts, etc. through configuration. To configure logging, modify the NLog.config file in the application’s executing directory. For Web applications, this file exists alongside the web.config file. When LogLine or LogObject workflow activities are used to capture entities that contain sensitive information, remove such activities as soon as testing is complete. We recommend setting the Level value to Information for any LogLine or LogObject activities. See Best Practices for Logging and Logging in Azure. If, instead you followed the recommendations, and the development machine NLog minLevel is set to “Info” and all logging is done at the “Information” level, and the production machine NLog minLevel is set to “Error” (default), then nothing needs to be done because the production machine will not log “Information” LogLine or LogObject activities. The additional benefit is that the logging is still available if a problem can only be seen in a production machine and lowering the NLog minLevel to “Info” temporarily (and restarting the app pool) will allow troubleshooting.

Important

Log files may contain confidential information such as user names and passwords, account information, etc. It is your responsibility to protect sensitive user and system data.

To mitigate the risks of exposing sensitive data, observe the following best practices:

Set the log level in production environments to the lowest, least detailed log level. Increase the log level in test environments only when needed. Reset the log level when testing is complete.
The default logging provider used by Anthology Inc. products is NLog. NLog allows you to configure log targets, levels, rules, layouts, etc. through configuration. To configure logging, modify the NLog.config file in the application’s executing directory. For Web applications, this file exists alongside the web.config file.
When LogLine or LogObject workflow activities are used to capture entities that contain sensitive information, remove such activities as soon as testing is complete.
We recommend setting the Level value to Information for any LogLine or LogObject activities. See Best Practices for Logging and Logging in Azure.
If, instead you followed the recommendations, and the development machine NLog minLevel is set to “Info” and all logging is done at the “Information” level, and the production machine NLog minLevel is set to “Error” (default), then nothing needs to be done because the production machine will not log “Information” LogLine or LogObject activities. The additional benefit is that the logging is still available if a problem can only be seen in a production machine and lowering the NLog minLevel to “Info” temporarily (and restarting the app pool) will allow troubleshooting.

Location of Log Files

Forms Builder Logs

Local logs: C:\logs
Server logs: \\<server>\c$\logs

Where <server> is the name of the server where Form Designer and/or Forms Renderer is installed.

The log folder on the server contains numerous installation logs and error logs for Anthology applications. The most commonly used log file for troubleshooting Forms Builder issues are the FormsBuilderRenderer<date>.txt and Cmc.Nexus.AdaptiveLog.txt. Sort the folder by “Date modified” and open the most recent log.

Event Logs

Event logs for workflows that are executed on an Anthology Student server are written to the following folder on the server machine:

Program Files (x86)\CMC\C2000\Services\Nexus Event Notification Service <version>\logs

The logs capture all workflow events including LogLine output, events associated with long running workflows, and errors captured by the Service Module Host.

Logs for Saved Events

For Saved events, logs are found in:

Program Files (x86)\CMC\C2000\Services\CampusVue Nexus Event Notification Service<version>\logs.

Logs for Saving Events

The host process for Saving events from the legacy interface for Anthology Student is the CampusLink WCF API (worker process). The logs are on the API server under cmc.campuslink.webservices.Wcf\logs.

The logs for Saving events from the standard interface for Anthology Student are on the Web Client server in the \logs folder in the Cmc.Nexus.AdaptiveLog file.

LogLine/LogObject Activities

Add LogLine or LogObject activities at critical points within the workflow, for example, after "Get" or "Save" operations.

We recommend setting the Level value to Information for any LogLine or LogObject activities. See Best Practices for Logging and Logging in Azure.

Use the following settings in LogLine activities to catch all errors and all attributes associated with an object:

Level = Information
Text = Newtonsoft.Json.JsonConvert.SerializeObject(<object>, Newtonsoft.Json.Formatting.Indented)

Where <object> is replaced with the name of the entity for which you want to capture details, e.g., studentEntity. The log file will contain the values for all attributes of the specified entity.

NLog Levels

On the test system, in the CMCFormsRenderer_V3 folder, locate the NLog.config file.

In the <rules> section of the NLog.config file, change the minLevel to "Info". Do not change this on your production system.

<rules>
   <logger
     name = "*"
     minLevel = "Info"
     writeTo = "file" />
</rules>

Now any LogLines in your test machine that log to “Information” will be seen in the logs.

On your production machine where the minlevel is “Error”, these will not log, making it unnecessary to remove the LogLines from a production ready workflow (for performance reasons), with the option of enabling them if necessary.

Common Errors and Solutions

Scroll through the log file and locate the pertinent time stamps or search the log file with keyword “error”.

Some error messages include details about the cause for the error and tips to correct the issue. Correcting one issue may lead to the resolution of multiple related errors.

The following tables list common errors found in the Forms Renderer and Form Designer logs and provide suggestions for actions to take to correct the errors.

FormsBuilderRenderer Log
Error Type	Example	Action to take
Durable Instancing	Cmc.Nexus.FormsBuilder.Renderer.Web.Services.FormInstanceService The workflow version for this sequence may have been updated after the sequence was published. Records in the [System.Activities.DurableInstancing].[InstancePromotedPropertiesTable] table may be referencing a different version of the workflow. FormInstance WorkflowDefinitionVersionId: 2577 WorkflowDefinitionVersionId from DB: 2995	Clear persisted workflows and rerun the sequence.
Endpoint Not Found Exception	Cmc.Nexus.FormsBuilder.Renderer.Web.Controllers.FormInstancesController Unable to create new form instance: System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://<server>.anthology.com/Cmc.Nexus.Web/Services/Common/StudentService.svc that could accept the message. This is often caused by an incorrect address or SOAP action.	A form is trying to use an entity that does not yet have a service running. Check if the Anthology web service exists; if not, check if the service is supported.
Index Out Of Range Exception	Cmc.Nexus.FormsBuilder.Renderer.Web.Controllers.FormInstancesController Unable to execute a form instance service transition: System.IndexOutOfRangeException: Index was outside the bounds of the array.	In this case, a File Upload component was used with a GetAttachments activity and the ControlIdentifier argument was not correct (copied from another workflow). When the ControlIdentifier is incorrect, it cannot be connected to the File Upload control and GetAttachments will get no data.
JSON Serialization Exception	Cmc.Nexus.FormsBuilder.Renderer.Web.Controllers.FormInstancesController Unable to execute a form instance service transition: Newtonsoft.Json.JsonSerializationException: Cannot deserialize the current JSON object (e.g. {"name":"value"}) into type 'System.String[]' because the type requires a JSON array (e.g. [1,2,3]) to deserialize correctly. To fix this error either change the JSON to a JSON array (e.g. [1,2,3]) or change the deserialized type so that it is a normal .NET type (e.g. not a primitive type like integer, not a collection type like an array or List<T>) that can be deserialized from a JSON object. JsonObjectAttribute can also be added to the type to force it to deserialize from a JSON object.	Check the data type used most likely for the in/out argument.
Null Reference Exception	Cmc.Nexus.FormsBuilder.Renderer.Web.Controllers.AccountController Unable to logout: System.NullReferenceException: Object reference not set to an instance of an object.	Check the casing on the in/out arguments. If you initialized StudentID and not StudentId, the StudentId will be null.
Unable to get form from database	Cmc.Nexus.FormsBuilder.Renderer.Web.Controllers.FormRecordController Unable to get Form data from database: System.ApplicationException: Form Welcome does not exist in the database.	Using SQL check if the form exists in the database. If someone has manually deleted the form, work with your DB administrator to recover it, or create a new Welcome form.
Workflow Definition Version not loadable	WorkflowDefinitionVersion Id 'xxx' is not loadable.	Check if the versions of activities in the workflow are compatible with the versions of the products in your environment. This error occurs if you try to use newer activities in older product environments. Try to open the workflow in the environment where it is failing. If you cannot open the workflow, most likely the form sequence will not render properly either.

FormsBuilderDesigner Log
Error Type	Example	Action to take
Unexpected character encountered	Cmc.Nexus.FormsBuilder.Designer.Web.Controllers.Api.FormsController Unable to save Form data: Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: [. Path 'formsections[0].columns[0][1].ControlProperties[2].Value', line 1, position 7415.	Check the syntax in the Model property binding.