"No sensors defined" after result comes back from scripted RestMessage call

[treycarroll]

All,

I can see my out/in responses in the ECC Queue to the execution of this script.

var r = new RESTMessage('asdf', 'post');
r.setStringParameter('attributeName', 'asdf');
var response = r.execute();

However, the input queue entry always errors with the message "No sensors defined", even though I have created a Sensor that "responds to Probe" RESTProbe (OOTB).

I need to know how to connect this new Sensor to the RESTProbe.  

I have tried making the Sensor name match the "Reacts to Probe" value as I see with the OOTB Sensors, but that doesn't make a difference.   I have ensured that the agent value matches the MID Server that is set on the REST endpoint.

I cannot upgrade to Fuji right now, so I'm stuck using RestMessage V1.      

Any pointers would be appreciated.

Regards.

Trey Carroll

[brian_quinn]

Trey,

As a workaround you could change the sensor to a business rule on the ecc_queue table, and add "r.setEccParameter('skip_sensor', 'true');" to the script that triggers the REST Message.   This will prevent the "No sensors found" error, and then your business rule can process the message and mark the ecc_queue record as processed.

Is there a reason you do not want to handle the processing of the message in the same script that triggers the outbound message like is demonstrated in the wiki?

Scripting Outbound REST - ServiceNow Wiki

Thanks

Brian

[treycarroll]

Hi Brian,

Thanks for the high-quality reply.   It is much appreciated.

I thought that your suggestion was excellent:

then your business rule can process the message and mark the ecc_queue record as processed.

I was able to silence the error with the skip_sensor param, but I was trying to "cooperate with the platform" and correctly use Sensors where appropriate.   My understanding of probes and sensors comes from CMDB work where Sensors seem to be the correct way to respond to Probes returning results to the ECC queue.

I thought that reaching into the ECC queue directly was going to be considered a kludgy solution, rather than utilizing the prescribed, pre-built probe/sensor mechanism.   (This understanding was reinforced by the fact that the REST WF activity defines a Sensor script for handling the results.)     But I found the most of the information on using probes/sensors   (old Doug Schulze posts) are filled with broken links and no longer usable - so there was almost no information available.

Your point about using the "Scripting outbound REST" from the wiki is right on target and I really wish that I had RestMessageV2 available.   Unfortunately, we cannot upgrade to Fuji until we get everyone here migrated off of IE8, so I'm stuck with the old RestMessage, which returns a null result when the script runs.

I wound up just using the Sensor script in the REST message WF activity... with one small change.   I had to clone the activity and point it to use a customized version of WebServiceActivityHandler which does an eval on the contents of the variables

getMessageParameters: function() {

               // Process the variables string, and add them to the web service message for substitution

               var messageParams = {};

               if (!gs.nil(this.variables)) {

                       eval(this.variables);

   this.variables = script_result;

                       var params = this._processVars();

                       for (var name in params) {

                               messageParams[name] = params[name];

                       }

               }

               return messageParams;

       },

This way you can define dynamic values in the variables field like this:

var script_result = "application="+workflow.scratchpad.application + ",";

script_result += "attributeName="+workflow.scratchpad.attributeName+ ",";

script_result += "attributeValue="+workflow.scratchpad.attributeValue+ ",";

script_result += "identityName="+workflow.scratchpad.identityName+ ",";

script_result += "operation="+workflow.scratchpad.operation;

Credit for this solution goes toMatthew Dumont

I would still like to know if there is an OOTB to define a probe that would ship back the REST response onto the scratchpad of the WF where the call originated... but I think that I'll just wait for RestMessageV2 and call it good.    

[kumaran]

Did you able to fix the error 'No Sensors defined'.

I am also having the same issue.

[Slava Savitsky]

Does this blog post help?

Getting rid of No Sensors Defined error when sending SOAP messages in a workflow