上QQ阅读APP看书，第一时间看更新

Creating the table

Now that we've created an update set and marked it as current, we're ready to begin development. As is the case with many (though not all!) ServiceNow applications, we begin our application by creating a new table to house our data. In this case, we're creating a virtual war room application, so we'll create a table to hold virtual war room tickets.

First, in the application navigator, navigate to System Definition | Tables, and you'll be presented with the list view for the sys_db_object table; or you might say, the Tables table.

Click on the blue New button at the top-left of this list to get started. On the New record form, enter Virtual War Room for the label, and press Tab. Once you've done that, the Name field should auto-populate with the value u_virtual_war_room. The u_ indicates that this is a custom, user-defined table, as opposed to a table that's built-in with ServiceNow.

It is generally good practice to give your tables singular labels (Virtual War Room as opposed to Virtual War Rooms) and names (u_virtual_war_room, as opposed to u_virtual_war_rooms). Most built-in tables in ServiceNow adhere to this standard as well, except for the Properties (sys_properties) table. ServiceNow will try to figure out the best way to pluralize the label of a record type (though you can custom-define the plural form if you prefer), for use in places like the label at the top-left of a list. The singular form would then be used as the label on a form displaying one record.

Next, in the Extends table field, we have to determine whether we want our table to extend another table (and thus, inherit the existing fields, labels, and certain business logic). We'll go over what this means in more detail, in a later chapter. For now, since we are going to want access to some of the task-related goodies built in to ServiceNow, let's set our virtual war room table to extend the task table by entering Task into the Extends table field.

There are multiple tables with a label of Task, but only one with a name of task. A similar table containing catalog tasks for example, also called task-is named sc_task. More info on the Task table can be found in Chapter 5, Tasks and Workflows.

Since we want to create a new application menu item and module for our application, we'll leave Create module and Create mobile module checked. We'll also leave the Add module to menu option set to -- Create new --, and underneath that field, we'll leave the New menu name field set to the same as our table label: Virtual War Room.

You'll notice that the Columns tab or form section contains a list of Table Columns, which is currently empty. We'll leave this section alone for now, as many columns are going to be automatically created for our table once we save the new table record, since we're extending another table.

Moving to the Controls form tab/section, we've got several more options:

Extensible: This indicates that other tables are able to extend this table. This might be useful if we were creating a parent table that would have child-tables that needed to share the same custom fields we created, but for our purposes we're going to leave this box un-checked.
Live feed: This checkbox determines whether live feed is enabled on this table. The live feed is part of the newer social IT applications, and serves as a place where users can post and share certain content. If live feed is enabled, you can have a sort of twitter-stream like view of tickets you're interested in, and activity happening on them. Let's go ahead and check this box.
Auto-number: This allows you to define a prefix (incidents, for example, use INC by default), and the system will automatically number each record in your table, beginning at the number you specify. Let's check the auto-number box, set the prefix to WAR, and leave the Number and Number of digits fields default.
Create access controls: This allows you to create a new role (see Chapter 7, User Administration and Security, for info on roles and security) to control access to your application. It might make sense down the line, for us to have a separate role that we can grant only to certain major-incident managing groups or users, so go ahead and leave that box checked. The User role field beneath it allows us to select an existing role, or create a new one. The field background color should be green, which means the value currently in it is new, and will create a new role when saved.

Application Access: This tab/section allows us to control application-scope specific settings, but we're not concerned about that right now so go ahead and leave everything there default.

Whether the Columns, Controls, and Application Access sections display as tabs or stacked form sections, depends on whether you have the Tabbed forms toggle switched on, in the Forms tab of the System Settings cog menu. Just a reminder, this setting is a preference, meaning that it is user-specific, and won't affect other users' experience.

Finally, right-click in the header and click Save. We could also click the Submit button, but that would redirect us back to the previous page we were on, and we're not ready for that just yet.

After saving the new table record, if you go back into the Columns section, you'll notice that somewhere in the ballpark of 60-70 new columns have been created automatically! A few of these are default fields created on every table (fields like Created, Updated, Sys ID, and a few others), but the vast majority of the fields you'll see, came from the Task table:

By default, you'll see that the Table columns list inside the Columns section of the form has several fields shown: Column label, Type, Reference, Max Length, Default value, and Display. Since these are rather universal, let's go through each column and make sure we know what it means:

Column label: This is the friendly name for the column (or, on the form, the field label).
Type: This is the type of field. This dictates the default max length (which you can change), what field properties and attributes are available for this field, and what sort of values will be accepted. Changing a field type after it's been created is very difficult, and not recommended after users are actively using your application, as all data from that field will be lost, in all existing records.
Reference: This field is only relevant to certain types of columns which reference records on other tables. We'll go into reference field types in Chapter 4, Understanding Data and Relationships.
Max Length: You can probably guess at what this field governs. That's right, it's the maximum length (in characters) that the field will accept. The default value for this is 40 for most column types, 32 for reference fields, 4,000 for journal fields, and so on. You can specify whatever length you like here.
Default value: Also fairly self-explanatory, this is the default value for the column, to be used before the user has selected one.
Display: Each table can have only one display value. The display value is the single column which is displayed to represent a record as a whole. On the Incident table for example, the display value is the Number column, but some users change it to Short description. On the Users table, you might want User ID, or Name to be the display value.