This is the heart of the application and holds all the necessary information about the basic configuration details. There will be only one instance of this component per active application (TechPortal, Self-Service). So during every first login after a server restart, IISRESET, this component would be loaded and remain in memory until the application is live. Generally, this component will not give any errors, unless there’s a DB connectivity issue, DB is corrupt (manual updates of the internal Track-It! tables) or any other dependent component is failing.
 

Whenever the user observes a failure mentioning “MetaData Init failed” error, enable information/debug level of tracing. If still need not able to pin point the issue, then enable trace level and examine the logs.

Similar to the Metadata component, this one too exists as single instance. This component holds the key mapping of the licensed features. If this fails, or having issues, then the product would not function as there would be no detail about the license entitlements.

When to refer to logs:

Whenever the user observes license related issues, enable information/debug level of tracing. If still need not able to pin point the issue, then enable trace level and examine the logs

This component keeps track of the Technician logins. Based on the license type of the Technician, the login attempts would be handled accordingly. This also keeps the check on session activeness and end the inactive ones.

When to refer to logs:
 

Whenever the user observes issues while logging in or prompted repeatedly to override the already logged in session, enable information/debug level of tracing. If still need not able to pin point the issue, then enable trace level and examine the logs.

 

This component maintains all the workspace views. All the views that we ship out of the box as well as customer created would be handled by this component. This component also provides the count for rendering the Dashboard views.

When to refer to logs:
 

Whenever the user observes issues while loading Dashboard views or any of the workspace views, enable information/debug level of tracing. If still need not able to pin point the issue, then enable trace level and examine the logs.

Log file name: MGCQuickViews_<date stamp>.log

This component is responsible to render the module forms (Ticket/Assignment/Solution…) on to the disk as HTML files. We would be then accessing these files while working on the respective records.

When to refer to logs:
 

Whenever the user observes issues for not being able to access any forms of the module or the configuration section (Technician/Requestors), enable information/debug level of tracing. If still need not able to pin point the issue, then enable trace level and examine the logs.
 

These components are involved in the communication to the connected application servers, whenever there’s a change in the configuration section. These components issue a HTTP request internally, and generally known to work seamlessly.

When to refer to logs:
 

There will be no visual indicators of whether these HTTP call(s) failed. In addition to the log files, errors are logged in the Windows Event viewer with the source as the component name.

As the name indicates, this component is responsible to process all the business rules defined in the application. This is controlled by the “TrackIt Job Processor - TrackItBR” Windows Service. When this service is stopped, no jobs would be processed. Please note that this service is known to be CPU intensive in case of systems which have a large number of BRs defined and an active servicedesk.

When to refer to logs:
 

By default, we enable Informational level of logging for this component. This would have all the data that’s getting processed during the BR event. When there’s a failure of the job (other than notifications), this log file would hold the information about the failure.

8. Notification (NAMLogicNotification_<date stamp>.log)
 

As the name indicates, this component is responsible to listen to the mailbox configured in the incoming mail section. This is controlled by the “TrackIt Mail Processor - TrackItBR” Windows Service. When this service is stopped, no emails would be processed. This component works in conjunction with the Business Rules to accomplish the use cases related to emails.

When to refer to logs:

By default, we enable Informational level of logging for this component. This would have all the data that’s getting processed during the notification event. When there’s a failure of the notifications, this log file would hold the information about the failure.
 

 

As the name indicates, this component is responsible to fetch email(s) from the incoming mailbox configured with the POP3 access

When to refer to logs:
 

When no emails are processed from the configured mailbox (POP3), do enable the trace for this component. Another recommendation is to have the “Enable Email Event Logging on the Track-It! Server” enabled on the Email Monitor Settings section of the configuration.

 

As the name indicates, this component is responsible to send out emails from within the application. In R1, we used to rely on the local SMTP service to handle the sending of emails. From R2, users can configure a dedicated mailbox and use that for sending out emails.

When to refer to logs:
 

When no emails are received from Track-It! application (even from the Notification through BRs), enable Debug/Trace logs to examine the cause of the failure.

11. Ticket (LogicHelpdesk_<date stamp>.log)
 

As the name indicates, this component is responsible for the Ticket records. All the Ticket record related updates (Tech Portal, BR, Self Service) will be processed by this component.

When to refer to logs:
 

When there is a discrepancy of the data that’s getting saved/updated in the Ticket record, enable logs for this component. There are few other components that would work in conjunction with this one: Attachments, Due Date Calculation and Start/Stop Clock.
 

As the name indicates, this component is responsible for the Assignment records. All the Assignment record related updates (Tech Portal, BR) will be processed by this component.

When to refer to logs:
 

When there is a discrepancy of the data that’s getting saved/updated in the Assignment record, enable logs for this component. There are few other components that would work in conjunction with this one: Attachments, Due Date Calculation and Start/Stop Clock.
 

As the name indicates, this component is responsible for the Attachment records linked to various other module records.

When to refer to logs:
 

When there is an issue with adding/fetching the attachment record(s) from various modules, enable logs for this component.
 

As the name indicates, this component is responsible to calculate the due date for a Ticket/Assignment based on various factors: Priority, Work Schedule, Time Zone difference, Assigned to Technicians’ availability, etc.

When to refer to logs:
 

When the due date is not properly calculated, enable log for this component.

 

As the name indicates, this component is involved in the pausing or restarting the time for the Ticket/Assignment records. This feature is particularly useful when the resolution is dependent on external factors and we don’t what the SLA to be breached.

When to refer to logs:
 

When the restarting of the clock is not pushing the due date or the change of status is not activating the start/stop clock (based on the status record), enable logging for this component.

 

This component is responsible for the background processing of tasks such as Asset Synchronization, Scheduled Reports, etc. This is very similar to the monitor infrastructure that we have in v11.4. Please bear in mind that the Track-It! application (application pool) has to be active in the IIS process for this to work.

When to refer to logs:
 

If there are issues related to any of the asset sync, scheduled report related issues, enable logging for this component.
 

 

These are the components for the Tech portal and Self Service.

When to refer to logs:
 

In case there are any unhandled exceptions thrown on the UI, enable logs for these components and examine the details for the issue. Mostly these issues may result in defects, but not always.