Diagnostic Tools

Oracle Transportation and Global Trade Management provides several utilities to help while configuring the system and while the system is running. The following sections describe these utilities.

Application Logging

Oracle Transportation and Global Trade Management provides an embedded logging utility. Application logging is configured on the page Configuration and Administration > Power Data > General > Log Files. Application logging provides detailed information about the processes running in the system. The output of the logging is viewed on the following page, which is accessible from all parent menu groups,Process Management > Logs > System. For more details, see the “Logs: System and Integration Files” help topic.

Although logging is a vital function in Oracle Transportation and Global Trade Management, excessive logging is a very common cause of poor performance. This is particularly true of bulk planning processes. You can review what logging is currently enabled in the system using the page Configuration and Administration > System Administration > Logging Overview. You can also temporarily disable all logging by setting the following property:glog.log.suppressAll=true

Setting this property can be a quick method of identifying whether logging is the cause of a performance issue.

Note: The Logging Overview screen can't be used to display summary information or suppress logging in Log Files of type WEB.

LogIDs with a suffix of “Debug” or “Details” have the potential to log significant amounts of data and should be avoided unless directed to be by Oracle Technical Support. Ad-hoc logs are the most dangerous because they generate logging regardless of the user logged in. On the other hand, User logs only write to the log file when that particular user is logged in and using Oracle Transportation and Global Trade Management. In some scenarios user logs can still have a significant impact on performance, even if that particular user isn'tlogged in. This logging happens because there's a certain amount of overhead in generating a log message. The overhead occurs before Oracle Transportation and Global Trade Management determines, based on the logged in user that it doesn't need to write the message to the log file. For this reason, having many user logs with detailed logging enabled can have a significant impact on performance.

Note: Log files are limited to a maximum size of 10MB and 20 Backups.

Action Logging

To streamline diagnoses of issues, OTM supports a type of logging called Action Logging. When running a finder/manager action, editing a top-level record or submitting a process control action, you can opt to turn on a log dedicated to that action. While the action runs, all logging needed for diagnostics is written out to a single, specific log file. When the action completes, you can view the focused log and download it for offline analysis.

For more information, see the About Action Logs topic in the online help.

Performance Monitoring

Oracle Transportation and Global Trade Management provides embedded tools which should be used for investigating performance issues. The following tools are located on the menu at Configuration and Administration > Technical Support:

  • Diagnostics and Tools
  • Configuration Collection
  • Performance Collection

These tools provide insight into the current transactions in the system, as well as, historical statistics based on previous transactions. They capture data on technical components of the application such as data caches, workflow threads, object locks, and more. Diagnostics and Tools are a set of user interfaces, whereas Configuration Collection and Performance Collection are utilities which capture data in an XML format. Should performance issues occur in the system you may be requested by Oracle Technical Support to monitor and/or capture data from one of these utilities.

Historical Metrics and Notifications

The Oracle Transportation and Global Trade Management Cloud Service captures a broad set of performance metrics. These performance metrics are persisted to the database on an hourly basis and are aggregated by day and week and are referred to as Historical Metrics. The Historical Metrics cover many technical components within the service including User Interface, Integration, Agents, Email and Logging. They also cover Infrastructure Health components including caches, connections, object locks, and memory. These metrics should be used to help identify, diagnose, and resolve application performance issues. Refer to the Historical Metrics topic in the online help for more details.

Metric Collections provide a configurable mechanism for comparing Historical Metrics to a baseline. Email Notifications can be generated based on user defined thresholds. It is also possible to initiate a Diagnostic Logs capture, QDLogs, based on a defined threshold. This will provide additional diagnostic data for analysis by Support and Development. Please refer to the How to Configure Metric Collections topic in the online help for more details.

Business Object Caches

The Transportation and Global Trade Management Business Object caches are maintained by Transportation and Global Trade Management. The majority of Transportation and Global Trade Management Business Objects caches use a Least Recently Used (LRU) strategy to maintain the cache. When an LRU cache reaches its maximum, a one-for-one exchange is made for the new object and the least recently used object in the cache. Most static data used by Transportation and Global Trade Management business logic is maintained in one of these caches. The App-tier Caches utility page, located on the menu under Technical Support – Diagnostics and Tools – Caches, can be used to review statistics on these caches.

The size of a Business Object Cache can have a significant impact on performance. The efficiency of a cache is measured by its hit ratio. A low hit ratio is a possible indication of an undersized cache. If a cache has reached its capacity and the hit ratio is low (less than 0.80), performance may be impacted. Increasing the maximum size of this cache may increase system performance. Temporary changes can be made to the cache using the diagnostic screen, but the changes will revert to the default upon restart. To permanently change the size of a cache the appropriate glog.property must be set in a Property Set. For example, the size of the Rate Offering cache is set by the following property:glog.cache.TRateOfferingCache.capacity=2000

It is important to note that increasing the size of the cache has the adverse effect of increasing memory usage, so changes should be done incrementally and with thorough testing. Please refer to the Property Sets section of this document for more details on changing property value.