Debugging the workflow

The process for debugging is different for the two phases of the Data Connector workflow.

• Debugging the interactive phase

  The interactive phase occurs in the user’s browser, which means that the Javascript surrounding this phase can be debugged using the browser’s developer tools.

• Debugging the fetch table phase

  The fetch table phase is executed in a NodeJS context within the Intelligence Server (IServer), which means that debugging cannot be handled as normal using the browser’s developer tools and must be handled differently.

To detect whether the Data Connector's Javascript is being executed within the browser or within the NodeJS context in the IServer, you need to inspect the user agent. If the user-agent contains node.js, you can assume the code is currently being executed within the NodeJS context. For example:

var isNode = function(){window.navigator.userAgent.toLowerCase().includes("node.js");}        

If you determine that the code is being executed on the browser, simply debug using the browser’s developer tools. However, if the code is being executed on the IServer, you can try one of the methods described below to help debug your fetch table code.

Debugging the fetch table phase

The fetchTable function defines how to fetch the data and convert it to the format required by MicroStrategy. Debugging this function can be challenging because it is executed on the IServer. When an error occurs, an error message like the one below is returned:

If you try debugging the code normally, it may appear as if some logic is never called since breakpoints are not being hit within the browser’s developer tools. This is because that component of the data connector is never executed by the browser, and is only executed within the IServer’s NodeJS context.

There are several possible ways to help debug the code executed on the IServer.

• Debug load_data.js

  When the IServer executes the fetchTable function, it uses the jsdom library inside the Node application to load the connector page. For a Windows installation, it uses the file C:\Program Files(x86)\MicroStrategy\Intelligence Server\GenericGateway_SDK\load_data.js. The IServer runs load_data.js with the following arguments:

  • Connection URL: URL to your connector page
    This is the same URL you used when you added the connector to the Data Import page.
  • StrictSSL: Specifies whether or not to do SSL key validation when making requests
    Possible values are 0 or 1.
  • IServer address: IP address of the IServer
    In production, this value is used to send data from the Node process to the IServer. During debugging, using a real IServer address for this argument may cause unexpected problems. Instead, use a non-existent IP address, such as "abc".
  • IServer port: Port used by the IServer
    In production, this value is used to send data from the Node process to the IServer. During debugging, using a real IServer port for this argument may cause unexpected problems. Instead, use an invalid port number, such as "-1".

  • Parameters: Base64-encoded parameters you set before you call the submit function
    For example, for a table named omdb, the parameters could be expressed as the base64-encoded value of the following JSON string:

    {"connectionName":"omdb","fileType":"FORMAT_JSON","connectionData":{"value":"titanic"},"tableList":[{"tableName":"omdb"}]}
    

  • Table name: Name of the table

  • Authentication type: Type of authentication to use
    Possible values are Anonymous, Basic or OAuth.

  If you provide the arguments listed above and debug load_data.js, you will be able to debug the fetchTable function for your data connector.

  Here is an example of a full Node command:

  node load_data.js http://localhost:8080/omdb/index.html 1 localhost 12345 eyJjb25uZWN0aW9uTmFtZSI6Im9tZGIiLCJmaWxlVHlwZSI6IkZPUk1BVF9KU09OIiwiY29ubmVjdGlvbkRhdGEiOnsidmFsdWUiOiJ0aXRhbmljIn0 sInRhYmxlTGlzdCI6W3sidGFibGVOYW1lIjoib21kYiJ9XX0=omdb Anonymous

  Before running the command, you need to turn on the debug flag in load_data.js so that logs are displayed in the console. To turn on the debug flag, set mylogger.debug to "true" in load_data.js.

• Debug the Node app in Chrome

  Refer to the Node Debugging Guide for specific instructions for how to debug NodeJS code in Chrome.

  1. Open "chrome://inspect" in the Chrome browser.
  2. Click the Configure button and ensure that the target host and port are listed.

  3. Run the node command with --inspect -brk, like the following:

     node –inspect-brk load_data.js http://localhost:8080/omdb/index.html localhost 12345 eyJjb25uZWN0aW9uTmFtZSI6Im9tZGIiLCJmaWxlVHlwZSI6IkZPUk1BVF9KU09OIiwiY29ubmVjdGlvbkRhdGEiOnsidmFsdWUiOiJ0aXRhbmljIn0 sInRhYmxlTGlzdCI6W3sidGFibGVOYW1lIjoib21kYiJ9XX0= omdb Anonymous

  Now, you can inspect the code in Chrome DevTools. You will be able to see your JavaScript file and set break points.

• Use a logging function

  One way to gather the debugging information that does not show up in the developer tools is to output logging information using a logging function. You create a logging function, which triggers a specific HTTP request every time it is called, like the one shown below:

  Copy

  function logInfo(logMessage) {
    console.log(logMessage + “&isBrowser=” + isBrowser() + “&isNode=” + isNode());
    $.get(“https://myserver.com/MicroStrategy/log?message=” + logMessage +  “&isNode=” + isNode());
  }

  Whenever this method is manually invoked within the data connector’s logic, it passes the parameter to the end of the URL and executes an HTTP request against the web server at the address provided. You can then parse the access logs on the web server to read the messages that were sent through.

  In a UNIX environment this can be done using the following command:

  Copy

  tail -f ./localhost_access_log.2017-06-15.txt | grep “log?”        

  This works for requests coming from either the Intelligence Server or the user's browser.

See also

• Understanding the Data Connector workflow
• Creating custom error messages
• Handling invalid certificates