EducationSoftwareStrategy.com
StrategyCommunity

Knowledge Base

Product

Community

Knowledge Base

TopicsBrowse ArticlesDeveloper Zone

Product

Download SoftwareProduct DocumentationSecurity Hub

Education

Tutorial VideosSolution GalleryEducation courses

Community

GuidelinesGrandmastersEvents
x_social-icon_white.svglinkedin_social-icon_white.svg
Strategy logoCommunity

© Strategy Inc. All Rights Reserved.

LegalTerms of UsePrivacy Policy
  1. Home
  2. Topics

KB15796: How to use SOAP tracing to troubleshoot connectivity issues with XMLA data sources in MicroStrategy 9.x


Community Admin

• Strategy


This document shows how to use SOAP tracing to troubleshoot connectivity issues with XMLA data sources in MicroStrategy 9.x

When troubleshooting issues with XML for Analysis (XMLA) connectivity, it may be necessary to examine the HTTP requests submitted by Strategy Intelligence Server to the data source's XMLA provider. In most cases, this information may be obtained by enabling the Strategy diagnostic log XMLA > Verbose Info.
It is possible, though unlikely, to have a discrepancy between the request submitted and that actually transmitted across the network. In that case, it is helpful to use a third-party utility to log the HTTP traffic. One such utility is TCPTrace from pocketSOAP. TCPTrace may be downloaded from the following location:
ttp://www.pocketsoap.com/tcptrace/
How it works
TCPTrace is not a packet sniffer. It captures only HTTP traffic going to and from a specific port on a specific machine; so, unlike network tracing, the amount of traffic captured is significantly less, and is targeted to the issue at hand.
In XMLA communication, Strategy Intelligence Server sends HTTP requests directly to the XMLA provider on the port specified in the Web application server hosting the provider, as shown below:
 

ka04W000001MKnNQAW_0EM440000002FGN.gif

 
TCPTrace intercepts the traffic on a different port, and relays it to the XMLA provider on the correct port, as shown below:
 

ka04W000001MKnNQAW_0EM440000002FGP.gif

Configuring TCPTrace
TCPTrace has only a few configuration parameters, as shown below:
 

ka04W000001MKnNQAW_0EM440000002FGJ.gif

 

  • Listen on port #: This is the port on the machine where TCPTrace is running were traffic to be monitored should be sent.
  • Destination server: The fully-qualified machine name, or IP address, of the web server where the traffic should be relayed.
  • Destination port #: The port number of the Web application server on the destination server machine.
  • Create Log File, Log Filename, Use XML logfile format: It is always recommended to create a log file when troubleshooting a conductivity issue with the assistance of Strategy Technical Support. The XML logfile format is recommended.

After clicking OK, TCPTrace will start monitoring traffic.
To capture XMLA traffic from Strategy Intelligence Server, it is necessary to modify the database connection object used by the XMLA database instance to point to the TCPTrace machine and "Listen on" port number. If this is not done, the HTTP traffic will be sent directly to the Web server, bypassing TCPTrace; in that case, nothing will be logged.
To configure the database instance to relay traffic through TCPTrace, perform the following steps:

  • In the Strategy Database Instance Manager, edit the database instance connecting to the XMLA data source.
  • Click "Modify..." toward the bottom to edit the database connection object.
  • Edit the uniform resource locator (URL), substituting the TCPTrace machine name or IP address and port in place of the XMLA provider's machine name and port. In this case, "localhost" is used because TCPTrace is running on the same machine as the Strategy Intelligence Server. TCPTrace may be used on a different machine, however; this allows the utility to be used even against Strategy Intelligence Server Universal running on a UNIX platform.
ka04W000001MKnNQAW_0EM440000002FGL.gif
  • In the Strategy Database Connection Monitor, ensure that there are no cached database connections for the XMLA database instance.

Strategy should now be able to communicate with the XMLA provider with no difference in behavior. The HTTP traffic should be visible in the TCPTrace window. If so, the user may proceed to reproduce the issue under investigation.
 

ka04W000001MKnNQAW_0EM440000002FGY.gif

 
When the test is complete, be sure to return the database connection object in Strategy to its original state, so that it will again send traffic directly to the XMLA provider.
 
NOTE: The TCPTrace log file is written only periodically as its logging buffer fills. The file may remain empty until the trace is terminated.
 


Comment

0 comments

Details

Knowledge Article

Published:

April 7, 2017

Last Updated:

April 7, 2017