How To Capture Enterprise Restful Diagnostics Tracing

Overview

This article explains how system administrators and internal support teams can capture and review diagnostics tracing for the Enterprise RESTful Website (also referred to to end users as the Impact Browsing Service).

The RESTful Website provides REST-based web services for the Impact CAD Browser. This allows Impact CAD clients to browse a central Enterprise-enabled Impact database over HTTP or HTTPS without requiring a VPN connection to the database server.

When errors or performance issues occur, Impact often displays only generic messages. The steps below describe how to enable and review built-in RESTful diagnostics tracing to identify the underlying server-side cause.

Audience & Scope

This article is intended for:

• System administrators
• Internal IT teams
• Internal or partner support staff

Anyone without access to, or familiarity with, the Enterprise services host should refer the issue to their internal IT / Enterprise administrator or to Arden Impact Support.

This applies to all versions of Impact CAD where Enterprise services are deployed, which typically includes multi-site environments using synchronised design databases.

When You Would Use This

Use this process to diagnose exceptions or performance issues where Impact error messages do not provide enough detail.

Examples include (but are not limited to):

• “The Impact Browsing Service was unable to process the request”
• HTTP/1.1 500 Internal Server Error
• “Unable to retrieve the Enterprise project information for the project ‘xxxx’”

Prerequisites

• Access to the Windows Server hosting the Enterprise RESTful Website
• Administrator or equivalent privileges on the server
• Permission to edit the RESTful Website web.config file
• Familiarity with IIS and application pool identities

Step 1: Locate the RESTful web.config File

1. On the server hosting the Enterprise RESTful Website, open the RESTful installation folder (path varies by deployment).
2. Locate and open the web.config file in a text editor running as Administrator.

This file controls diagnostics tracing behaviour for the RESTful service.

Step 2: Review Existing Tracing Configuration

Inspect the system.diagnostics and trace sections of the web.config file.

In many environments, tracing is already present but commented out or set to minimal levels. A basic trace configuration may resemble the following:

<trace autoflush="true">
  <listeners>
    <add name="Tracing"
         type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
         initializeData="C:\Path\To\Rest.log" />
  </listeners>
</trace>

Confirm that:

• The configured log file path exists
• The IIS application pool has write permissions to that location

Step 3: Verify File System Permissions

Ensure the IIS application pool identity running the RESTful Website can write to the log location.

Typically, this requires Write permissions for:

• IIS AppPool\<ApplicationPoolName>

Insufficient permissions may result in HTTP 500 errors without any diagnostics being written.

Step 4: Enable Diagnostics Tracing

The Enterprise RESTful Website includes a built-in diagnostics tracing mechanism. This tracing is configured directly in the RESTful Website web.config file and does not rely on native IIS tracing features.

For full background, supported options, and detailed guidance, refer to the Enterprise documentation article on Tracing.

If tracing is not already enabled, you can add or update the configuration as shown below (based on the Impact Enterprise Services help guide):

<configuration>
  <appSettings>
    <!-- Optional: restrict tracing to specific users -->
    <add key="TraceUsers" value="ADMIN;DESIGNER" />
  </appSettings>

  <system.web>
    <trace writeToDiagnosticsTrace="true" />
  </system.web>

  <system.diagnostics>
    <switches>
      <add name="Database" value="Error" />
      <add name="Thumbnails" value="Error" />
      <add name="RESTful" value="Error" />
      <add name="Extensions" value="Error" />
    </switches>

    <trace autoflush="true">
      <listeners>
        <add name="RESTTracing"
             type="System.Diagnostics.TextWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
             initializeData="C:\Path\To\Tracing.log" />
      </listeners>
    </trace>
  </system.diagnostics>
</configuration>

Info: The TraceUsers setting is optional. Use it to limit diagnostics output to specific users and reduce log volume when reproducing an issue.

Warning: Increasing switch levels to Info or Verbose can generate very large log files. Log growth is not restricted and may impact disk space and system performance. Use higher levels only for short diagnostic periods and disable or reduce tracing afterwards.

Step 5: Reproduce the Issue

1. Ask a single affected user (ideally listed in TraceUsers) to reproduce the browsing or project open issue.
2. Confirm the error appears again in Impact.
3. Review the generated tracing log at the configured location.

The log should now contain the underlying exception, database error, authorization issue, or service failure responsible for the problem.

Step 6: Disable or Reduce Tracing

After diagnostics have been captured:

1. Disable tracing or reduce switch levels as appropriate.
2. Save the web.config file.
3. Recycle the RESTful Website application pool if required.

Leaving diagnostics tracing enabled unnecessarily can negatively affect performance and disk usage.

Result

You should now have detailed server-side diagnostics explaining why the Enterprise RESTful Website was unable to process requests or why browsing performance is degraded.

If the cause is not immediately clear, collect the tracing logs and provide them to Arden Impact Support as part of a support ticket.

Further Reading

• Open Enterprise Project
• Impact Project Browser