OracleAppsDBAKK1: Key Logs When Troubleshooting Demantra Issues - From Installation to Operations (Doc ID 741464.1)

In this Document

APPLIES TO:

Oracle Demantra Demand Management - Version 7.0.2 and later
Information in this document applies to any platform.

PURPOSE

This document outlines the location of the main troubleshooting logs that you will need during all phases of Demantra Installation, Go-Live and Lifecycle Support.

Note that while this list is not exhaustive, or necessarily valid for all Demantra versions, it is meant to provide the locations of those logs that would commonly be used during first and
second line troubleshooting. Also, it should be stated these logs may not lead to the actual resolution of your issue but are meant to provide extra clues which could then be used to reference
other Support Notes and/or can be provided to Oracle Support.

Please check out the referenced documents at the bottom of this note.

Any questions about these logs or tables should be directed to Oracle Support.

SCOPE

This note should be used by anyone responsible for installing and/or maintaining the health of the Oracle Demantra Application

DETAILS

1. Installation of the Demantra Base Application, Patches or Version Upgrades

   For Clients installing or upgrading Demantra Versions 7.2.0 and higher then please refer to Note 1077000.1 for new logging options.

   Note that there will also be some ancillary logs under the following folders:

   .. Demand Planner\Database Objects\Oracle Server (Oracle back end database)

   .. Demand Planner\Database Objects\Microsoft SQL Server (Sql Server back end database)

More information on troubleshooting the Demantra base installation process is found in Note 430913.1

2. Error starting the Web Server and/or deploying the Demantra WAR file

Review the Collaborator.log which is found under the ...Collaborator\demantra\logs folder on the webserver where Demantra is running. Also, each individual webserver (ex. OAS, JRUN, Tomcat, Websphere, etc...) will have their own individual logs in various directories which can also be consulted. The individual webserver documentation should be reviewed for these log locations.

3. Error logs for the Demantra forecast engine - batch or simulation

When the Engine Executables are installed on Windows, additional troubleshooting tips for the Demantra Batch Engine are found in Note 848205.1.

   The key engine logs are found under the root drive of the machine where the engine executables are located and the engine is launched from. If you are using
   the distributed mode (ex. running the engine on Machines A, B and C):

   If the primary engine is on Machine A then all logs will be found on that Machine.  The folder on that machine, that holds these logs, usually have Engine2k somewhere in the name.
   Note that there should be at least Engine2k logs, these logs record the actual splitting and forecasts that the engine does, present in this folder.

   However, to write the primary EngineManager logs to this folder you need to go to the Engine Administrator
   (..Demand Planner\Analytical Engines\bin --> Settings --> Configure)
   and change the Engine Manager Log tab from STD to FILE. If you did not have Log set to FILE then we would expect you to re-run the engine one more time so that
   we can record this additional logging.

   Note: It is NOT advised to re-register the engine after making this change

   When the Engine Executables are installed on Linux (new option starting in Demantra v73)

   Engine and EngineManager logs are placed at the same level as installed BIN and LIB directories. They can be accessed under $ENGINE_ROOT/engine2k directory.
   Sub directories are arranged according to schema name, machine name and run time. Log placement can be configured in $ENGINE_ROOT/bin/Settings.xml file, relative to $ENGINE_ROOT/lib/Engine.exe location or by supplying full path.

4. Stored procedure errors with Active_Proc_Dyn somewhere in the error message

To view the errors go to Business Modeler --> Tools --> Procedure Error Log

Note that this looks to the backend table called db_exception_log

5. End user errors, when they occur in a Demantra worksheet, or when end user updates appear not to be processed or saved correctly.

   The important log that we want to review with end user issues (ex. screen freezes, error messages appear when running or editing a worksheet, end user updates
   are not being processed*, etc..) is the Java plugin log.

   There are two ways to get this log:

   1) In the bottom, right hand part of the machine you will see a Java coffee cup icon. Right click on it > Open Console. Note that if there are more than one
      icon then look for the log that referencesDemantra in the URL

      To make sure that you are not including old messages, press the clear button and then try to recreate the issue again.

   2) Clear your browser cache:

For IE, Hold the Ctrl key and press the F5 key - Or - hold the Ctrl key and click the Refresh button on the toolbar
For Mozilla Firefox, hold down the Ctrl key and then press F5 - Or - hold down both the Ctrl and Shift keys and then press R
For Chrome Either: Hold the Ctrl key and press F5 - Or - hold the Ctrl key and click Reload button

      If the machine has frozen up then a log is still usually saved on the back end of the machine. This can usually be found by going to C:/Documents and
      Settings/<Username>/Application Data/Sun/Java/Deployment/log

      If there are no errors evident in the java plugin log then go to the Collaborator.log found under:

      http://< Host Name of Webserver : Port Number>/demantra/admin/systemLogs.jsp

      For example if you normally log into Demantra using the following URL:

      http://DEMANTRAMACHINE:8080/demantra/portal/loginpage.jsp

      then these logs would be accessed by going to:

      http://DEMANTRAMACHINE:8080/demantra/admin/systemLogs.jsp

      An alternative way to view these logs is to go directly the machine hosting the webserver and go to the logs found under ...Collaborator\demantra\logs
      (note that this a Windows Directory path example and Demantra, when deployed on non-Windows boxes, will still be under this folder path but obviously with
       different directory navigation steps)

      Look for the entries in the log around the time of the error (note that the webserver might be in a different timezone so an error for an enduser in New York
      at 4pm will show up at 1pm in the Webserver based in California)

      Enhanced Logging for End User issues can be recorded by going to:

      http://< Host Name of Webserver : Port Number>/demantra/admin/loggerManager.jsp

      For v7203 and lower once there, turn on the following lines (note that if the button is marked TURN ON then actually it is OFF. Once the button is marked
      TURN OFF then the logging is actually ON which is what we want). For v730 and higher these will have check boxes instead of ON/OFF buttons.

appserver.sql
appserver.audit_trail_sql
appserver.update.operation
appserver.update.process
appserver.update.sql
appserver.retrieve.sql
appserver.retrieve.data.sql

      Note that this logging will be turned off either by the next time the webserver is restarted or by the user turning off the lines that were earlier turned on.

      * For issues where updates are not being reflected in the series after re-running the worksheet, and there doesn't appear to be any errors in the Java
        Plugin or Collaborator.logs, then close out of the worksheet completely and try to re-run the worksheet one more time. If the update is then reflected
        that that usually points to a possible issue the last_update_date column and needs to be addressed differently. It should also be mentioned to Oracle
        Support if this problem with updates only recently started occurring with this series or if this is a new series that is being tested out.

6. Errors with Workflows or Level Methods that call Workflows (ex. Load Scenario Data)

   Although the root cause might lie in another log, the first log that should be checked is the Collaborator.log This log can be accessed by going to the following URL:

   http://< Host Name of Webserver : Port Number>/demantra/admin/systemLogs.jsp

   So for example if you normally log into Demantra using the following URL:

   http://DEMANTRAMACHINE:8080/demantra/portal/loginpage.jsp

   then these logs would be accessed by going to:

   http://DEMANTRAMACHINE:8080/demantra/admin/systemLogs.jsp

   To make sure you are not looking at older cached System Logs then press F5 since this is the IE method to refresh the cache.

An alternative way to view these logs is to go directly the machine hosting the webserver and go to the logs found under ...Collaborator\demantra\logs (note that this a Windows Directory path example and Demantra, when deployed on non-Windows boxes, will still be under this folder path but obviously with different directory navigation steps)

Look for the entries in the log around the time of the error (note that the webserver might be in a different timezone so an error for an enduser in New York at 4pm will show up at 1pm in the Webserver based in California)

   To enable Java console log:

   Start ->control Panel ->Java - >Advanced->

   Click for Enable Trace, Enable console and show console option

   Enhanced Logging for Workflow issues can be recorded by going to:

   http://< Host Name of Webserver : Port Number>/demantra/admin/loggerManager.jsp

Once there, turn on any line that has Workflow in it and then re-run the workflow in question. Note that this logging will be turned off either by the next time the webserver is restarted or by the user turning off the lines that were earlier turned on.

   For v730 and higher these will have check boxes instead of ON/OFF buttons.

appserver.workflow.general
appserver.workflow.steps
appserver.workflow.timing
workflow.general

If the error is in a Transfer step then you might need to consult that Integration Interface logs in the next section of this document.

7. Integration Interface / Transfer Step / APS.bat / APS.exe Errors or Data Issues

   Although the root cause might lie in another log, the first log that should be checked is the Integration.log This log can be accessed by going to the following URL:

   http://< Host Name of Webserver : Port Number>/demantra/admin/systemLogs.jsp

   So for example if you normally log into Demantra using the following URL:

   http://DEMANTRAMACHINE:8080/demantra/portal/loginpage.jsp

   then these logs would be accessed by going to:

   http://DEMANTRAMACHINE:8080/demantra/admin/systemLogs.jsp

   To make sure you are not looking at older cached System Logs, clear the browser cache:

For IE, Hold the Ctrl key and press the F5 key - Or - hold the Ctrl key and click the Refresh button on the toolbar
For Mozilla Firefox, hold down the Ctrl key and then press F5 - Or - hold down both the Ctrl and Shift keys and then press R
For Chrome Either: Hold the Ctrl key and press F5 - Or - hold the Ctrl key and click Reload button

An alternative way to view these logs is to go directly the machine hosting the webserver and go to the logs found under ...Collaborator\demantra\logs (note that this a Windows Directory path example and Demantra, when deployed on non-Windows boxes, will still be under this folder path but obviously with different directory navigation steps)

Look for the entries in the log around the time of the error (note that the webserver might be in a different timezone so an error for an enduser in New York at 4pm will show up at 1pm in the Webserver based in California)

   Note that errors might also be found in the following tables in the Demantra schema/database:

   - <Integration Interface Table name>_ERR (ex. if the staging table is name Biio_Supply_Plan then the error table would be Biio_Supply_Plan_Err)

The ERR table mentioned above is checked to see when the record does not make it from the staging table (ex. Biio_Supply_Plan) to the end Demantra table (ex. Sales_Data). For certain types of integration there might be 4 additional intermediate tables which should also be checked for records being kicked out or else not fully processed.

   They are:

UPDATE_BATCH_TRAIL
UPDATE_BATCH_VALUES
UPDATE_BATCH_TRAIL_ERR
UPDATE_BATCH_VALUES_ERR

Each of the above ERR table will have a message field with at least a brief description of why it was kicked out.

8. Errors with Member Management or Chaining

Note that issues with actually launching these two applications from the Collaborator Workbench and other silent installer issues should be addressed by reviewing Note 947322.1

   Errors that occur in Member Management might be seen by going to Business Modeler --> Tools --> Procedure Error Log

   Note that this looks to the backend table called db_exception_log

   Errors that occur during Chaining* might also be might be seen by going to Business Modeler --> Tools --> Procedure Error Log

   An additional error message table for Chaining is the Chains_Queue table (can only be viewed by use of SQL commands).

   * It should be noted that this error has to do with when the Status states 'Failed' and is not meant to cover legitimate warning messages like 'No Common
     Population or Source' indicating that the setup of your chaining profile is possibly incorrect.

9. Issues with EBS/ASCP Integration to/from Demantra (ex. Shipment and Bookings, SCI Data, etc..)

   This section talks about troubleshooting integration or data loads that start with the job launching outside of Demantra (ex. Launching the jobs from the Oracle
   EBS Concurrent Request screen such as the Collect Bookings and Shipment History job).   Data Collections, like Load Scenario Data, which is launched directly
   from the Demantra Collaborator Workbench (ex. by right click functionality) should be debugged, at least initially, using the Errors with Workflows or Level
   Methods that call Workflows (ex. Load Scenario Data) section of this note.

For those persons used to working with Oracle EBS/ASCP applications you know that most jobs (ex. Collections) can be logged using the steps found in Note 245974.1.

However, jobs that directly relate to Demantra (ex. Shipment and Bookings Collection, Load SCI, etc..) can have extra logging turned on by changing MSD_DEM: Debug Mode to Yes (default is No) and MRP DEBUG: Yes at the User level (turn on this logging in both the Source and Destination instances).

Note that as these jobs move to the other side of the wall from EBS/ASCP to the Demantra side of the database (usually indicated by when you start seeing references to the Demantra schema or tables like t_src_items_tmpl, t_src_sales_tmpl_err, biio_sci_data, etc.) then these errors may need to be tracked using the Workflow or Active_Proc_Dyn or Demantra specific troubleshooting sections of this note.

Review in:

Concurrent Request Log/ View Output Log / View Logs
Log for the Request_id Log in question
Demantra Staging tables and related Err tables
apscheck.sql

10. Error with Legacy Demantra Scheduler Application (ex. Manuals_Ins, Dynamic_Sync, etc.)

Prior to Demantra Version 6.x, when the application became a Web Based front end application, clients would have used a native Demantra application, commonly referred to as Scheduler, to run various stored procedures at set intervals. The most important of these jobs was the Manuals_Ins stored procedure which pre-dates the asynchronous Java Updater (the latter which came into the application starting in v7.x). Errors on the Scheduler, usually indicated by a Red Stripe over the job on the application interface, can be tracked by going to the logs found under the ..Demand Planner\Scheduler\bin folder on the machine where the Scheduler is running.

11. EP_LOAD PROPORT and MORE Can Use LOG_IT to Enhance Log File Information

LOG_IT is a logging mechanism for Demantra PL/SQL database procedure code. It is analogous to log4j in Java.
LOG_IT can be used to trace a procedure flow, show variable values and record performance timing without having to run a debugger.
LOG_IT is only available for a limited number of procedures like CHAINING, PROPORT, SIMULATION, EP_LOAD, ADD_MISSING_DEFAULT_ROWS and more. The list keeps growing.

The available procedures are listed in the LOG_IT_PARAMS table.

See Note 1408753.1 for details regarding LOG_IT.

Summary

In summary, most clients who have the Scheduler running at their site are going to be pre-Version 6.x clients but we might have some clients on the latest versions of Demantra continuing to run it due to Bug 6439497. Jobs that are running in the Scheduler should be ported over to the Demantra Workflow schedule by the client or consultant and given the same schedule run times and frequency as in the current Scheduler. Note that Dynamic_Sync and Manuals_Ins however serve no purpose in v7.x versions of Demantra and higher and should not be ported over to the Workflow.

REFERENCES

NOTE:1675117.1 - Demantra Topical and Procedural Debugging Using Log Files and Key Troubleshooting Techniques Including LOG_IT and the NEW SET_LOG_IT_LOGGING Procedure
NOTE:947322.1 - Step by Step Troubleshooting of the Silent Installer (opening up the Business Modeler, Chaining, or Member Management links from the Demantra Collaborator Workbench)
NOTE:1481533.1 - Oracle Demantra v7.3.1.4 to v12.2 Installation Guide to Simplify Installation Process Using Weblogic
NOTE:1952102.1 - Demantra Debugging, Error Location, Log File Location, Log Files by Process, Patch, Patching
NOTE:848205.1 - No Demantra Forecast Generated - Common Issues
NOTE:1408753.1 - Demantra LOG_IT Setup Execution Explanation ORA Errors Detailed Log Production + New SET_LOG_IT_LOGGING Procedure
NOTE:1614966.1 - Oracle Demantra Development strongly suggests all customers uptake this critical patch. Patch 17808535. Critical Internal Processing Patch
NOTE:1086704.1 - Demantra Engine on Linux or Unix Failure Hanging Error Not Starting Debugging Install and Configuration Checklist

OracleAppsDBAKK1

Tuesday, November 16, 2021

Key Logs When Troubleshooting Demantra Issues - From Installation to Operations (Doc ID 741464.1)