topic Re: NMSDK 5.5, ZExplore, and Ontapi 1.31 versus 1.32 in Software Development Kit (SDK) and API Discussions

NMSDK 5.5, ZExplore, and Ontapi 1.31 versus 1.32

dkorns — Wed, 04 Jun 2025 19:34:13 GMT

Starting my first attempt to use NMSDK so I apoligize in advance if this is a dumb-newbie question.

My lab is based on ONTAP 8.3.2 simulators.

My first attempt to play with ZExplore and connect to an 8.3.2 vsim fails with:

... and when I look at the API choices in ZExplore (this is Zexplore 2.3.1 included with NMSDK 5.5)

So is this saying 8.3.2 reports a higher Ontapi version (1.32) than Zexplore can handle? ... which seems to only support up though 1.31 then 1.100 (for ONTAP 9 as I understand from elsewhere)

Is there a way around this (safe or unsafe) by setting something. I've tried to choose 1.31 manually (as it suggests) but same error reported.

... or am I looking at down rev'ing my simulators?

Re: NMSDK 5.5, ZExplore, and Ontapi 1.31 versus 1.32

asulliva — Thu, 11 Aug 2016 15:01:29 GMT

Hi David,

Zexplore is simply lacking awareness of ZAPI 1.32. You can safely use version 1.31 for the vast majority of operations...you might encounter an occasional issue if there is a discrepancy between 1.31 and 1.32, where Zexplore is using the 1.31 specification but 1.32 differs in some way.

If you're looking at the ZAPI docs, and not relying on Zexplore 100%, you'll be able to spot the differences. There is also a "What's New" section of the ZAPI docs which should point out differences between the versions.

You could also use the internal Zoom tool.

Andrew

Re: NMSDK 5.5, ZExplore, and Ontapi 1.31 versus 1.32

dkorns — Mon, 22 Aug 2016 21:23:49 GMT

Thanks Andrew. That answer makes sense but my real problem was I thought ZExplore was refusing to connect to the cluster. It was just warning me about the API version difference. The GUI gave no visual clue that it also went ahead and accepted the conneciton and ran the workflow step(s) ... until I happened to notice it the next time I was trying it out days later.. Oh well, never mind.