MicroStrategy ONE
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:
Error in importing file. Check the file to import.[Get data failed. Error in importing files. Please check the file to import. Error type: Data Import Error. No data was loaded. Node JS command may exit unexpectedly.]
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.
- Connection URL: URL to your connector page
-
Debug the Node app in Chrome
Refer to the Node Debugging Guide for specific instructions for how to debug NodeJS code in Chrome.
- Open "chrome://inspect" in the Chrome browser.
- Click the Configure button and ensure that the target host and port are listed.
-
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:
Copyfunction 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:
Copytail -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