This blog is not the definitive guide to application development on the ServiceNow platform. Rather is is one developers' notes, thoughts, enlightenments and mis-queues as he moves from .NET and Force.com development to service based application development on our platform.

Before joining ServiceNow I wrote Cobol on the mainframe, Visual Basic apps for client server, and cloud based apps using Force.com. In the course of this evolution I spent 2 years working on a software development application called Telon. I bring this up because there are similarities from this Rapid Application Development product and custom application development on ServiceNow but for now I'll start from the beginning.

Like almost every developer I know, all I wanted was an "instance" of the platform ... then get out of my way while I play around and find the cool stuff. My problem was I expected the interface to be much more like Force.com than it actually is. (Note: My next post will show my Force/SN Apples-2-Apples matrix). Force.com makes it pretty easy to know where things go. Your HTML is built via a meta-data front end called VisualForce. Your database queries are written against Force.com "Objects" using SOQL (Salesforce Object Query Language). The syntax is similar to native SQL, however it is NOT SQL. Most developers speak SQL as a second language but you soon find out that aggregates and other functions are not supported. Finally, server logic is written in Apex. Apex is very similar to Java. If you know Java, you know Apex.

The training sections in the developer community are the best way to get a feel for ServiceNow development. This is not the only form of development however. Catalog Item Designer (no-code), Service Creator (low-code) and Service Portal (pro-code) are other flavors of application development on the platform. We will cover each in this series, but today's entry is focused on scoped service management applications via SN Studio.

I was making my way through the training when I followed a link for UI Pages that took me to another reference for Jelly and Glide. Both were new to me so I followed the links. I ended up spending two days in Jelly - Jelly : Executable XML and Jelly Tags - ServiceNow Wiki. Do NOT do this. When I came up for air I realized that this is the equivalent of Force.com's VisualForce for custom page development. I then made a note of it then put it on hold until I had a reason to return.

Back in the training environment I walked through every section. Each module made sense but there was a new "language" emerging. Things like Business Rules, Script Actions, and Transform Maps were new names for processes I was familiar with from other frameworks so I started keeping a spreadsheet to correlate these new names with my old names. Then I hit the UI's !! Catalog UI Policies, UI Actions, UI Context Menu's, UI Macros, UI Pages, UI Policies, and UI Scripts. Now I'm not the brightest bulb but I have been around for a while so naturally I figured if a code block starts with UI it must mean "User Interface" and it would execute on the client. Well as it turns out this is not always the case. (see below).

Components of a ServiceNow application - UI x

Description	Client/Server	Code Types
UI Page [sys_ui_page]	Custom Jelly-based HTML pages available to the system	Server	Pro Code
UI Macro [sys_ui_macro]	Custom Jelly-based user interface elements available for lists, forms, and pages	Server	Library - Pro Code
UI Action [sys_ui_action]	Controls to create a custom button or link on lists or forms to perform a particular action	Client and Server	Low-code
UI Policy [sys_ui_policy]	Controls to specify what fields are visible and editable on a form based on its current content	Client	No-code
UI Formatter [sys_ui_formatter]	Controls to specify what custom user interface to display on a particular form	Client	No-code
UI Script [sys_ui_script] *	UI scripts provide a way to package client-side JavaScript into a reusable form, similar to how script includes store server-side JavaScript.	Client	Library - Pro Code
Catalog UI Policy [catalog_ui_policy]	Fields to display when viewing Catalog Tasks, Catalog Items, and Requested Item Tasks	Client

I didn't know it then, but as I explored each logic block it hit me. Developing apps on the ServiceNow platform via Studio is very similar to Telon! Telon helped mainframe programmers build CICS/DB2 applications quickly by standardizing a base code flow and opening up "Code Blocks" where custom code could be inserted. Standard edits like 'numeric', 'date', etc were automatically generated. Only the real logic of the program needed to be added. A studio built custom application works the same way! Each program block in ServiceNow has a function. If the logic of your application calls for it's type .. Then you know where to put the code! It's efficient and the reason why applications on SN can be built so quickly. Another component that immediately stood out is the power of the Workflow engine. The ability to trade custom code for a workflow is a game changer. Once you build one or two apps its like a light bulb goes off.

Force.com has a different philosophy. VisualForce, SOQL, and Apex are blank pallets for a developer to create an application. This is both good and bad. Good because it's easy to relate after using other IDE's, but bad because members of a team could write their portion of an application in completely different manners. As time goes on, another person or persons will be responsible for maintaining and updating the application. They will have to understand each programmers style before making any changes. With ServiceNow, once you get a hang of your naming conventions, you know right were to look!

For pure business value, application time to market and maintainability the ServiceNow approach is a proven winner.

** Dave Knight is the author of these Platform Block diagrams. They helped me and I hope they will help you as well.