Deleting the homepage will permanently delete the homepage from the instance. You will have to re-install the update set to re-install the homepage.
The properties page configures user credentials used to connect to the Perspectium server. There are also properties for triggering debug logging, outbound message size, and pass-phrases used for encrypting and decrypting the outbound and inbound messages.
These modules will start and stop all scheduled jobs with a name that begins with
Perspectium. Clicking on the Status module will display the Component Status record for
Perspectium's schedule job running status. Starting and Stopping will also re-sync the Event Subscription script actions.
You can read more about what these do here.
The Test Connection link will attempt to retrieve ServiceNow
statsx.do pages and post to the configured
Perspectium server. The status of the test will be displayed on the browser frame.
Perspectium logs are filtered with the source value of “Perspectium”. Clicking this module will display a list of log records of this source value. To generate more log, you may enable the
Debug flag property on the
A list of all of the Perspectium application script includes.
There are lot of components to the Perspectium Table Maps within ServiceNow. For the full article you can click here.
This feature is used to map and/or transform the outbound ServiceNow field data for the record being replicated. If the field names of the record being replicated outbound from ServiceNow need to be modified, or if the value of one or more fields needs to be transformed, you should create and configure an Outbound Table Map. If you are familiar with Transform Maps for Import Sets, its is conceptually the Outbound version of a Transform Map.
Once the Outbound Table Map is configured, it can be assigned to a Dynamic Share or Bulk Share by selecting it in the Table Map field on corresponding forms.
These are often used to grant a greater control of the Outbound Replication. They are utilized and packaged per integration (Jira, Salesforce, etc).
While Outbound Table Maps are more built to be an Outbound Transform Map the Inbound Table Maps more function as a Subscribe definition. They will direct the traffic to a Import Set Table where then a ServiceNow Transform Map will do the processing. We will traditionally package the Table Maps and Transform Maps for the advanced integrations.
These configurations are used to map inbound replication messages to a ServiceNow table based on the Topic and Type specified in the message. For example: a record coming in with the “topic=siam” and the “type=common_incident” will be mapped to the “u_psp_common_incident” Import Set Table. The corresponding Transform Map will then process that appropriately.
Clicking on this module will bring you to the Observer user interface hosted by
Perspectium. This rich interface allows for monitoring and trending of ServiceNow performance metrics. Here is an example of the UI.
Clicking on the “Health Check” module will analyze your instance and give you a current health check report on the instance. This information can provide you an overview of key ServiceNow metrics that can you help understand where your instance may be performing slow or having issues.
Information displayed in this health check report include:
*Requires the Stats Tools Diagnostics Plugin be installed.
Alerts triggered by Observer monitoring of ServiceNow performance flow back into the instance in this module.
Alerts are processed by the
Alert Import Set Table and inserted into the
Alerts module. The
Alert Import Set has pre-defined mapping to import these values from the Inbound Message table into the
Situation can be created to collect similar and related alerts into a work unit that can be assigned. For example, the following
Situation aggregates the similar alerts that can be assigned to an individual, put through a simple workflow or brought into your current Incident or Change management workflows.
Situation Templates define automatic Situation detection and creation rules. Coming soon
These modules provide a quick way to access the run-time code related to Observer.
These modules allow the customer to define subscription to ServiceNow internal events (from Event Log) that result in the creation of Observer flags/labels on the Observer Trend Chart.
Example Trend Flags
This is the feature that allows the customer to configure tracing of a particular transaction by URL or User over a period of time. All metric values related to the transaction in the ServiceNow
Transaction Log is captured and sent to Observer. The captured metric appears as separate Trend lines in the chart, making it possible to correlate the transaction's metric with other performance metric already being captured.
As a result, all user transaction timings are tracked over the specified time, including:
To follow a user's transactions, navigate to the Follow Transactions link and click New. Next, select User Type and enter the User's ID and select the amount of time to follow the user. Click Start to start following.
In Observer, you will see a similar Trend chart as follows:
To follow transactions related to a specific URL, navigate to the Follow Transactions link and click New. Next, select URL Type, enter the URL (or a substring of it) that you would like to track and select the amount of time to follow. Click Start to start following.
For example, the following configuration will follow every transaction related to “incident.do” for an hour.
You can follow specific URLs originating from an application module.
To be very specific about a URL you would like to track, modify its module and add a URL parameter that ServiceNow ignores and then track that. For example, editing a List of Records link type to add an argument of “TRACK_OPEN_INCIDENTS” and then subsequently using this value in your follow URL transaction configuration will result in only the Open incidents module being followed over time.
To follow transactions by specifying a condition on the Transactions table, navigate to the Follow Transactions link and click New. Next, select Conditions Type, build the condition as you would like to filter on the Transactions table and select the amount of time to follow. Click Start to start following.
For example, the following configuration will follow all background jobs for 1 week.
Actions are the Observer jobs that collect, monitor and analyze ServiceNow application metrics and attributes. In versions prior to v3.15.0, these jobs were each individual scheduled jobs (found under Observer > Scheduled Jobs), they are now “actions” that are run as part of two scheduled jobs to allow to minimize system usage and to make it easier to turn on/off each job.
Actions can be set to run as follows:
The Observer update set comes with default Observer actions that are set to run when the update set is installed. For any questions on these default actions or creating your own custom actions, please contact email@example.com.
Any actions set to run On Interval can be changed to run less frequently if you do not want to capture this info as often or if you notice any performance impact. You can also change them to run Daily to collect the data daily instead of On Interval (default every minute).
In v3.24.0 the External User Accounts and Local User Accounts actions are defaulted to inactive due to performance considerations. If you would like to collect details related to External User Accounts or Local User Accounts (i.e. how many of these accounts are logged into the instance), activate these actions and considering change them to run less frequently as mentioned above.
Metrics and attributes collected by Observer actions are placed into Observer's own outbound queue that can be viewed here. A separate Observer-specific scheduled job runs in the background at a default interval of every 5 minutes to post these messages to Perspectium MBS so as to view this data in the Observer UI. Messages will be posted to the Perspectium MBS as specified in the default Control and Configuration > Properties.
After installing the Perspectium Update Set, there will be a section in the Perspectium application for Replicator as described below.
The Properties page for the Replicator application can be found in ServiceNow by navigating to Perspectium > Replicator > Properties.
Notable Replicator properties found on this page include:
|Encryption key for encrypting shared content from replicator (must be at least 24 characters long for AES-128 encryption |
or at least 32 characters long for AES-256 encryption).
|The cow jumped over the moon (AES-128)|
|Decryption key used to decrypt replicated content that is subscribed (must be at least 24 characters long for AES-128 encryption |
or at least 32 characters long for AES-256 encryption).
|The cow jumped over the moon and the sun (AES-256)|
These are configurations for defining which ServiceNow table is to be shared dynamically as records are being created, updated, or deleted. Bulk Share defines one-time sharing of a filtered list of records.
Please refer to the Use Cases for more detailed configuration options accompanied by normal use cases.
This module configures the subscription of data flowing into this instance of ServiceNow. By configuring specific tables and actions like create, update, and delete one can define in detail how data is coming into this instance of ServiceNow.
The Shared/Subscribed Queues along with the credentials and endpoint URL to access them allow
Subscribe entries to specifically target a known message queue on a server. This level of configuration comes in handy when designing for data to flow in a particular direction and target instance or agent.
This module allows for the definition of recurring or scheduled
Bulk Share over time.
These modules link to related run-time components related to Replicator.
Outbound message table contains records that are queued to be sent to the
Perspectium Server. Up to 4000 records can be sent every 30 seconds by default. This value can be changed on the
Inbound message table consists of records intended for the current instance of ServiceNow that were shared by other instances and agents. The data flowing into this table will only be consumed only when they are also configured in the