Is there a way to set custom property values from your groovy script in your datasource?

I don’t think hostProps.get() does anything in production. Even if it did, you’d want instanceProps.set(), but AFAIK that doesn’t do anything either. There are two ways to write a property to an instance: 1) discovery and 2) API (or you could hack the collector).

Discovery:

If you want, your discovery script can set/update instance level properties every time it runs. The most frequent you can force this to run is every 15 minutes, so that may not work. However, if you want to go that route, you’d need to include something in the 5th term of each discovery script output line. Each output line has 5 terms, separated by double hashtags. The last is a url parameter style list of properties. So, if your discovery right now is outputting:

id##name##description

You’d need it to output:

id##name##description####prop1=value1&prop2=value2

Where prop1 and prop2 are the names of the properties you want to add and value1 and value2 are the values of those properties, respectively. More here.

API

If you need it more often, you would need a function in your collection script to call the API to patch the instance’s properties. The UI does this with a PUT on the instance, so you’d have to have the entire definition of the instance in json format so you could update it. There is a PATCH option, which might fit your use case better. All of this requires now that your DS have access to API credentials as properties. All of that is doable, but I haven’t done it before. In this case, you’re basically replicating what instanceProps.set() would do.

Put in another feedback ticket for instanceProps.set() (and hostProps.set()).
 

Also, this is exactly what LM Actions should do, if it ever becomes more than an idea.

No, that should work if the property exists. You can’t call instanceProps.get() from discovery though, only collection. To verify the properties are present, you can look up the task details in the collector debug console. Here are the docs on the *Props.get() methods.

Collector attribute script = collection script. *Props.get() methods should work there. Do the properties exist on your instances?

No, that’s the right place. instanceProps.get(“blockerdetails”) should do it. What’s your collection script look like (don’t forget to redact any keys)?

It’s set to batchscript.  Should it be script?

Also it is greyed out and doesn’t give me the option to switch it if i wanted.

OOTB.

I was tweaking it but still using the OOTB

Yes exactly.  The collection script can pull the desired info.  I am just unclear what the best approach is to display that to the user through alerts and the triggered emails

No this helps a good bit.  Thanks.  Time to bust out some python

I did put a support ticket requesting just that. an example of a patch in groovy.  lets see what they say

If you’ve got postman working, you’re doing well. That’s where most people trip up.

So, you need to construct this URL to do your patch:

/device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{id}

To do that, you need three variables: deviceId, hdsId, and id. Sounds like you already have deviceId. 

To get hdsId (hardware datasource id, don’t ask why it’s called that, it doesn’t matter), you’ll need to do a GET on :

/device/devices/{deviceId}/devicedatasources?filter=dataSourceName:"Microsoft_SQLServer_GlobalPerformance"&fields=id,dataSourceName

The response will give you, as you’ve seen, the list of datasources on that device, but with the filter specified above, you should only get a response if there’s been an instance discovered on the device whose device ID is {deviceId}. If there’s not one there, you have chosen the id of a device that doesn’t have an instance for that datasource.

From there, you can use the id from the response (which is different for every device, yay!) to get the list of instances that you will be attempting to patch. Do a GET on:

/device/devices/{deviceId}/devicedatasources/{hdsId}/instances

The id shown in the response for each instance is the id that should go in the PATCH url.

Also, when you go to do your patch, there’s a query parameter: opType that will affect how your patch works, especially when it comes to properties. The swagger docs don’t even tell you what the possible values are much less what they do, so here it is:

Define custom properties for this device. Each property needs to have a name and a value. To add or update just one or a few device properties in the customProperties object, but not all of them, you’ll need to additionally use the opType query parameter. The opType query parameter can be set to add, refresh or replace. opType=add indicates that the properties included in the payload will be added, but all existing properties will remain the same. opType=replace indicates that the properties included in the request payload will be added if they don’t already exist, or updated if they do already exist, but all other existing properties will remain the same. opType=refresh indicates that the properties will be replaced with those included in the request payload.

So, the possible values are add, replace, and refresh. 

Add - You specify the properties you want to add. Existing properties are untouched. New properties are added. If your payload has a property that already exists, that property isn’t modified.

Replace - You specify the properties you want to update. New properties are added. If your payload has a property that already exists, that property is updated to match your payload.

Refresh - This is the nuclear option which will delete all properties and replace them with the properties in your payload.

You’d probably want to do replace.

So I began trying to port over what I have done with postman into my groovy script.  (I know you said you had much better success using python, but I still wanna give it a try first)

Interesting note.  I was able to successfully make a get request using this line.

def http_body = httpClient.get(endpoint_url, ['Authorization': ‘{{the authtoken copied from postman','Content-Type': 'application/json','Cookie':'JSESSIONID=17513E3CB1FC4E623F829A629A16B811'] );

now when i try to take everything in those square brackets for the header and put them into a variable and use them the same way

def http_body = httpClient.get(endpoint_url, headers);

i get an error.  interesting.  

I made sure it wasn’t expired.  Like i said when i just hard code the header i get a success.  but when i try to put the same info into a variable and use it I get 

The script failed, elapsed time: 0 seconds - No signature of method: com.santaba.agent.groovyapi.http.Client.get() is applicable for argument types:

I do understand that yea this method won’t work long term either way for that very reason.  I’m just taking this one small step at a time so I know what I’m doing is working every step of the way if that makes sense

when the auth does expire i get an auth error within my test.  not from the script itself

def headers = ‘["Authorization": "LMv1 PHf4xEdZHA5sz8U5ECM8:NzJjNzMzZDkyZjdmMDY0MWYwMWUwZmU3Nzc1ZDUzZjIwY2I3OWEyZGU3NGU5MmE1YzhiNWM3NTA5NDViZmFhZA==:1684428033047","Content-Type":"application/json"]’