The web blog strives to be a comprehensive guide to SCCD, TADDM, SERVICE NOW and MAXIMO tools. This is a personal site maintained solely by me. I intend to update it regularly.For live updates please follow us on.

Service Now Reporting

Service Now Reporting

Service Now reports can be lists, charts, or calendar-based views of data in a particular table. The Service Now system also offers a range of predefined reports that pertain to applications and features like incident management and service catalog requests. If none of the predefined reports meet your needs, you can create your own reports. Use reports on homepages to display key information to different users. You can also publish reports to a URL that can be emailed. 

In Service Now reporting, you can control the following aspects of reports: 
  • Report Visibility
  • Report Types
  • Report Generation
  • Report Output formats
You can generate Service Now reports manually or according to a schedule.

Report Visibility

You can control who sees reports by making them:
  • Globally visible to all users. 
  • Visible only to the report creator. 
  • Visible to one or more specific users. 
  • Visible to one or more specific groups. 
Report visibility controls which users can access individual reports.

ACLs control access to the underlying table data. List reports require the reporting user to satisfy ACLs on the target table to view records in the list. Users without sufficient permissions may see filtered list reports. 

Report Types

You can generate the following types of reports, organized by category:
  • Time Series Chart
  • Line
  • Column (Fuji release)
  • Area (Fuji release)
  • Spline (Fuji release)
Column and Bar charts
  • Bar
  • Pareto
  • Histogram
Pie and Donuts
  • Pie
  • Donut (Fuji Release)
  • Semi-donut (Fuji Release)
  • Speedometer (Fuji Release)
  • Dial (Fuji Release)

Report Generation

You can generate a report manually at any time. These on-demand reports are useful for capturing information at the moment, such as the number of incidents assigned to you right now.

You can also schedule reports to generate on a regular basis.
The charting engine you use depends on the version of the Service Now platform you are running. 

Report Output Formats

You can publish reports in the following output formats. You can schedule all of these reports for regular export. 

Service Now Performance & Tuning

Service Now Performance & Tuning

Performance issues can arise with your Service Now instance in the network Latency, Application Server response, and Browser Rendering.

One of the first things to consider when troubleshooting performance issues is to determine where the issues originated. This can be accomplished by performing basic troubleshooting steps, such as testing the issues on different computers or using different browsers.

Network Performance

One clear indicator of a network issue is if users in one location have very good performance while users in another location have very poor performance. This indicates that the application server is fine. If the browser settings are identical for these users, the only meaningful difference is the network.

Monitor Ping Times
 The coarsest measure of network response time is a ping, which measures the total  time for a packet to travel from the source machine to the target and back again.  Ideally, the response time should be under 100ms in the United States or under  150 ms in Europe or Asia. In practice, though, anything under 250 ms is not a major  component in perceived response time.

Running a Traceroute
If you are observing slow ping times, you can run a traceroute. Traceroutes are great tools for identifying network bottlenecks.
To run a traceroute in Windows, open a command prompt window and enter:
tracert <yourinstancename>

Application Server

Application server performance issues generally manifest themselves in slow response times. Monitoring response times and checking logs can help when identifying performance problems.

Monitor Response Times
 To maintain good performance levels on the application server, regularly monitor  response times throughout your instance, including at the transaction level and on  forms.

Track System Transaction Logs
As you operate Service Now, the instance automatically logs the vital statistics of every transaction it processes. That information is available to users with the admin role.
Navigate to System Logs > Transactions.

Fixing the issue:
Ensure that a cache flush is not being run during business hours. Be aware, however, that when update sets are committed, they automatically trigger cache flushes, which prevent older data from interfering with changes and updates. So do not schedule update sets to be committed during business hours
If there is no identifiable cause, but overall response time is still slow, contact ServiceNow Technical Support to find out if anything is affecting the application server hardware.


Browser performance issues are often related to how the browser handles and renders compressed data. Monitoring how the browser handles caching of data from secured sites can also affect performance.

Compressing Data
 Make sure that your browser always requests for compressed data. Frequently, a  proxy or edge device disables gzip compression. Enabling gzip compression would  speed up the interactions.

Caching items from Secure Websites

If your organization has a policy to never cache items from an https location, every interaction with the ServiceNow server will fetch a large amount of JavaScript and images.
To prevent this performance impact, make sure the Internet Explorer Do not save encrypted pages to disk option is off (the Microsoft default).

Simplified procedure to generate Maximo log

Simplified procedure to generate Maximo log

1. Go to System Configuration > Platform Configuration > Logging.
2. Configure the Root Loggers as:  

Root Loggers:
Logger = sql
Log Level = INFO
Appenders = Console,Rolling

Root Loggers:
Logger = application
Log Level = DEBUG
Appenders = Console,Rolling

3. Select Action > Set Logging Root Folder
    This option allows us to select a folder where the Maximo log will be created.
4. Save.
5. Click OK on “BMXAA5191W - Logging settings have been changed. However, changes will not       take effect until the Apply Settings action is executed.”.
6. Select Action > Apply Settings.
7. Replicate the problem scenario and send the log to IBM Maximo Support.

Maximo MIF Authentication

Maximo MIF Authentication

MIF Authentication
MIF Authentication (for HTTP based integration) follows the authentication model that is set for the Maximo

MIF components (HTTP and non-HTTP) supporting inbound transactions require varying configurations to 
enable authentication.

The Inbound MIF Integration options:
3. Interface Tables
4. XML/Flat file loading (UI and CRON task)
5. HTTP SOAP-based web services
6. HTTP Servlet (XML/HTTP)
7. JMS (Direct)

MIF Configuration points when using Maximo Authentication

HTTP SOAP-based Web Services
Can optionally use the default Login User (use ALLOWDFLTLOGIN in the ejb-jar.xml file)
When not using the default Login User, the request must pass the HTTP Header Property named  MAXAUTH which must contain the user:password that is base64-encoded

HTTP Servlet (XML over HTTP) 
Can optionally use the default Login User (use ALLOWDFLTLOGIN in the ejb-jar.xml file)
When not using the default Login User, the request must pass the HTTP Header Property named  MAXAUTH which must contain the user:password that is base64-encoded

The request must pass the HTTP Header Property named MAXAUTH which must contain the  user:password  that is base64-encoded.  No support for the Default Login User.

The request must pass the HTTP Header Property named MAXAUTH which must contain the  user:password  that is base64-encoded.  No support for the Default Login User.

Flat and XML File Loading
Requires a valid user defined in the system property.  This is not optional and  the setting of the ALLOWDFLTLOGIN in the ejb-jar.xml file has no bearing on this behavior.

Inserting messages into a queue (inbound and outbound)
Requires the assignment of  a user and password to the JNDI name for the queue.
Configure that same user and password on the queue definition in Maximo using the  Add/Modify Queues Action in the External Systems application.  This allows the MIF  components that read and write to the queue to be able to access the queue.
For Continuous Queues that use the Message Driven Beans (MDBs) to consume messages, the  ejb-jar.xml deployment file must be updated with the user name assigned to the queue.
See the section, Configuring J2EE restriction for JMS queues, in the MIF section of the Maximo  Knowledge Center for more details.

Consumption of messages out of an inbound queue (processing into Maximo)
Requires a valid user defined in the system property when no user is attached  to the message.  This is not optional and the setting of the ALLOWDFLTLOGIN in the ejb-jar.xml  file is not applicable.   See section, Other Usage of the default Login, further down in this  document for additional information.

Interface Tables
Does not support or rely on a default user.  Interface Table End Point would require DB  User/Password if DB tables are secured.

Maximo performance Issues and Solution

Maximo performance Issues and Solution

User not able to do anything in Maximo screen. But Maximo developed such a way, once start center loaded then Maximo will allow to navigate to applications.

  •       Clean User desktop Temp Files by execute Temp from Run
  •       Clean Temp files from user desktop by execute %temp% from run.
  •       Java Cache Clear-Control Panel->Java->Temp Files ->Delete All
  •       Clear IE Cache
  •        Restart the PC.