Extract Raw Output from Datapoint into Custom HTTP Integration
Hello all,
I'm not sure if this is possible but I'm going to ask here as a last resort.
I simply want to extract the "output" of the "Raw Request/Response" section of a SP Datapoint to be able to post it as JSON (or raw text) into a Google Chat webhook I have configured. The alert works perfectly fine, as well does the custom HTTP integration for the webhook, but it can only post the ##VALUE## after the Complex Datapoint runs (post processing) which converts the number of records returned from the Database into a number that can be alerted upon with a threshold. It's essentially just the number of rows returned, which works for the alert portion. I just want the actual values extracted somehow and appended to the Chat message, so the team watching for these alerts can quickly identify the issue. We are manually copying and pasting this information from using Raw Data > Poll Now and adding it to the chat room after the alert triggers, and I want to automate away this portion.
After reviewing the tokens available for DataSource tokens, I don't think it's possible. Needless to say, I was wondering if anyone here had a "magic work-around" or knew a way to make this possible.
** And to clarify, this SP only ever returns a handful of results at a time, so maximum size of the payload would never be reached. It checks for a particular type of rare error we have.
Nathan_Ribelin
OP4 years agoI see, thanks for clarifying this. I might try this out if one other option I researched does not work.
Alternatively, I'm going to try and configure and EventSource with a custom Groovy script to execute the Stored Procedure and try to extract the results this way, so it accepts string output. Not sure if this will work either but I'm going to give it a shot. I appreciate the response @mnagel! Will keep that auto-discovery method as a backup.
mnagel
·4 years agoYou are correct -- you cannot store text values in datapoint results, only numbers. The "cheat" workaround to this is to use auto-discovery in the datasource at a rapid enough rate that you can populate instance auto-properties with the test results that are (hopefully) close enough to true and then emit them to your integration. And you would need to implement the DS in Groovy (if not already) as auto instance properties are not supported in most other data collection types.
What you see in many datasources as a workaround to the numbers-only limitation is a hardcoded manual map of numbers to strings, typically only shown (truncated most of the time) in chart legends. I submitted a feature request long ago to make those first-class by creating enum mappings within datapoint definitions, allowing those strings to be used more generally. Sadly, as is the case for feature requests it is just a way to vent and not to actually get anything done. Most of the time, anyway.