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

Tanushree Maiti · 3 weeks ago

Hi @Fernnn

As per ServiceNow (Refer: Processors )

Key Reasons to Avoid Deprecated Features:

No Further Updates or Fixes: Once a feature is deprecated, it will not receive enhancements, security patches, or bug fixes, leaving your instance vulnerable or out of date.
Support Ends: ServiceNow Technical Support will no longer assist with issues related to these features.
Upgrades and Risks: While deprecated features usually remain active in your instance after an upgrade, they are considered custom code and can break or cause issues with newer releases.
Performance Issues: Old technologies may not be optimized for modern performance standards, potentially causing slowness.

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin:

Fernnn · 3 weeks ago

This is exactly the sort of vague and unhelpful answer I called out in my post. Most of these points don't even apply to processors specifically, given that they are an essential part of the platform.

Tanushree Maiti · 3 weeks ago

Hi @Fernnn

If we continue to rely on a deprecated feature and choose not to adopt the modern capabilities provided by ServiceNow, it may become difficult to fully appreciate or accept the rationale behind the proposed changes. In that case, even well-explained and logical points might seem unclear or less convincing.

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin:

Fernnn · 3 weeks ago

This is still not an answer to the question that was asked and comes across like you don't know what a processor is.