Extending AbstractTextFileAnalyzerDataSource Implement RiskAnalyzerDataSource

23-2 Oracle Fusion Middleware Developers Guide for Oracle Adaptive Access Manager

23.1.2 Divide and Conquer

Steps to reduce the problem to a manageable issue are listed in this section.

23.1.3 Rigorous Analysis

All or part of the process should be applied if: ■ a problem is complex ■ a problem is highly escalated ■ a problem was not solved with the first attempts Intuitive leap or guess The problem just inspires a guess at a cause. You have a feel for the problem or rather its cause. This can be very effective and result in a quick resolution, but without proper confirmation, it often leads to the symptom being fixed and not the real cause being resolved. Review basic diagnostics Check the logs for errors and the flow. Check flow HTTP headers, network packet trace, SQL trace, strace. Run through and document the flow. Cross check with configuration details to ensure flow is expected. Read the error message Reading the error and the flow information will give a big clue. Taken together with some knowledge of the way the component works, this can give a lot of insight. Always check knowledge Oracle and search engine for matches. Perform any diagnostics needed to establish if the error is key. With multiple errors, look to see which is likely the cause and which are just consequences. Compare Compare the logs and flows with a working system. Perform a test case. If it happens only at a certain site, then compare the differences. Divide Break the problem down Process Description Simplify the problem Make a problem as simple as possible. Remove components that are not needed Most problems involve complex components and connections between them. Most involve third party components. So where ever possible, eliminate third party components first and then as many components and custom components as possible for example, command line not application, SQLPLUS is not an application.? Reduce complexity Test to see if a simpler version of the problem exists with the same symptoms. for example, remove components of a complex Select, or a search filter, check if a single request or few requests will suffice?. Like fixing an underground pipe with a leak Imagine a complex configuration as being a underground hose pipe with a leak. You know something is wrong, there is a leak someplace, but not where it is. List the components Draw a box for each components and a line where it is connected to the next. Note the protocols used to join them. Check both ends What goes in should come out the same. If you see data in and out results in a problem then it is one of the ends that is wrong. If the flow is not as expected the problem is in between. Lazy Y Test points in the configuration to find where the deviation occurs. Once established beyond doubt that a piece of the configuration behaves as expected it can be ignored. Repeat Repeat this loop to close in on the problem Help When 3rd party components are involved in the issue, get help from the others and work on the issue together. Steps Description FAQTroubleshooting 23-3 ■ a problem is getting out of control ■ a problem has potential for getting out of control

23.1.4 Process Flow of Analysis

The process flow of analysis is presented below: 1. State the problem. 2. Specify the problem. Develop possible causes from: a. Knowledge and experience b. Distinctions and changes 3. Test possible causes against the specification. 4. Determine most probable cause. 5. Verify the solution.

23.1.4.1 State the Problem

Stating the problem is the most important step to solving the issue.

23.1.4.2 Specify the Problem

Describe problems in detail and ask focused questions to gather pertinent information. Step Description Ensure a clear and concise problem statement Stating the problem is the most important step. It is the most commonly ignored or at least the problem statement is assumed. It is pointless trying to solve a problem until the problem statement is stated. Otherwise what are you actually trying to fix? If you do not know what it is you are fixing how can you fix it? Consider if the problem stated can be explained If so, then it is not the problem statement --If the problem statement can be explained then back up and try and get a more correct problem statement. This is a case to start communicating if you are helping someone solve his problem. Either ask some direct questions to narrow down the issue or just pick up the telephone and talk to the person to clarify the real issue. If there are lots of issues then start noting them down as separate issues. Do not settle for a vague statement Vague problem statements, like bad performance, something crashes are of no use and commonly are the cause for issues to be long running and out of control. Never combine problems in a single statement Ensure there is only one problem being dealt with. Do not accept combined problems. The combined problem is either multiple distinct problems or some of the problems are actually symptoms. Step Description Specify the problem These are symptoms of the problem. Start by asking questions Ask questions such as What, Where, When, and to what Extent? What? What tends to be the obvious question and is mostly a list of facts and symptoms; what deviated from the expectation? Where? Where may or may not be relevant, but is worth asking as it is often significant and often overlooked.