For fast and efficient troubleshooting fairly detailed information is needed. Here's the basic list of information that an adopter should always consider when calling Paul or sending an email (See the more detailed Defect Ticket Checklist for logging a ticket):
- A short description of the problem. Example: Query builder page will not submit a query. Pressing the submit button and the browser stays on the builder page.
- The URL of the page that has the issue.
- A description of ALL the steps you perform/needed to reproduce the problem.
- A description of what you'd expect to see/happen.
- Screenshots of each step/selections and resulting page.
- How widespread is the issue? E.g. does the problem happen for other like requests or only this one(s)? If so which ones have the issue?
Items that may help/be applicable:
- Screenshots or descriptions of the browser's console error window, the IBIS error page, log files that show a Java exception etc.
- Screenshots of working code and what it should look like.
- What version of the IBIS software are you running?
- Are the content files checked into the repository? If so what version?
- What browser and browser version are you running?
- If the request is a secure type request then What user? What privs does that user have?
The quickest and easiest way is to pick up the phone and call Paul Leo and walk him through the above items. If after hours or you want to send an email or you want to log a ticket then all of the above information should be included and anything else that you feel can be helpful.
IMPORTANT: Each adopter should have an idea of the priority of resolving the issue. Each adopter MUST consider and manage the amount of hours that the support person can and should work on the issue. When the adopter contacts Paul Leo, they should ask Paul how many hours they have left on their support contract. Paul can then look up the available hours and the adopter and Paul can then discuss and limit the amount of time to be spent. It is up to the support person to determine work load and schedule.
BASIC STEPS FOR TROUBLESHOOTING A QUERY
Many issues are query related. To troubleshoot this type of an issue try and determine where the issue is by following these basic steps:
- Using the query builder interface build the query definition and submit it.
- Use the result page's "View XML" to see the query module XML.
- Locate the IBISQ query result XML (the backend SAS IBIS query system). This is done by searching for an element named "IBISQ_QUERY_RESULT".
- Inspect the elements and check for:
- An ERROR element (QUERY_MODULE/IBIS-Q_QUERY_RESULT/ERROR or QUERY_MODULE/REQUEST/ERROR). If it exists read the details for clues as to what the issue may be.
- The IBISQ RECORDS/RECORD elements and see if they represent the data that was requested (if no ERROR).
If the expected data records exist but the view system does not display them correctly then this is potentially a view webapp issue. If the data is not there or there is an error element then this is likely a backend IBISQ issue - continue to follow the next steps.
- Within the XML locate the REQUEST URL by searching from the top of the file for: "QUERY_APPLICATION_URL".
- Run this URL directly to IBISQ without using the view webapp by copying the URL and pasting into your browser's address text input.
- You should see a subset of the query module's XML that is the same as the IBISQ_QUERY_RESULT element.
- Try to determine what the backend IBISQ/SAS issue is by turning on the various IBISQ debug params via the request URL. These are HTTP request name/value pair parameters that are simply appended/modified to the request URL. The parameter names and values are found in the system documentation and/or by asking Tong or ZW. Here's a partial list:
sas: 0, 1, or 2. 1 = returns the actual SAS program generated/used. 2 = returns the SAS log file.
test: 0, 1, 2, 4.
debug: Empty, 0, 1, true, false, yes, no, x.
func: 1, 2, 3, 4.