Getting Data In

Saved Search working in UI, but errors when called via REST

emiller42
Motivator

I have a rather complex saved search that functions perfectly when accessed via the UI. But when a job is kicked off via REST, it fails, giving the following error: "Error in 'eval' command: Failed to parse the provided arguments. Usage: eval dest_key = expression"

Here is the search string itself:

(sourcetype="livecycle:webserver:server" OR sourcetype="alfresco_cms:app:ds") tag::host="dev" nodeUUID=* 
| regex nodeUUID="[a-z0-9]{8}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{4}-[a-z0-9]{12}" 
| eval status=case(DS_PDFG=="doc_status_change",state, DS_PDFG!="doc_status_change",DS_PDFG, searchmatch("error OR fail"),"Error")
| rex "(?msi)Conversion failed\s*:\s*(?<conversionFailed>.*?)nodeUUID" 
| rex "com.adobe.livecycle.assembler.client.ProcessingException message:(?<processingException>.*)nodeUUID" 
| rex "javax.resource.ResourceException\s*:\s*(?<resourceException>.*)" 
| rex "javax.naming.NameNotFoundException\s*:\s*(?<nameNotFound>.*)" 
| rex "\{\"exceptionType\":(?<exceptionType>.*)\}" 
| rex "\'Error\':\s*(?<error>.*)nodeUUID" 
| stats first(_time) as time, first(status) as status, first(conversionFailed) as conversionFailed, first(processingException) as processingException, first(resourceException) as resourceException, first(nameNotFound) as nameNotFound, first(exceptionType) as exceptionType, first(error) as error by nodeUUID 
| eval reason=coalesce(conversionFailed,resourceException,processingException, nameNotFound, exceptionType,error) 
| table time nodeUUID status reason 
| where status="Error" 
| sort -time 
| convert ctime(time)
0 Karma
1 Solution

emiller42
Motivator

Actually answered this myself, but posting it all here in case someone else runs into this:

As you can see from the code above, there are line breaks to aid readability. They did not cause any problems when running the search through the UI. If I scheduled the search, and used REST to access the results, there was no issue as well. However they did cause the search to fail if a new job using it was kicked off via REST.

Removing the line breaks resolved the issue, and the search jobs now run appropriately when invoked via REST.

View solution in original post

emiller42
Motivator

Actually answered this myself, but posting it all here in case someone else runs into this:

As you can see from the code above, there are line breaks to aid readability. They did not cause any problems when running the search through the UI. If I scheduled the search, and used REST to access the results, there was no issue as well. However they did cause the search to fail if a new job using it was kicked off via REST.

Removing the line breaks resolved the issue, and the search jobs now run appropriately when invoked via REST.

Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Observability Simplified: Combining User Experience, Application Performance & ...

Tech Talk Observability Simplified: Combining User Experience, Application Performance & Network ...

Event Series May & June: From Network Visibility to Service Intelligence

Unifying the Network: Moving from Alert Noise to Service Intelligence with Splunk ITSI In today’s hybrid ...

Global Splunk User Group Events: May + June 2026

Your Splunk Community Awaits: Discover Upcoming User Group Events Worldwide    Staying ahead in the fast-paced ...