mksAPIViewer

[wstokes]

In my workflow, I use Python scripts to construct and execute Integrity CLI commands, utilising the Python subprocess module.

This works well, but parsing the output from the CLI commands is tricky and not particularly robust. 

I have recently been made aware of mksAPIViewer.exe

I have started experimenting with this approach of prepending

mksapiviewer --iplocal --xml

To the start of my CLI commands, for example;

mksapiviewer --iplocal --xml im viewissue --hostname=<host> --port=<port> <item ID>

This returns me the output, but in XML format. This is much easier to process.

I am keen to understand why this seems to be quite hidden away in Integrity? It appears to be an improvement on the standard CLI output. Should I be using it, or is there some better approach which I have not discovered?

Many thanks,

Will

[awalsh · Accepted solution]

The output from the API is definitely an improvement over the CLI when parsing information with scripts.  The output is intended to be parsed, whereas the CLI output is intended to be human readable. 

The mksAPIViewer uses the C API. You can find documentation about the mksAPIViewer and the Java API viewer in the Integrations Builder Guide. See "Viewing Responses with the API Viewer Utility"

(p. 39 in 12.0 guide:

https://www.ptc.com/support/-/media/8B8CB69390BE4444965F0B15906A143F.pdf?sc_lang=en)

You can also find a list of Published Commands in the Integrations Builder Guide. Not all CLI commands will work with the API. 

[wstokes]

Thanks for the response,

The core of my application is Python so I have something like this;

import subprocess as sp

cmd = im viewissue --hostname=host --port=port 12345
cmdxml = mksapiviewer.exe --iplocal --xml + " " + cmd

response = sp.Popen(cmdxml, stdout=sp.PIPE)
response = response.stdout.read()

Which puts the XML output, as a string, in response. I can then parse this with an XML library, and search it with XPath (or however I like...)

Is there any disadvantage of the C API viewer over the Java? The approach above is compact and robust (as I know that mksapiviewer.exe is located in the same folder as im.exe/si.exe, so it will be on the path). Using the Java approach requires more fiddly Java setup.

So as long as the approach above is sensible, I think I am happy to continue with it.

Many thanks for your input

Will