Best Practices for Groovy Script Datasources that call the API? | Product Discussions

Lewis_Beard · 2025-05-14T14:42:14.768000Z

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?

Discussions

Best Practices for Groovy Script Datasources that call the API? | Product Discussions | LogicMonitor Community