Description

Each component of Foundation has a method of logging. These logs only capture information related to that component as verbose log files can grow large quickly. In many cases, Winshuttle Support may ask for more than one type of logging.

You can turn logging at any time, which helps in identifying root causes. Just be aware that logging causes a performance reduction. The Winshuttle Workflow logging is especially hard-hitting on the system.

User Governance

This logging captures information related to logging into Foundation through Studio, licensing, uploading scripts, processing scheduled script and data file jobs, and other functionality of the User Governance site.

To enable this logging, you need to be on the Foundation site as someone with the Central Application Administrator role.

1. Click on Settings in the menu.
2. Click on Logs and Reports Settings.
3. Prior to setting the log level, it's good practice to clear any previous log data. Do that by setting the "Clear Log for:" drop down to all and clicking on Execute.
4. Set the Logging level to "All" and click Execute.
5. Replicate the issue.

Be sure to turn off logging by setting the Logging level back to either "Error" or "None". If left on, the logging table will grow and reduce Foundation performance.

Workflow

Workflow logging has several types that focus on an aspect of forms and workflows. All logging is enabled through the Workflow Central Administration site, on the Logging page.

By default, most logs should be a the Core type. Be sure to select Clear Prior Logs so the capture only has fresh data, but be sure that once the issue is captured the log is downloaded prior to logging being turned off or it will clear the newly captured log when Save is clicked.

1. Go to the logging page in Workflow Central Administration.
2. Check the correct Logging Type.
3. Select "Clear Prior Logs".
4. Click "Save".

Almost immediately after clicking save, the logging will start writing information to the log file. You may experience extreme slowdowns on Forms site when Core logging is enabled.

After the issue is captured, go to the Log Viewer page in Workflow Central Administration and set the Display drop down to All or click the Download All Logs link in the upper right. Once the log is saved to a local computer, logging can be disabled.

LMS

LMS logging is largely to capture IIS site functionality and communication with other Foundation components. Logs are automatically captured and saved on the LMS server in the virtual directory/site/logs folder. For example:

C:\Program Files\Winshuttle\LMS\Site\Logs

There are no configuration options for this logging, which are defined in the LMS site's web.config.

Gathering log files requires access to the LMS server.

Composer

Issues with the Composer site can be analyzed through Composer logs. Like LMS, logging is stored on the server in the virtual directory\logs folder. By default, Composer logs are set to only capture errors, but this can be changed to verbose logging by changing the nlog.config file in the Composer site virtual directory root. Change the minlevel property to "debug" and save the file.

When editing .config files, an Administrative Notepad instance must be used which means an administrative account must be used. Server access is required to gather logs.

Composer has a runtime logging available to assist. When Composer or a Composer-developed form is open in the browser, press CTR+F12 to open Blackbird logging. This can help isolate problem fields and may be requested by Winshuttle Support.

SAP Integration Server (SAPIS)

This logging captures information related to web services in forms and workflows and scheduled script jobs from Foundation. Basically, any time a Winshuttle Foundation product communicates with SAP, it will run through this component and logging.

Like Workflow, SAPIS logging has several types that focus on a particular functionality.

Logging by default is set to only capture errors. When troubleshooting, verbose logging is useful.

To enable logging for SAPIS, log into the SAPIS server with an administrative account and perform the following steps:

1. On the desktop, right-click and run as administrator the Server Administration utility.
2. Click on either the Manager, Worker, or Worker Launch GUI tab.
3. Click on Load Configuration
4. In the Log4Net section, change the level to ALL.
5. Click Apply Changes.

In the Worker and Worker Launch GUI tabs there are additional log types beyond developer. These should not be enabled unless directed by Winshuttle Support.

For Manager logs to take affect, the WinshuttleServer IIS site's application pool must be recycled.
For Worker logs to take affect, the Winshuttle Worker Windows service must be restarted.
For Worker Launch GUI logs to take affect, the Winshuttle Worker Launch GUI Windows service must be restarted.

Manager log files are written on the SAPIS server to to the SAPIS install directory under manager\temp.
Worker log files are written on the SAPIS server to to the SAPIS install directory under worker\temp.
Worker Launch GUI log files are written on the SAPIS server to to the SAPIS install directory under Worker Launch GUI\temp.

To gather SAPIS logs, server access is required.

Installation Logs

If a customer facing issue while upgrading or Installing Winshuttle Products ask for the installation logs.

For the Installer logs go to the folder where user have kept your installation file there should be log file automatically created or else user can go to File Explorer- Type %temp% and look for the hexadecimal numbered folder.

Event Viewer Logs

It is always recommended to have the Event viewer logs from the server as well to check the server is functioning correctly and there are no Sharepoint or the SQL issues.

Event View logs

Applies To

Foundation 11

Official Documentation

Foundation User Governance Logging
Foundation Workflow
Foundation Composer
Foundation SAPIS