Once you are familiar with the basics of ServiceNow table maps, including the difference between inbound and outbound table maps, how to create a table map, and how to add a table map to dynamic/bulk shares, there are optional features you can configure based on your needs.
Existing table maps, as well as transform maps and all other related mappings, can be duplicated or copied. If you plan to modify any of the Common Table Maps, e.g. Incident to Common Incident, we recommend that you modify a new copied table map.
Here's how:
By default, data replicated from existing tables will automatically create the same schema at the replicated database. The targeted database schema of replication needs to be flexible and customized in certain situations, such as:
Customizing your target database schema is done by using table maps in your dynamic share or bulk share.
Here's how:
Prerequisites:
Instructions:
To share the table map output, you need to crate a dynamic share or bulk share and select the table map from step 1 in the table map field. The generated payload can be subscribed by an agent and the scheme created dynamically.
In this example, the common incident table map will result in the following table schema, if consumed by a database agent for MySQL.
mysql> describe common_incident; +---------------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------------------+--------------+------+-----+---------+-------+ | state | mediumtext | YES | | NULL | | | short_description | varchar(160) | YES | | NULL | | | description | mediumtext | YES | | NULL | | | priority | mediumtext | YES | | NULL | | | attachments | mediumtext | YES | | NULL | | | category | mediumtext | YES | | NULL | | | correlation_id | varchar(100) | YES | | NULL | | | number | varchar(40) | YES | | NULL | | | correlation_display | varchar(100) | YES | | NULL | | | caller_id | mediumtext | YES | | NULL | | | caller_email | varchar(100) | YES | | NULL | | | caller_full_name | mediumtext | YES | | NULL | | | comments | mediumtext | YES | | NULL | | | sys_id | varchar(224) | NO | PRI | | | | work_notes | mediumtext | YES | | NULL | | +---------------------+--------------+------+-----+---------+-------+ 15 rows in set (0.00 sec) |
Even though we specified the number field as the required Sys ID (GUID) field in the table map, the number field does not become the GUID. Instead, the sys_id field is created as GUID (PRI key) and contains number values to be used for lookup during updates/deletes. This is consistent with replicating database views. |
Table maps can be configured to use scripts to serialize the record yourself. Within the script, you can set the variable answer to be the value you want the record to be serialized and returned as.
This is an advance configuration. Contact Perspectium Support for more information.
The following variables are available to use:
Variable | Description |
---|---|
current | This represents the record that is being shared |
gr_tablemap | This represents the outbound table map itself. For example if you want to access the table map's name, you can use gr_tablemap.u_name |
Instructions:
|
ServiceNow table maps abide by the share only updated fields property that is set in the dynamic share record. However, if you want to override this setting, you can do so in the table field map record. This can be useful if you have a field that is designated as the record's unique ID field (such as the sys_id field) that you always want to share out, regardless of whether it's updated or not.
Prerequisites:
Instructions:
ServiceNow table maps will often generate common documents with empty elements, depending on the script that is used or the source field being mapped. This may not be the desired result and hiding these empty elements may be more favorable. This can be done using the hide empty fields feature that is built into table maps.
Prerequisites:
Instructions:
This feature allows you to map fields in the outbound record based on values from the ServiceNow record to be shared.
Prerequisites:
Instructions:
Using scripts, you an enhance or create new columns of data in your table map's field mapping. Here's how:
Prerequisites:
Instructions:
There are various ways you can use scripting in your field mappings. Here are some examples (click to reveal):
To set an overall value for your field mapping, use the following:
|
To script the transformation of an entire record to a new format (ex: convert to a custom JSON format), use the The following example builds a JSON string from the value of correlation_id and short_description in the current record:
|
To ignore mapping fields for cases such as specified conditions not being met, use the script:
In the following example, the mapping field will be ignored if the the work_notes field is empty:
|
This feature allows you to share data only when certain conditions are met. You can also set up filter conditions for dynamic shares and bulk shares. Table map filter conditions can be created per source field either with the ServiceNow condition builder or programatically. For more information about creating filter conditions in ServiceNow, see condition builder.
Here's how to create filter conditions for a ServiceNow table map:
Embedded records are fields in the table map that cannot be mapped by singular values. Instead, they are entirely different records included (i.e. embedded) inside the table map to be created on the subscribing system.
To include embedded records for a ServiceNow table map, do the following:
Update the Source Field to the following available:
Target Field | Source Field | Common Document |
---|---|---|
approvers | ${TM:psp_approver;sysapproval=$[GR:sys_id]} ${TM:psp_approver;document_id=$[GR:sys_id]} | Common Change Common Request Common Request Item Common Knowledge |
attachments | ${TM:psp_attachment;table_sys_id=$[GR:sys_id]} ${TM:psp_attachment;table_sys_id=$[GR:sys_id];msp_client_application_sent;skip_insert} ${TM:psp_attachment;table_sys_id=$[GR:sys_id];msp_client_application_sent;psp_action=create} | Common Incident Common Change Common Problem Common Request Common Request Item Common Task |
affected_cis | ${TM:psp_affected_ci;task=$[GR:sys_id]} | Common Incident Common Change |
affected_products | ${TM:psp_affected_product;kb_knowledge=$[GR:sys_id]} | Common Knowledge |
catalog_tasks | ${TM:psp_catalog_task;request_item=$[GR:sys_id]} | Common Request Item |
change_tasks | ${TM:psp_change_task;change_request=$[GR:sys_id]} | Common Change |
delegates | ${TM:psp_delegate;user=$[GR:sys_id]} | Common User |
groups | ${TM:psp_group;user=$[GR:sys_id]} | Common User |
group_approvals | ${TM:psp_group_approval;parent=$[GR:sys_id]} | Common Request Common Request Item |
impacted_services | ${TM:psp_impacted_service;task=$[GR:sys_id]} | Common Change |
incidents | ${TM:psp_incident;problem_id=$[GR:sys_id]} | Common Problem |
incidents_caused | ${TM:psp_incident;caused_by=$[GR:sys_id]} | Common Change |
incidents_fixed | ${TM:psp_incident;rfc=$[GR:sys_id]} | Common Change |
knowledge_feedbacks | ${TM:psp_knowledge_feedback;article=$[GR:sys_id]} | Common Knowledge |
manage_subscriptions | ${TM:psp_manage_subscription;user=$[GR:sys_id]} | Common User |
problems | ${TM:psp_problem;rfc=$[GR:sys_id]} | Common Change |
problem_tasks | ${TM:psp_problem_task;problem=$[GR:sys_id]} | Common Problem |
recurring_prices | ${TM:psp_recurring_price;request=$[GR:sys_id]} | Common Request |
requested_items | ${TM:psp_requested_item;request=$[GR:sys_id]} | Common Request |
roles_list | ${TM:psp_role;user=$[GR:sys_id]} | Common User |
variables | ${TM:psp_requested_item_variables;request_item=$[GR:sys_id]} | Common Request Item |
NOTE: You must have the referenced table map in your instance. For example, for attachments, you need to have the psp_attachment table map installed in your instance. See Common Documents for more information.
For other ways to utilize scripting in your field mappings, contact Perspectium Support.