mksAPIViewer vs. CLI
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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.
Solved! Go to Solution.
- Tags:
- cli
- integrity_api
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
If i remove the --ipport flag I don't get anything back. I tried running both si about and im reports.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
I just opened a new case. Case #12355205
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
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.