Forum Discussion

Lewis_Beard's avatar
Lewis_Beard
Icon for Expert rankExpert
7 hours ago

Best Practices for Groovy Script Datasources that call the API?

In the past, any datasources I've written, where I use groovy to reach out to the API to collect data, they were datasources on our portal object. The appliesTo was only for that portal resource, and so we have the lmaccess.id and lmaccess.key and the account set on the portal object, and we use hostProps.get to grab those, and then I can reach out to the API to pull what I need and set my datapoints.

But now, I actually want to write a datasource that runs against normal resources, where we dont have those API keys set. I'm looking to, for a bunch of resources, collect and roll up some info into a custom datasource. But we dont have those lmaccess values set anywhere other than the portal object.

I dont want to hard code credentials in my groovy script. I also dont really want to have to set the lmaccess.key and lmaccess.id globally or anything. I looked at a few at random that are script-based and they often call underlying things like snippets or hidden packages like a vsphere sdk or something.

What would be considered best practices for groovy datasources in this case? Where you need to call the API but you dont want portal passwords slammed all over your source, or even spamming up resources on your portal just to get at them with hostProps.get?

1 Reply

Sort By
  • Mike_Moniz's avatar
    Mike_Moniz
    Icon for Professor rankProfessor
    7 hours ago

    I don't know about best practices but I would likely stick with using lmaccess properties myself. As an MSP, most of our collectors are hosted within the customer's environment that we don't fully own. The LM API would be called from these customer collectors in this situation, so in the past I've created per-customer API keys that only has access to their items. This would prevent (even if unlikely) the customer being able to extract/observe an API key that can access other customers.

    What I've also done, although that might be to limited here, is create kinda "virtual" devices in LM that is placed in the customer's groups but is assigned to a collector we host. Basically like your Portal Resources but one per customer. But sounds like you need something more broad than that.

    I don't think the snippets and such that LM provides will have LM API access but don't know for sure. I hope not since that might mean customer collectors have more access then they should.