
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-30-2015 05:08 PM
The ServiceNow documentation for eventQueue has the following parameters...
3.1 eventQueue(String name, Object instance, String parm1, String parm2, String queue)
Queues an event for the event manager.
Parameters:
name - (String) name of the event being queued.
instance - (Object) a GlideRecord object, such as "current".
parm1 - (String) an optional parameter, saved with the instance if specified.
parm2 - (String) a second optional parameter, saved with the instance if specified.
queue - (String) the name of the queue.
Returns:
void
Example:
if (current.operation() != 'insert' && current.comments.changes()) {
gs.eventQueue("incident.commented", current, gs.getUserID(), gs.getUserName());
}
My question is what value should be used for the 4th parameter? The documentation says "name of the queue" but then has an example of gs.getUserName(). That doesn't make sense to me as why is the userName the same name as the queue? Thanks.
Todd
p.s., I've noticed that most of the sample events in SN have an empty "Queue Name."
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-30-2015 08:05 PM
Hi Todd,
gs.eventQueue takes 5 arguments. 4 are described here:
https://wiki.servicenow.com/index.php?title=Events_and_Email_Notification#Building_a_Script
Field | Input Value |
---|---|
Name | The name of the event triggered, set in quotation marks |
Record | The record referenced when the condition in the script evaluates to true. Usually this is expressed as current, meaning the current record the business rule is working on. If the business rule is being triggered as part of a scheduled job, use a GlideRecord argument in its place. |
Parm1 | Passes a string value. Notification events pass the Sys ID of the user with the gs.getUserID() method. Other scripts can reference this string value as parm1 using the format ${event.parm1}. |
Parm2 | Passes a string value. Notification events pass the user name with the gs.getUserName() method. Other scripts can reference this string values as parm2 using the format ${event.parm2}. |
parm1 and parm2 are the 3rd and 4th values, and they are just pieces of information that your event action script might need. Think fo them as context. For instance, you might send:
gs.eventQueue('change.inserted',current,gs.getUserId(), gs.hasRole('itil'));
Now you can tell every time someone with the itil role inserted a change, without doing extra lookups based on the user record.
There is also a fifth value you can pass: queue name. You can set up an event processor that *only* handles events in a given queue. Your instance probably already does this: text indexing events are processed as a separate queue from other events in the sysevent table. The regular event processor handles all events that don't have a specific queue name, and the text index processor handles those events where the queue is 'text_index'.
If you want to collect events, but only process them once an hour, or twice daily, you could put them into a queue with a specific name, and add a scheduled job to process them on your schedule. Or you may want to throw an event every time some action occurs, but you really don't want to do anything with that except for forensic purposes; for example, every time a user views a particular record, but you only care about *todays* events, and only if that record's status changed. OK, that might not be the best example. There are probably lots and lots of other use-cases for this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-30-2015 06:49 PM
I'm fairly sure I've seen that used as a ref to sys_user_group.... it may be a feature developed by the Brits (queue = line..... ex: queue for the loo);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-30-2015 08:05 PM
Hi Todd,
gs.eventQueue takes 5 arguments. 4 are described here:
https://wiki.servicenow.com/index.php?title=Events_and_Email_Notification#Building_a_Script
Field | Input Value |
---|---|
Name | The name of the event triggered, set in quotation marks |
Record | The record referenced when the condition in the script evaluates to true. Usually this is expressed as current, meaning the current record the business rule is working on. If the business rule is being triggered as part of a scheduled job, use a GlideRecord argument in its place. |
Parm1 | Passes a string value. Notification events pass the Sys ID of the user with the gs.getUserID() method. Other scripts can reference this string value as parm1 using the format ${event.parm1}. |
Parm2 | Passes a string value. Notification events pass the user name with the gs.getUserName() method. Other scripts can reference this string values as parm2 using the format ${event.parm2}. |
parm1 and parm2 are the 3rd and 4th values, and they are just pieces of information that your event action script might need. Think fo them as context. For instance, you might send:
gs.eventQueue('change.inserted',current,gs.getUserId(), gs.hasRole('itil'));
Now you can tell every time someone with the itil role inserted a change, without doing extra lookups based on the user record.
There is also a fifth value you can pass: queue name. You can set up an event processor that *only* handles events in a given queue. Your instance probably already does this: text indexing events are processed as a separate queue from other events in the sysevent table. The regular event processor handles all events that don't have a specific queue name, and the text index processor handles those events where the queue is 'text_index'.
If you want to collect events, but only process them once an hour, or twice daily, you could put them into a queue with a specific name, and add a scheduled job to process them on your schedule. Or you may want to throw an event every time some action occurs, but you really don't want to do anything with that except for forensic purposes; for example, every time a user views a particular record, but you only care about *todays* events, and only if that record's status changed. OK, that might not be the best example. There are probably lots and lots of other use-cases for this.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-30-2015 09:17 PM
Great response Cory and reference link. That makes sense to me know. I actually meant to say the "5th" parameter and accidentally said 4th but you knew what I meant anyway. Thanks again.
Todd

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-03-2021 07:04 AM
This is an old post but here is something I found when using custom event queues and how to process them:
Using Custom Queues - Advanced Topic | ServiceNow Developers