Asynchronous REST message via MID server on ECC queue - How to set setEccCorrelator()

[tantony]

I have a script which uses REST message  to update data on a remote server using executeAsync() via MID server.. My script is not waiting for response and is working fine .But I am worried about 1000's of "input" entries in ECC queue sitting as 'ready' ,that it can lead to performance issues. I am assuming setting EccCorrelator as in below KB article is a solution, I could be wrong

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0727028 gives an example to:

sm.setEccParameter("skip_sensor","true"); // prevent Discovery sensors running for the ECC input
sm.setEccCorrelator("rest.yahoo"); // unique identifier for this message, used by the custom sensor business rule for matching the ecc_queue input
sm.executeAsync(); // send the ECC queue output and end this script. The Sensor business rule will carry on once the response arrives back from the MID Server

https://docs.servicenow.com/bundle/paris-application-development/page/app-store/dev_portal/API_reference/RESTMessageV2/concept/c_RESTMessageV2API.html

Above link also talk about a "unique identifier" . Can anyone help me how to configure that "unique identifier" and custom sensor business rule? Or even a link to a example or even documentation how to create that

I want the "input" entries in ECC queue to be moved to "processed" instead of sitting there as "ready".

[Kieran Anson]

Hey,

Setting eccCorrelator is indeed a solution. You can then setup an after / async business rule on ecc_queue to look for your eccCorrelator (which will populate the topic field). If you're not needing to do any processing to the response you can simple add the following to the script:

current.state = "processed";
current.processed = gs.nowDateTime();

Example of condition:

current.queue == "input" && current.state == "ready" && current.topic == "rest.yahoo"

Make sure your topic is unique to avoid conflicts going forward. I usually go for a naming convention which the company prefix at the start to ensure there isn't a chance of your business rule processing something it shouldn't!

[tantony]

Kieran,

Thanks for the quick reply. You have got me almost there. I have a couple of questions.

-The BR is to run on 'insert'. Am I correct?

- You said an "after/async" BR. In that case I will have to use current.update() which I would like to avoid . Since the conditions are there do you see any problems in making it a "before" script?

Looking at the ECC payload I found that the setEccCorrelator() sets the "agent_correlator" and not the "topic" in my case. The queue entry already had a topic-"RESTProbe".It did not overwrite it.

[Kieran Anson · Accepted solution]

Ah yes apologies setEccCorrelator is for the MID server. For your need I'd set a custom topic and use a business rule. 

Regarding the business rule run type, you can do any, I guess as you're not doing anything with your data on before insert will be fine.

[tantony]

I ended up with this:

My script which updates records in a remote server, via MID server:
----------------------------------------------------------------------------------------
var r = new sn_ws.RESTMessageV2('My Outbound REST message', 'put');
r.setEccParameter("skip_sensor","true");
r.setEccCorrelator("my.unique.identifier");
r.executeAsync();//The response do not need any processing

My custom business rule on ecc_queue table to change "input" entries with "ready" state to "processed":
---------------------------------------------------------------------------------

when to run Business rule:

before
on insert

Business rule script condition:
------------------------------------------
current.agent_correlator == "my.unique.identifier" && current.topic == "RESTProbe" && current.queue == "input" && current.state == "ready"

Business rule script:
---------------------------

(function executeRule(current, previous /*null when async*/ ) {

//Check if the ecc_queue entry is in error status by parsing Ecc payload

var xmlPayload = new GlideXMLDocument();
xmlPayload.parse(current.payload);
var error = xmlPayload.selectSingleNode('//results/@error');
if (JSUtil.notNil(error)) {

      current.state = "error";
} else {

      current.state = "processed";
      current.processed = gs.nowDateTime();

}

})(current, previous);

If you are wondering how ECC queue is cleared, it is by Table rotation. You don't have to worry about entries growing exponentially and sitting in ECC queue for ever

Some related docs:
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0855595

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0727028
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0718589
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0855595