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!

Step into “Hunt the Insider: An Splunk ES Premier Mystery” to catch a cybercriminal ...

After a whole week of being on call, you fell asleep on your keyboard, and you hit a sequence of buttons that ...

SplunkTrust Application Period is Officially OPEN!

It's that time, folks! The application/nomination period for the 2026-2027 SplunkTrust is officially open. If ...

Announcing Modern Navigation: A New Era of Splunk User Experience

We are excited to introduce the Modern Navigation feature in the Splunk Platform, available to both cloud and ...