Testing Enterprise Server 9 using the Health Check page

Whenever an important change is made to the setup or configuration of Enterprise Server or any of its 3rd-party integrations, it is recommended to test the working of Enterprise Server.

A dedicated test page exists for this purpose named the Health Check page.

Figure: The Health Check page is used for testing Enterprise Server and the integrated 3rd-party systems.

Accessing the Health Check page

Step 1. In Enterprise Server, click Advanced in the Maintenance menu or on the Home page. A page with all advanced Maintenance features appears.

Step 2. Click Health Check.

The Health Check page appears.

Note: When you are not able to log in to Enterprise Server (for instance because of an incorrect configuration), access the Health Check page by entering the following URL in your Web browser: <Server URL>/server/wwtest/testsuite.php

If the test page is not displayed, the Web Server is not working properly. Some of the issues that you may run into could be:

• Error: “Forbidden - You don’t have permission to access /Enterprise/Server/wwtest on this server”. Check the file system’s access rights on the Enterprise folder and make sure that the Web user (Mac OS: “www”, Windows: “IUSR_<servername>”, Linux: “www”) has at least Read access. An easy fix is to recursively apply Read access to “Other” (Mac OS and Linux) or “Everyone” (Windows).
• The page does not come up. Try http://<server URL>/Enterprise/server/wwtest/index.htm. If this works, this means that your Web Server does not have its default page set correctly. (See your Web server documentation for details about how to fix this.)
• No test screen appears, just some PHP code. This usually means that the Web Server has no association for the .php extension. This can be fixed in the Apache configuration file or in the Microsoft Internet Information Services (IIS) Manager, depending on what Web server you are using.

Tip: The user name and password used for the Health Check routine is set in the Enterprise server/wwtest/Tests/Logon/Logon.test.class­.php file, which can easily be edited at any time to match the user name and password you wish to use for the logon test.

Running a test

Run a test by having the check box selected for a test and clicking the Test button.

Tip: To view additional information about a test, click its paperclip icon.

After the test is run, the result is shown. These can include the following:

• OK
• Warning
• Error
• Not installed
• Info
• Skipped

Additional information about the result of a test can appear in the form of instructions and background information and may include guidelines for resolving any issues.

Tip: Click the paper clip icon next to each test to see a description of that test.

Figure: After running a test, the results are shown.

Troubleshooting tests

The following are some general issues that you may run in to when using the Health Check page:

• If the WSDL Cache test fails, do one of the following:
• Create a folder named “tmp” on the root of the hard drive
• In the php.ini file, modify the path to another folder in the following setting:

soap.wsdl_cache_dir=”/tmp”

• If the Logon/logoff test fails in an Enterprise/IIS Web Server configuration resulting in an error similar to: “LogOn Logon FAILED: HTTP Response 401 Authentication Failed Time elapsed: 0.02s”, then the access rights are not correctly set for the Web user. Open IIS and check the Anonymous Access and Authentication Control settings on the Directory Security tab. Click the Edit button and make sure that at least the Anonymous Access check box is set. It is not necessary to also have the Integrated Windows Authentication checked.

• Of the File Storage test fails, then the new subdirec­tory “_SYSTEM_” must be added to the File Store directory. This subdirectory must have the same access rights as the File Store directory.

• If the Server Plug-Ins test fails when logging in to Enterprise for the first time after installation, go to the Server Plug-ins page to initialize those plug-ins and go return to the Health Check page to run the test once more.

• If a test is running for too long, click Abort.

About passwords

Some tests require a user name and password. In the shipped Enterprise configuration, the “woodwing” user with password “ww” is hard-coded and should therefore be changed in order to make these tests work in your production configuration.

Step 1. Open the configserver.php file.

Step 2. Locate the TestSuite section:

// ---------------------------------------------------------------------------
// Testing - Options used by TestSuite modules (at wwtest page)
// ---------------------------------------------------------------------------
define( 'TESTSUITE', serialize( array(
	'User'     => 'woodwing',  // User name => for automatic login during tests
	'Password' => 'ww',        // User password => "    "
	'Brand'    => 'WW News',   // Brand name => picked to create/retrieve test data
	'Issue'    => '2nd Issue', // Issue name => "      "
	'SoapUrlDebugParams' => '',// Debug params posted by SoapClient at SOAP entry 	 
			           // point URL (only applied when DEBUGLEVELS is set 
			           // to 'DEBUG'). Typically useful to trigger 
				   // Zend/Komodo debuggers. 
)));

Step 3. Change the following values:

• User. User name.
• Password. Password.
• Brand. Name of the Brand to create or retrieve data.
• Issue. Name of the Issue to create or retrieve data.
• SoapUrlDebugParams. Debug parameters posted by the SoapClient at the SOAP entry point URL (only applied when the DEBUGLEVEL option is set to DEBUG. It is typically used to trigger Zend/Komodo debuggers. One parameter which can be added is start_debug=1. This will trigger the debugger of Zend Studio or Komodo.

Step 4. Save and close the file.

Saving log files

Certain tests can return problems which cannot be fixed by for instance changing the configuration. For these types of errors, the Show Log button at the bottom of the page can be clicked. This raises a browser window with the server logging of the test(s).

Note: In order for the information to appear, Server logging needs to be enabled in the configserver.php file.

If you are unable to solve the problem using the logging information, do one of the following:

• Customers: Save the log as a HTML file and submit it to your local reseller.
• WoodWing Partner companies: Save the log as a HTML file and submit it to Woodwing Support.

Additional tests

The menu on the left side of the Health Check page provides options that either execute a test or provide an overview of a specific installation or configuration.

• Health Check. Opens the Health Check page.
• Config Overview. Displays settings as set in the config.php, configserver.php and serverinfo.php files, as well as details about the installed PHP version.
• PHP Info. Shows details on the PHP configuration and/or which libraries are installed.
• Planning Interface. Automatic test tool *
• Admin Interface. Automatic test tool *
• Data Source Interface. Automatic test tool *
• Data Source Admin Interface. Automatic test tool *
• Spelling Profiler. Automatic test tool *
• Spelling Workbench. Automatic test tool *
• Spelling Unicode Blocks. Automatic test tool *

* Automatic test tools are typically used by system integrators. They demonstrate a complete functional working Enterprise Application Server and provide sample materials that can be used to ease integrations with 3rd-party products. Each tool fires all possible service requests defined in the interface. Requests are fired from a SOAP client (written in PHP) against the Enterprise Application Server (also written in PHP). The client and server run in separated PHP processes.