Demantra Issues and Troubleshooting

1. Installation of the Demantra Base Application or Patches
Create a C:/Tmp folder on the machine where the setup.exe will be executed prior to the installation as this will generate a log file to this folder

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 while additional Patch installation information is also found in Note 453127.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. Errors with the Demantra Batch or Simulation Engine
The key engine logs are found under the root drive of the machine where the engine is launched. The folder that holds these logs usually have Engine2k somewhere in the name.

Note that there should be at least Engine2k logs (these are the logs that show the actual splitting and forecasts that the engine does) in this folder.

However, to write the master 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.

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

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/Saved Correctly.

The important log that we want to get usually 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 references Demantra in the URL

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

2) 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//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://<>/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
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

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://<>/demantra/admin/loggerManager.jsp
Once there, turn on the following lines:

appserver.sql
appserver.audit_trail_sql
appserver.update.operation
appserver.update.processapp
server.update.sqlappserver.retrieve.sqlapp
server.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. Workflow Errors
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://<>/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
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

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 Workflow issues can be recorded by going to:

http://<>/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.

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
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://<>/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

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

Look for the entries in the log around the time of the error. Note that errors might also be found in the following tables:

- _ERR (ex. if the staging table is name MSD_DEM_PRICE_LIST then the error table would be MSD_DEM_PRICE_LIST_ERR)

The above ERR table is when it is going from the staging table (ex. MSD_DEM_PRICE_LIST) to the main integration staging tables,

UPDATE_BATCH_TRAIL and UPDATE_BATCH_VALUES.
UPDATE_BATCH_TRAIL_ERR and UPDATE_BATCH_VALUES_ERR

The above ERR table is when it is going from the integration staging tables UPDATE_BATCH_TRAIL and UPDATE_BATCH_VALUES to the final Demantra table (ex. Sales_Data)

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 463049.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 Integration to Demantra

In general, most EBS side activities (ex. Planning Data Pull) can be logged using Note 245974.1 however, the Shipment and Bookings Collection job can have extra logging turned on by changing MSD_DEM: Debug Mode to Yes (default is No).

Note that as the Shipment and Bookings Collection job moves to the other side of the wall from EBS side of the database 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 or t_src_sales_tmpl_err) then the errors may need to be tracked using the Workflow or Active_Proc_Dyn troubleshooting sections of this note.

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

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. This scheduler would 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). To track the errors from any of the procedures/jobs in the Demantra Scheduler then go to the logs found under the ..Demand Planner\Scheduler\bin folder.

So in summary, most clients who have the Scheduler running at their site are going to be pre-Version 6.x clients but you might have some clients on Version 6.x and early Versions of 7.0.x that have it running in place of the newer Workflow Manager application.