The options you've suggested sound feasible as a starting point to consider, although may be difficult in practice - I don't have much to add. You're right that business adapters won't be able to be used to bring in this type of data; the data will need to be in an NDI format, whether that is produced by Flexera tooling or bespoke tooling.
But this does make me wonder why you are seeking to bring in this information, and whether there are deeper issues to consider beyond the technical question of how to get data into Flexera One.
In particular: It sounds like this is infrastructure that is operated by a service provider who - as a direct consequence of not giving access to VMware APIs as part of the service they provide - is intentionally not providing transparency around the underlying physical host hardware, VM-host relationships, and clusters.
A logical consequence of this arrangement is that it would be very poor (risky) practice to deploy any software to this environment where the licenses require that type of information to be gathered. On the (optimistic?) assumption that such a poor practice has not been followed, it's possible this data doesn't need to be gathered for Flexera One and you can simply avoid doing what you're trying to do. Treat the underlying infrastructure as a black box (like is generally the case with virtual instances running on public clouds).
On the other hand, if such a poor practice has been followed, maybe the right discussion to have is to use the information from Flexera One to help identify software that should be removed from this environment and deployed in an environment where the required transparency can be achieved.
(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
