Changes
One of the most complex challenges when working on any software project is to debug unintended behavior. In {{UBIK}}, there is an inherent structure to every project, which we can exploit for debugging. Let's find out, how.
== Quick-fix check list ==
== Debugging {{UBIK}} ==
<!-- DO NOT REMOVE THIS -->{{Template:HowTo/Begin}}<!-- DO NOT REMOVE THIS -->
= Reproduction =
= Visualizing the algorithm === Full Test System ====In order to find out what's going on To reproduce the problem with {{UBIK}}, you require a test setup. This usually means a local copy of the database the problem occurred with and an installation of the {{UBIK}} products relevant for the problem. It is important to debug efficientlyuse the same binaries, plugins and versions as in the system where the problem occurred.Then, we must be able can try to imagine provoke the workflow and architecture of reported issue in the use-casetest setup. This might require getting more information about the issue.
=== Inspect the mobile client ===
* Use the [[Developer_Mode]] to inspect the currently visible view models and their values.
* Inspect the log files of the mobile client, including the web service client log.
=== Inspect the web services or the Enterprise Service ===
* Inspect the log files of the web service or Enterprise Service.
* Modify your plugin or programmatic customizing to output log messages describing the state of your program at critical points.
* Modify your plugin or programmatic customizing to write diagnostic {{UBIK}} objects describing the state of your program at critical points.
* Use a Who-Bert script to test a specific setup and output log messages to the console.
= Hypothesizing =
In order to narrow down the cause of the problem, we can try to formulate an idea what could have gone wrong. Optimally, we actually go and look for a proof, to see it happen in action, but it's always good to know potential error sources. In general, there are several common types of problems, and from another perspective, a set of common sources for such problems.
=== Visualizing the architecture and algorithm ===
In order to come up with a good hypothesis, you must understand the architecture and algorithm at work.
This means you have to find out which {{UBIK}} products and modules are involved and how the affected use-case is implemented in the project.
[[File:IL_Platform_Architecture.png|thumb|The UBIK platform architecture]]
Nearly all use-cases in {{UBIK}} projects are either related to the mobile client or to interfacing with 3rd party systems. Though the specific implementation can be very different from others, the general flow of information throughout {{UBIK}} modules will almost always be similar. If there is a problem, it has to occur in one of the respective steps, caused by one of the listed dependencies.
In this case, the {{UBIK}} Proxy mechanism is an additional source of complexity; but there's a [[HowTo:Configure_Proxies|separate article]] for that.
= Hypothesizing == Types of problems ===
==== Performance issues ====
Performance issues can be caused by:
** Network security restriction
** User rights restriction
* Web Service, Studio or Enterprise Service
** A manual step was forgotten (rebuilding the custom code, releasing the ACM meta definitions, restarting the web service, ...)
** Plugin code (a standard or customer plugin has a bug)
** Custom code (custom code of meta classes or the custom code library has a bug)
* Client App
** Erroneous data (unexpected values provoke the problem)
** Wrong configuration (the profile or a configuration object coming from the server is misconfigured)
** UI customizing (some XAML contains an error)
** Core implementation (the app itself has a bug)
= Inspection = Somehow, we must see what's really going on under the hood. No matter how good your hypothesis, if you can't verify or falsify it, it's no use. Even more frequently, a hypothesis is wrong and you have to come up with a better one - optimally, based on hard facts. How do we get more information about the problem? The keyword is inspection. It means, we have to look at the state of the program, as it performs critical steps in the algorithm. Basically, this means, we want to know:* When the algorithm makes a decision, which decision does it make and why?* Where is the first wrong decision made, and how does it end up in the observable erroneous state? Mostly, this means outputting the current values of variables, the current module and method at a point in the algorithm. It can also mean inspecting the input data or parameters for our algorithm to improve our hypothesis. There are the following ways to inspect the state of a {{UBIK}} system: === Inspect the mobile client ===* Use the [[Developer_Mode]] to inspect the currently visible view models and their values.* Inspect the log files of the mobile client, including the web service client log. === Inspect the web services or the Enterprise Service ===* Inspect the log files of the web service or Enterprise Service* Modify your plugin or programmatic customizing to output log message containing the state of your program at critical points* Use a Who-Bert script to test a specific setup and output log messages to the console. = SolvingFix: Performance Problems =
If you're in the technical design stage, you've already found out the reason for the performance issues. In case of a hardware or infrastructure bottle neck, you can either try to get better circumstances - or adapt to them, optimizing your solution.
Anyway, in some cases the use-case can be rearranged so the amount of data and information presented to the user at one point in time is smaller.
= SolvingFix: Crashes =
As explained in the hypothesizing section, crashes usually happen because of an unhandled exception being thrown by some module.
The real problem is either that the situation shouldn't occur in the first place or that the program cannot deal with that case; maybe it's a buggy dependency or erroneous input data.
= SolvingFix: Faulty data =
For faulty data, we have to find out where it comes from and solve the problem at its source (or as close to it as possible).
The rule of thumb here is: Don't try to cope with the faulty data when processing or showing it. Instead, fix the problem at the source and repair the data by reimporting.
= SolvingFix: Other misbehavior =
Maybe the issue is a simple typo or wrong setting and you can fix the problem with a simple measure. Since you're reading this, the solution might not be so simple and we have to approach it conceptually.
