What's wrong with processors?

Fernnn · 3 weeks ago

ServiceNow doesn't want people making new sys_processor items. I understand that they can be problematic, but so can the proposed replacement (scripted REST APIs, which are just an extension of processors BTW). They provide a simple and efficient way to do things that REST APIs do not (e.g. a vanity URL that takes you to a page who's URL may change over time, or based on server processing triggered by parameters in the URL). It may be possible to do that with a scripted REST API, but even if so, it just seems kinda dumb and clunky.

ServiceNow is still creating processors to this day.

I see a lot of vague statements telling us not to use them, but I have yet to dig up a detailed explanation as to why.

This is not a "how" question. It's a "why" question.

Fernnn · 3 weeks ago

Looks like this is part of the answer:
Type can be Java, which is most likely only intended to support ServiceNow devs.

List of available input parameters.

Specify parameter values in the URL as <parameter name>=<parameter value>.

Note:

Parameter names must be processor-specific. Do not choose common parameter names that another processor might use. If you use a common parameter name, such as id, sys_id or table in a processor, it can break other functionality, since the processor wins when that parameter exists in a URL. For example, a processor with an id parameter, regardless of the Path value in the same record, breaks the Service Portal, which depends on that parameter for page identification.

From what I can see so far, it seems that this is a feature that's too low-level for ServiceNow to trust their outside users with. It also interacts with parts of the platform that most users have little-to-no control over. It's probably only accessible without maint because it used to publicly serve the purpose that scripted REST APIs do now (and a few other edge cases) so rugpulling it would cause problems for some clients and make people angry.
Hopefully someone else knows more and is willing to explain.

View solution in original post

Fernnn · 3 weeks ago

Looks like this is part of the answer:
Type can be Java, which is most likely only intended to support ServiceNow devs.

List of available input parameters.

Specify parameter values in the URL as <parameter name>=<parameter value>.

Note:

Parameter names must be processor-specific. Do not choose common parameter names that another processor might use. If you use a common parameter name, such as id, sys_id or table in a processor, it can break other functionality, since the processor wins when that parameter exists in a URL. For example, a processor with an id parameter, regardless of the Path value in the same record, breaks the Service Portal, which depends on that parameter for page identification.

From what I can see so far, it seems that this is a feature that's too low-level for ServiceNow to trust their outside users with. It also interacts with parts of the platform that most users have little-to-no control over. It's probably only accessible without maint because it used to publicly serve the purpose that scripted REST APIs do now (and a few other edge cases) so rugpulling it would cause problems for some clients and make people angry.
Hopefully someone else knows more and is willing to explain.