Application debugging process

The following steps can guide you through debugging an AR Systemapplication.

Task 1: Where is the bug located?

Isolating the source is the process of eliminating all the possible causes of the bug, until the actual cause is found. After you have identified a small number of objects as probable causes, you can usually solve the issue by examining the object definitions.

Identifying problem forms

Determine which forms are involved with the issue.

• Can you observe the bug directly on a form?
  For example, the contents of a field are not what you expect, or fields that should be visible are hidden. In this case, you know immediately which form to focus on.
• Can you observe only the results of the bug?
  The application developer must understand the workflow to determine the correct form. For example, a macro might run on one form that pushes data onto, or creates a request in, a different form; the issue is observed in the form that contains the pushed data, not the form with the bug.

Identifying problem fields

After you have isolated the form that contains the bug, isolate any fields that are associated with the issue.

• Can you observe the bug directly in a field?
• Is a macro involved?
  If so, look at the macro definition.
• Are the field properties involved?
  For example, the field is not large enough, or the default values are incorrect.

Task 2: Is workflow involved?

If you did not resolve the bug by reducing the possible sources of the issue to a form and a small number of fields, the issue is probably workflow-related. Workflow is the source of the majority of code bugs.

Workflow debugging is complex because a workflow object responds to a two-stage trigger of cause and effect.

• The first trigger stage (the Execute On condition) is an application event. Filters use request transitions such as Modify or Submit while active links use an interface event like Open Window.
• The second trigger stage is the evaluation of a qualification. If the qualification evaluates to TRUE, then the actions specified in the If branch are executed. If the qualification evaluates to FALSE, then the actions specified in the Else branch are executed.

Is the problem with server-side workflow?

Does something happen on the server every time you create a new request? If so, the bug probably involves the server side, which might be with filters and escalations.

Is the problem with client-side workflow?

Does something happen on the server every time you select a button on a form? If so, the bug probably involves the client side, which might be with the active links.

Which objects respond to the event?

After you have decided to focus on either filters, escalations, or active links, determine which objects respond to the event, the filters or active links that have an Execute On condition that matches the cause. This reduces the number of objects to examine.

Task 3: Reproduce the bug

Mid Tieris equipped with a logging feature that captures real-time combined (server and client) workflow. You can usually resolve workflow-related bugs, including combination active link/filter bugs, by inspecting this log. For more information about logging, see Working-with-logs.

To use the combined workflow log

1. After you have reduced the number of workflow objects to examine, log on to 

   Mid Tier

   using the same browser (type and version) on which you observed the problem.

2. Navigate to the AR System User Preference form and click the Logging tab.
3. Turn on logging for the type of workflow that needs debugging (Active Link, Filter, or API and SQL logs) and save the changes.

4. Log out and log in back again.
   A pop-up window is displayed that logs the workflow. Make sure that the pop-ups are enabled in 

   Mid Tier

   .

5. Duplicate the issue you are debugging.
6. Examine the pop-up window, which displays the captured information about the cause and effect and execution sequence of filters and active links.

Active link debugging example

Chris Code works for a county maintenance department. Chris built two applications: one designed to track road maintenance and repairs in the district, and one to report bugs in the application. 

Chris designed a form called Road Defect, which can be displayed in different ways, depending on the contents of various fields. The user clicks on an action button to change the view. 

When Terry Test clicked on the action button, the form did not change as expected, so Terry reported a bug. The bug report tells Chris that the issue is with the specific button on the Road Defect form. 

Chris looks at each active link in Developer Studioto determine which active links are associated with the button. The links are all simple code, without macros, and the code is correct. 

Chris then uses active link logging to record the link actions while reproducing the issue. The log file shows that one of the active links is not running, so Chris looks at the active link definition in Developer Studioand discovers that the link is disabled. Chris enables the active link and retries the operation. 

The active link still does not work, so Chris looks at the workflow log again, and sees that the qualification is failing. The Run If qualification shows that the qualification depends on the contents of a display-only field, normally hidden on the form. Using Developer Studio, Chris makes the field visible and tests the issue again. The contents of the field are not correct. 

Chris learns that another programmer disabled the display-only field because it appeared not to be affecting the application. Knowing that most display-only fields have values pushed from other forms, Chris inspects the workflow for the display-only field. The value is set by a single active link, so Chris looks at the active link definition and sees that the source of the Set Fields action is a concatenation of a field the user fills in using a menu, and a string constant. The constant is not correct. Chris corrects the constant, which solves the issue.