PreEmptive Analytics Workbench User Guide

Testing the Installation

To test the installation, you will need to generate and send test messages, and then check that the messages were routed and processed correctly.

Generating test messages

There are two approaches to generating and sending test messages:

Option 1: Using an instrumented application

You can instrument your applications either through code injection or by writing directly to an API.

PreEmptive offers two tools that can inject analytics messaging code into your applications: Dotfuscator for .NET and DashO for Java. You can get an evaluation of either of these tools from our website.

We also offer APIs that you can use for .NET, Java, JavaScript, iOS, and native code. Our API downloads contain documentation and sample code. You can get the APIs on the downloads page on our website, under the "Additional Downloads" section.

If you wish to start with instrumentation via injection, see our Instrumentation Injection Quick Start document and our Instrumentation injection tutorial video. Both of those resources focus on instrumentation injection for .NET with Dotfuscator, but DashO for Java users will still find the information valuable.

When configuring the instrumented application, use the Data Hub endpoint URL noted at the end of the Data Hub installation.

Option 2: Download a free testing tool

  1. Download and unzip our test message sender. This is a simple HTML page that can send analytics messages using our JavaScript API.

  2. Edit the test message sender file and enter the endpoint URL for the Data Hub noted from the installer dialog. You will also need to supply GUIDs for the company ID and application ID where indicated.

  3. Disable "Do Not Track" in your browser. This page, in the "For users" section, indicates whether your browser currently has Do Not Track enabled, and links to instructions on how to change it. (Note that if it is your preference for "Do Not Track" to be enabled, you should re-enable it after testing your installation.)

  4. Open the test message sender page in a browser, and then click one of the buttons that creates an exception. Make sure to enable the JavaScript in the page if needed to allow the messaging code to run.

Check that the messages were processed correctly

Once you have generated and sent some test messages, you should:

  1. Wait approximately 90 seconds. The very first message received usually takes longer to process than later messages.

  2. Check to see if data corresponding to the messages you sent shows up in the Workbench Portal (http://127.0.0.1:88). If you have the Portal page already open when you send the data, you will need to refresh the page for the data to show up. (Note that a browser refresh is only needed in the case where a new filter value is added, as is the case when you send your first messages to the Workbench.)

When you are finished testing, you can purge your test data from the Workbench by using the administration console provided with the Workbench. Note that using the purge command will purge all of your data, so please use this carefully.

Troubleshooting

Once you have instrumented an application, if you are not seeing data appear in the Workbench Portal, start by just refreshing the browser page, rather than using the "Apply" or "Refresh" button within the page.

If that doesn't work, we recommend using Fiddler to monitor network traffic both on the client-app machine and the Workbench machine. That will usually help you understand and resolve any instrumentation issues.

If you are sure that instrumentation data is reaching the Data Hub's endpoint, but you still aren't seeing it in the Portal, then there are a variety of tools that can help diagnose issues:

  • All application-level and some underlying errors will be reported in application-specific sections of the Windows Event Log. (They all start with "PA".)

  • RabbitMQ has a management console that shows the status of each configured queue. It can be found at http://localhost:15672/#/queues. Login as guest/guest.

    • If any of the queues are growing, there may be a problem with the Data Hub or the Workbench, so you might need to try restarting components as described below. There will be messages in the Event Log explaining the issue.
    • If all of the queues are empty or near-empty, and you see occasional non-zero rates in the "Incoming" column (as you generate data in your client apps), then information is being received and processed correctly by the Data Hub and the Workbench.
  • If you wish to try restarting things, follow this order:

    • RabbitMQ
    • MongoDB
    • PreEmptive Workbench Computation
    • PreEmptive Analytics Data Hub Dispatch Service
    • IIS (easiest to just restart IIS entirely)
      • This will restart the two endpoints (Data Hub and Workbench) and their app pools

It is safe to restart RabbitMQ and/or MongoDB while the other components are still running.

  • For more in-depth troubleshooting, you might wish to investigate:
    • The MongoDB log in C:\mongodb\log (by default)
    • The various WMI monitors for the Data Hub and the Workbench. If you run Performance Monitor and "Add Counters", you can browse to the PA Data Hub and PA Workbench categories to find counters that can show detailed state information about each component.


Workbench Version 1.2.0. Copyright © 2016 PreEmptive Solutions, LLC