Future of ServiceNow UI: Seismic and the Now Design System

[tltoulson]

For additional information and the source code for the component in the video, visit the associated CodeCreative blog article.

Transcript:

Welcome to CodeCreative I'm Travis Toulson.

In this video I am breaking down some of the new seismic framework and the new UX design system. This framework currently powers the Agent Workspace, Workspace UI and also appears to be the heir-apparent to Service Portal. Keep in mind though this framework isn't yet documented or even exposed for general use yet. Nothing I'm showing in this video should be taken as production-ready or best practice.

But for those who want to gaze into what the future may hold you've come to the right place.

Now my objective in this first exercise was simple: render something, anything in the new framework so I started off with a create-react-app and added a behavior of loading a simple list of incidents and with some help from Nathan Firth, Andrew Pishchulin, Jace Benson, and some of the other dev MVPs I was able to make the necessary changes to get this into the new UX system. So let's take a look at how that was accomplished.

My first step was to elevate my roles. This was going to allow me to create some ACLs that were necessary to override some of the base maintenance roles on a couple of the tables.

Next let's go ahead and create a scoped application. And this is more just a personal preference on my part I like to encapsulate everything within a scoped application. That allows me to easily delete my changes when I'm done and I really like some of the advantages that scoped apps bring.

So I'm just gonna go ahead and give it a name here. Create the app. And I'm gonna go ahead and continue in studio to skip over some of the data entry we won't be needing any custom tables or custom roles so we can just bypass that step.

Now we can start diving into the data model. So you can see down the side here I've got a few of the tables already laid out. The first one we've got is the Page Registry. Now, for this one here I do have to modify some security rules. I don't have access to the new button by default so we're just gonna go ahead and create some access controls.

First one we're gonna do is a create. And I'll go ahead and set the table and then grant that role to admin. Then I will save this.

And next I'm going to insert a new one for the write operation. And we'll do insert with roles so it captures the admin role for this one as well.

And now we're ready to create our UX Page Registry record. Now that is on the sys_ux_page_registry table and this record allows us to expose a URL in ServiceNow. So this is the entry point for the custom UI.

So I'm just going to go ahead and give it a title for now. I'll specify the UI builder page and then we'll give it a UX playground URL path.

Next is the UX page record. Now we don't want to leave the UI builder page. That one's an out-of-box one for the new UI builder feature. We want to create our own page, but of course once again, this is locked behind the maintenance role. So I'm gonna go ahead and override some of these ACLs. And I'd like to point out that there is another way to accomplish this. We could just create a new Workspace app and that would generate the UX page and UX page registry on its own. But I wanted to bypass the Workspaces and go straight to the UX framework that underpins it.

Now I'll go ahead and save this one and once again I got a set a second one to allow me to write to this table. So I'll insert with roles and continue.

Alright, now we're all set to create our page record. The UX page record is roughly equivalent to an HTML page. We're still dealing with single page applications, similar to service portal. And so this UX page exposes a root element that defines the actual top-level element of the HTML page. We're gonna leave the root element field on the UX playground page empty for now.

Instead we're gonna skip down to the source code. The source codes are where we actually store all of these scripts. So this is somewhat equivalent to an angularjs directive or something along those lines. This is where we actually put our code.

Now I've already prepared a react component so I'm just gonna copy and paste that into here. I will be sharing my component source code on the CodeCreative blog but we won't be diving too deep into it today. I do however want to call attention to lines 194 and 195 (Edit: should have been 193 and 194). You'll see that I'm rendering the component to a specific tag name, in this case, UX playground root. This becomes important in a moment when we create the UX element. The other thing I want to highlight is the Tectonic React dependencies. I put a wrapping function around my compiled component so I could inject the react library ServiceNow already provided through Tectonic, which I assume is a part of the Seismic framework. As far as I can tell Seismic supports multiple renderers which means they [ServiceNow] can adapt the technology under the hood while still exposing the ServiceNow component interfaces through web components. And that should help future-proof our work on top of the platform. It's kind of like GlideRecord of the UI which is absolutely amazing from my standpoint.

Continuing on, our React component needs an HTML element to render to and that's where the UX Component Definition comes into play. By using the same tag name in the tag field as we did in the UX Source Code's React Dom render call, we ensure our component code has an actual HTML element to render into.

Additionally the UX component definition exposes a number of other properties and even some related lists that resemble Service Portal Widget like behaviors. And just like in service portal we have to add those widgets to a page which in Service Portal world is a Widget Instance. In the new UX framework however that role appears to be served by the UX page element. One significant difference between a UX page element and a Widget Instance though is that the UX page element appears to be able to be added to other UX page elements not just to a page. So the nesting of UX page elements is explicitly defined in the metadata as opposed to being hidden in the code like it is with Widget Instances.

And now we're in the homestretch. The last thing that we have to do here is to go back to our UX page and update the root element to the element that we just created. And then finally we need to head on over to our UX page registry and update from the UI builder page that we originally specified and instead set the page that we created custom for my component.

I do have one additional step and that is to go to the DB image table and upload the primary image from the create react app. That image is the little spiraling react symbol that you see and I do need to make sure to put that in the database as unlike the create-react-app we don't have direct access to a file system.

And with that last step completed we're now ready to jump over and view the URL that we exposed through the UX Page Registry.

And there we have it. Our component is rendered in the new UX framework. If I click on load incidents, the incidents panel comes up and I can scroll back to the bottom and click back to home.

Now I'm gonna put our sweet animation on hold for a minute because I want to call attention to two specific things. First of all, the load incidents is in fact loading live data from the ServiceNow instance. It's using a call to fetch in order to hit the ServiceNow REST API and pull the incidents in that way. And it does include the user token in order to authenticate on the API.

The other thing that I want to bring attention to is the URL. You'll notice that it follows a very specific structure and it's modeled similarly to the Workspaces URL. It starts with the application scope which in ServiceNow's case would just be "now" slash. For us, however, it's "x", slash instead of underscore, "270372". Or, for GlideFast, for example it would be "x", slash, "gfnll". And the final part is the URL we specified in the UX page registry record.

And with success at hand let's go ahead and do a quick recap. Starting with the UX page registry, that record routes a URL to a specific UX page. And that UX page in turn defines a root element. The root element can contain child elements and it also encapsulates a component. And that component exposes attributes and specifies an HTML tag that the component will render to. Finally we have the source code which contains the actual source code of our component that we're rendering.

For those looking for more information, be sure to check out Andrew Pishchulin's blog. He's got a great image on there and has been a pioneer for modern web development on ServiceNow. And of course, ever ahead of the curve, Jace Benson back in October was predicting the end of Service Portal and replacement with a new framework. He also provided links for us to the Knowledge 19 session where ServiceNow discussed the new framework and also the original presentation back during Knowledge 18 where they were discussing Agent Workspace and covering some of the very beginnings of Seismic.

If you do go back and watch the Knowledge 19 session in particular you will notice that there's a big difference between the code that they present in their VS Code editor versus what it ends up in the compiled code in the UX source codes so there is definitely some sort of build tool that sits in between and I for one can't wait for us to get our hands on it.

In the meantime we'll just have to sit back relax and ponder the great questions like what is Nathan Firth going to do with serviceportal.io.

[SaschaWildgrube]

In case you want to build pixel-perfect, state-of-the-art interactive user interfaces, you may also consider to use React.

The Reactor app enables you to build and deliver React applications directly from a ServiceNow instance. No need for an external development environment or pre-compilation. You can ship apps or individual components as part of your scoped apps. It also supports JSX.

Check this out:

https://www.wildgrube.com/servicenow-reactor