Adding a device to a Netcool dashboard
Prompts that let IBM Bob add a new device to an existing Netcool Impact dashboard with exactly the same tiles, filters and selection as the devices already on it, review that change, fix what the review finds and review the fix, and, apart from that sequence, debug a fault reported on the dashboard.
The use case
The operator's dashboard is a Netcool Impact Operator View page: HTML with inline JavaScript, fed every minute by an Impact policy. It lists about twenty network devices. Each device has a checkbox that adds it to the overview counts, and three tiles, Critical, Major and Minor, that open the Event Viewer filtered on that device's alarms. Every device is also named in the page's "select all" and "unselect all" functions.
The request: Bob must be able to edit the dashboard to add a new device when one comes into service, so that the new device has the same dashboard attributes as the others. The demonstration uses mock data, since the policy and the scripts that fill the counts on the live system were not part of the package.
Why not let Bob edit the page freely
Copying a device by hand is about ten lines, and Bob gets it right most of the time. The first use case showed where it goes wrong: when Bob types new lines itself, the result varies from run to run, and nothing flags a mistake. The typical mistakes here would be invisible on the page:
- one tile keeps the old device's filter name, so it opens another device's alarms;
- the device is missing from one of the select lists, so "select all" leaves it out;
- an element id is mistyped, so its count never shows.
So the change is made by the skill, and Bob only decides what to copy and what to call it.
How it works
The same generic code-review skill as in the first use case gained one operation in its change task: a copy. Bob names the model device, the block of lines that is its row, and the other spellings of its name. A made-up example:
### copy sw1 as sw2 lines: 40-47 replace: F_SW1_ -> F_SW2_ SW1 -> SW2 why: the owner asks for the device SW2, with the same tiles, filters and selection as SW1.
The skill then:
- copies the model's block right after itself, with only those replacements;
- finds every other line of the page that names the model (the select lists) and copies each one right after itself, the same way, so the new device is wherever the model is;
- refuses the copy while it still holds any name of the model, so no tile can keep an old filter;
- refuses a new name the page already uses, so ids and filter names stay unique;
- refuses a block that is not whole, one that closes a tag it never opened or the reverse, so the layout cannot break;
- accounts in its report for every string and call it repeated, so the comparison of the two versions has nothing unexplained.
The result is the model row, character for character, under new names, and the gate proves it.
Web pages as code
The skill's scanner reads code as text in any language. In a web page it now reads only the scripts and the event attributes (onclick, onchange), keeping the line numbers of the page. On the operator's dashboard that took the scan from 110 places, almost all markup noise, to 2.
Debugging, as a task with a gate
The skill's diagnosis task used to be instructions only. It is now a command with a gate, like the others:
- Bob writes the symptom, in the reporter's words, and the names it involves;
- the skill lists every line of the code that names them, with the scan hits on those lines;
- Bob writes each possible cause with its line, a quote that must be on that line, how the line produces the symptom, and whether the evidence shows it, rules it out, or which test would decide it;
- the gate passes only when a cause is shown, or every remaining cause names the test that decides it. Nothing in the code is changed.
The prompts
A closed loop of four prompts: add, review, fix, review the fix. Prompts 3 and 4 are repeated until the review is clean; when the review finds nothing, the fix passes at once without changing anything. Debugging is a separate prompt, used whenever a fault is reported. The names in angle brackets are filled in for the device being added and the fault being reported.
Add the device <NEW DEVICE>, with DeviceType '<NEW DEVICE>', modelled on the <MODEL> device, to a copy of inputs/<page>.html under refactored/step-1-device-added: the same tiles, filters and selection, under names of its own. Write reports/add-device.md. Do not change inputs.
Review refactored/step-1-device-added against inputs/<page>.html. Write reports/code-review.md. Do not fix anything.
Every prompt has the same three parts: a first line that starts with the verb of the task (Add, Review, Diagnose, Fix) and says what and where; Write and the report; Do not and the limit. The verb tells Bob which task of the skill to run, so it starts at once.
Fix the findings of reports/code-review.md in a copy of refactored/step-1-device-added under refactored/step-2-fixed. Write reports/change-log.md. Do not decide what is the client's to decide.
Review refactored/step-2-fixed against inputs/<page>.html. Write reports/code-review-2.md. Do not fix anything.
Diagnose inputs/<page>.html: the <DEVICE> tiles open the alarms of <OTHER DEVICE> instead of those of <DEVICE>. Write reports/diagnosis.md. Do not fix anything.
Questions people ask
What if the new device is not exactly like the model?
The copy repeats the model's lines and changes only the names Bob lists. So the new device gets the model's tiles, filters and selection, and nothing else.
- A value that depends on the label, such as the margin that lines the tiles up after the label, is taken from the rows whose label has the same number of characters as the new one, and the report names those rows. If no row has a label of that length, the model's value stays and the report asks the owner.
- Anything the model does not have, such as another tile or another condition in the filter, cannot come from a copy. Bob writes it as a question for the owner; nothing is invented.
- The gate refuses a copy that still holds any name of the model, a new name the page already uses, or a block that is not whole.
The limits. The copy is checked as text. The page's own scripts, which fetch the counts and build the device filter, were not sent, so whether they pick up the new device cannot be checked here; the report asks the owner. Nothing was opened on the live system.
What does the review check, and what can it miss?
The review works in two passes:
- The comparison (done by the skill) lists every line that differs between the copy and the original page, with the strings and calls each difference adds or removes. Nothing that changed can be left out of the list, not even a lost line or a changed line ending.
- Bob judges each difference: intended (part of the request) or unintended, with the reason. It also reads the changed lines and the lines that use the same names, such as the select lists, for problems a comparison cannot show, such as a tile that still opens the model's filter.
The gate does not pass while any difference is left unjudged.
The limits. The review sees only this page. It cannot see the scripts the page loads from the server, and it does not open the page in a browser. What only the owner can confirm goes into the report as a question.
How is the cause found, and what if it is not in the page?
The diagnosis works in two passes:
- The skill lists every line that names what the symptom involves (the two devices, their tiles, their filters), with the scan's hits on those lines.
- Bob reads those lines and compares the faulty tiles with tiles that work. Each possible cause gets its line, a quote from that line, how it produces the symptom, and a status: shown (the line itself proves it), ruled out, or open, with the test that would decide it. The gate checks that every quote is on its line.
- If the cause is not in the page, because it is in a script the page loads, in the Impact policy or in the events, the diagnosis says that no cause is shown in the page and names the test that would decide it.
- If the code may be doing what its owner intended, for example a filter that covers two devices on purpose, the diagnosis asks the owner instead of calling it a bug. That is why the prompt says "Do not fix anything".
The limits. The diagnosis is a reading of the code; nothing is run.
What was checked, and the run in Bob
| Step | Result of the dry run on the operator's dashboard |
|---|---|
| Add the device | Gate passed. One copy wrote 10 lines: the new row after the model's row, and the new device in both select lists right after the model. Nothing else in the page differs. A block one line short at either end was refused with the exact reason, and every device row of the page counts as a whole block, so any of them can be the model. |
| Review the change | Gate passed. The review lists exactly the 10 added lines and the strings and calls they repeat: 14 differences, all intended. An earlier version of the review lined up the near-identical select-list lines wrongly and reported 25 false rewrites; it now keeps strings in the alignment. |
| Debug | Gate passed on a fault found in the dashboard itself: the lines that name the two devices were listed, and the cause was shown on its line. A quote that was not on its line was refused. |
| The skill | 668 automated tests pass, including new ones for the copy, the whole-block check, web pages and the diagnosis. |
The run in Bob
| Run | Result |
|---|---|
| First run | The copy was right, and Bob noticed by itself that each tile's margin follows the length of its device's label. It also showed what to tighten: the prompt's wording let the copy land in the wrong folder, a second copy block for the same device was not refused, and Bob chose a margin no other row uses. Each became a check in the skill. |
| Standardized prompts, full loop | All five gates passed at the first attempt (add, review, debug, fix, review the fix), in one new chat: 12 minutes and 15 Bob coins. The review found nothing to fix, so the fix passed in seconds with the copy unchanged, and the second review confirmed it. Earlier in the same chat, the three first prompts took about 7 minutes and 12 Bob coins. Bob picked the task from the first word of each prompt. The copy was again exactly the new row and its two select lines, with the right margin; the gate refused Bob's first, incomplete plan and named what was missing, and Bob completed it at once. The diagnosis showed the cause on the three lines of the tiles. |
| Clean run | All three gates passed at the first attempt, in one chat with nothing typed but the three prompts: about 10 minutes and 10 Bob coins. Checked by hand: the copy added exactly the new row and its two select lines, with its own filter names and the margin the page uses for labels of that length, and changed nothing else; the review listed exactly those lines; the diagnosis showed the cause on its line and left the owner's question open. |
Still to come: the counts of the new device on a live system, which need the Impact policy and the page's scripts to know its DeviceType.
Running it
- Open the dashboard's workspace folder in IBM Bob. It holds the page under
inputs/and the skill under.bob/. - Start a new chat in the built-in Agent mode and send the prompts in order, with the names filled in.
- After each prompt, Bob's command should end with
Gate: passed. Read the report it names before sending the next one.