cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

mksAPIViewer vs. CLI

SOLVED
Highlighted
Regular Member

mksAPIViewer vs. CLI

If I run this command in mksAPIViewer, I get an exception. If i just run the simple CLI it works fine. Any idea how I can troubleshoot this? Is it a server configuration thing? I've removed the hostname from the string.

mksAPIViewer Command:

.\mksAPIViewer.exe --iphostname=<address> --ipport=7001 --namedsession --sessionuser=user --sessionpassword=pass im reports

Response:

App. Name = im

Command Name = reports

APIException:

Class = CommandCancelledException

Message =

Field:

Name = exception-name

Data Type = wchar_t *

Value = common.CommandCancelled

Exit Code = 2

I can run si about and that will execute just fine in the mksAPIViewer. Also, if I just run si reports (not using mksAPIViewer) it'll return the reports without any problem.

Tags (2)
1 ACCEPTED SOLUTION

Accepted Solutions

Re: mksAPIViewer vs. CLI

Hi Nolin,

I was able to get this to work by specifying the connection hostname /port and user name /password as additional parameters after issuing the ‘im reports’ command:

.\mksapiviewer --iphostname=<hostname> --ipport=7001 --namedsession --sessionuser=tester --sessionpassword=password im reports --hostname=<hostname> --port=7001 --user=tester --password=password

View solution in original post

7 REPLIES 7

Re: mksAPIViewer vs. CLI

Hello Nolin,

It looks like the --ipport flag is the culprit. Remove it and the command should complete successfully.

I would also open a case with PTC Technical Support to report this and get an RFC posted if one does not already exist.

Re: mksAPIViewer vs. CLI

If i remove the --ipport flag I don't get anything back. I tried running both si about and im reports.

Re: mksAPIViewer vs. CLI

I was just in the process of editing my post to mention that. As it turns out, the command worked for me because I already had a successful API connection so it cached the port for me. When I have no existing API connection and remove the --iplocal flag, it gives me an error about invalid credentials.

There is defintely something screwy with mksapiviewer here so a case would be great to find the defect. In the meantime, you could try using a local client integration point for mksapiviewer:

mksapiviewer --iplocal im reports

Re: mksAPIViewer vs. CLI

I just opened a new case. Case #12355205

Re: mksAPIViewer vs. CLI

Hi Nolin,

I was able to get this to work by specifying the connection hostname /port and user name /password as additional parameters after issuing the ‘im reports’ command:

.\mksapiviewer --iphostname=<hostname> --ipport=7001 --namedsession --sessionuser=tester --sessionpassword=password im reports --hostname=<hostname> --port=7001 --user=tester --password=password

View solution in original post

Re: mksAPIViewer vs. CLI

Stephen,

Thank you for looking into this. Your solution works for me as well. Is this the way that the command string is supposed to be or is this a work around? Could something be a little off with our server? We do not have a production environement so everything is new. We only have a test environment setup. Is there something that we could have missed? It seems awkward to have to specify a username, password, and host name twice.

Thanks!

Re: mksAPIViewer vs. CLI

Hi Nolin

I would say it's working as designed, although it could be a little more intuitive.

The mksAPIViewer needs the connection information in two contexts: for establishing the integration point, and to execute a command against a running Integrity Server. I'd agree it's a little akward, but in my experiences being explicit with the API Viewer is usually necessary in order to get the correct results. If anything, we could report a more meaningful message to offer some clues as to why the command isn't running.