Debugging the module systematically

Use a pattern to determine an issue within the custom modules. This pattern minimizes the time required to investigate and debug.

1. Use the console in the client.

   Most browsers have their own development tools built-in. If there are client-side errors in the JavaScript, they are displayed in the console of these tools. The resources are still being aggregated so it can be difficult to identify the exact resource that causes the error.

2. Turn on tracing.

   With tracing, we can see the specific resources that are aggregated on the page and we can see the location of where an error in the console originates. We can follow the code flow and track the expected values within the code.

3. Investigate the logs.

   If the error is not apparent in the client-side console, then investigating the HCL WebSphere Portal system logs is another likely place to track down an issue. These logs display any server-side errors and tracing enabled.

   1. Open portal logs...
      WP_PROFILE//logs/WebSphere_Portal/SystemOut.log
      WP_PROFILE/logs/WebSphere_Portal/SystemErr.log

   2. Enable more tracing through the Enable Tracing portlet in the Administration section of HCL WebSphere Portal.
      Administration | Portal Analysis | Enable Tracing

4. Add logging to the resources.

   The HCL WebSphere Portal code logs throughout the product for serviceability. However, the custom code might need more logging inserted to track down an issue. For client-side code, use a console log statement. A typical console log statement for displaying a value with a label is console.debug("example value: "+value);. Using this code displays a string value. To display the object in the console to see the values stored in the object, use

   console.log("the ibmCfg object:");
   console.debug(ibmCfg);

   The first line tracks the instance of the object. The second line adds the object to the console. Then, use the console to see the attributes and their values.

5. Ensure the resources are loaded on the page.

   If a particular feature of the page is not visible or does not seem to function properly, sometimes the resources are not on the page. To verify, we can view the requests on the page and see the individual JavaScript or CSS. Ensure the files needed for the function are included on the page. If resources are missing, edit the profile to include the necessary modules.

6. Investigate with the Theme Optimization Analyzer portlet.

   This portlet displays attributes of the theme, pages, profiles, and modules. We can investigate a module, and view the details for visibility based on device class and contributions of resources. Each resource is listed with its path in the server.

7. Export XML definition for resources.

   After you investigate the issue, modifying the resource attributes is the next solution. Resources that would require a change to their XML definition are the theme, page, client, or device class.

   WP_PROFILE/PortalServer/bin/xmlaccess.sh

   Examples are located in...

   PORTAL_HOME/doc/xml-samples/

   The following scripts export specific resources related to the theme framework.

   • Export all theme definitions to modify features such as metadata, resource root, default layout, or theme template definition. We can also modify other attributes through this definition.

     <?xml version="1.0" encoding="UTF-8"?>
     <request  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
     type="export" create-oids="true">
     <portal action="locate">
     <theme action="export" active="true" object></theme>
     </portal>
     </request>

   • Export page definition to modify features specific to the theme such as theme template override, dynamic content spot overrides, or device class filtering.

     <?xml version="1.0" encoding="UTF-8"?>
     <request  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
     type="export" create-oids="true">
     <portal action="locate">
     <content-node action="export" uniquename="ibm.portal.SamplePage"/>
     </portal>
     </request>

   • Export all defined clients to modify the device class assigned. We can view this information in the Manage Clients portlets as well.

     <?xml version="1.0" encoding="UTF-8"?>
     <request  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
     type="export" create-oids="true">
     <portal action="locate">
     <client action="export" uniquename="*"></client>
     </portal>
     </request>

   • Export all defined device classes to view the available groups and change the title or ID.

     <?xml version="1.0" encoding="UTF-8"?>
     <request type="export" create-oids="true"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0_2.xsd">
     <portal action="locate">
     <device-class action="export" uniquename="*" />
     </portal>  </request>

Parent Troubleshoot modular themes