Captain Oblivious

I thought the code was boring, so I left it out. Turns out, there is at least one person who wanted to see it (say hello to the nice people, Donovan!). I almost always think my code is boring (honestly, if I can come up with it, the rest of you certainly can), but maybe I ought to learn a lesson from Donovan's question and simply post it anyway.

In this case, I was looking up results from various databases in our environment to produce, well, this:

Welcome, Rob McDonagh

There are 4 support calls in your queue.
Your travel expense request has been rejected with a request for additional information.
The minutes from the 12/17 meeting on the Blackberry project are waiting for your approval.
There are no system wide alert messages.

To begin with, the font and color of the text are controlled, in my systems, by the text properties of the computed text. As for the details, starting at the top, the text "Welcome, " is immediately followed by computed text with this formula:

@Name([CN];@UserName)

No surprise there - makes sense, right? I suppose you could simply put the text inside the formula, but in this case I didn't. Doesn't really matter.

The next line in this example indicates whether you have any support calls in your queue. The specific formula wraps a basic @DBLookup inside an @Elements, and then displays an appropriate message based on the result:

val:=@DbLookup("":"NoCache";"":"HelpDesk.nsf";"CallsByTech";@UserName;1);
checkVal:=@If(@IsError(val);"";val);
count:=@Elements(checkVal);
@If(count=0;"You have no open support calls in your queue."; count>1;"There are " + count + " support calls in your queue.";"There is 1 support call in your queue.")

I think the logic there is straightforward.

The following example is a bit more complicated. It looks for workflow requests in a central workflow database. This particular system expects users to acknowledge workflow states. For example, when a request is approved, the initiator is supposed to confirm that they know it was approved. The result is that there is a lookup view in this database containing all active workflow requests - those the owner has not acknowledged yet. There is also a view containing relevant information about these requests in a concatenated format (so, RequestType~!Status~!Reason.....). The example I gave lists only one request for this user, but the formula in question handles multiple items:

statusVal:=@DbLookup("":"NoCache";"":"TravelExpense.nsf";"ActiveRequestsByUserConcat";@UserName;2);
checkVal:=@If(@IsError(statusVal);"";statusVal);
count:=@Elements(checkVal);
@For(n := 1;n <= count; n := n+1;
status:=@Word(checkVal[n];"~!";2);
concat := @NewLine + "Your " + @Word(checkVal[n];"~!";1) + " has been " + @If(status="1";"approved.";"rejected with a request for " + @Word(checkVal[n];"~!";3) + "."));
concat

Typical results might look like:

Your travel expense request has been rejected with a request for additional information.
Your performance appraisal has been approved.
Your training request has been approved.

So, what I'm doing is grabbing a list of concatenated strings describing workflow requests, iterating through that list, pulling out the values using @Word to parse the string, and generating a line of html (mostly text, really) for each. I use the new looping constructs in Notes/Domino 6, though I'm quite sure there are formula language wizards who could tell you how to do it in R3. Oh, and I left out the link again - I do insert the html for a link to the relevant Notes document. But that's no different than inserting the text itself, so I think we can skip it. If anybody wants to see it, though, toss in a comment and I'll post the slightly longer and harder to read formula I use.

The next line is fundamentally the same. There is a central project management notification system that indicates what actions are pending for each employee. When an employee resolves a pending action, the notification is removed. In the specific example I used, there are minutes from a meeting that this user is supposed to approve. There could have been a weekly project update due, or an open issue to resolve. In each case, there would be a line on the welcome page describing (and linking to) the source of the notification. Other than the name of the database and view, and the specific values in the concatenated string, the formula is identical.

Finally, the line indicating whether there are any system alert messages is very much like the first example, the support call queue. There is a database that contains alert messages, in the case that a system is down for repairs. If there are any alerts, the welcome page indicates how many there are. I could have it display a brief description of each alert as well, looping through them as above. In this case, most of our alerts are network-related, and so people mainly want to know: "Is there an issue?" If we commonly had a wider variety of alerts, I would probably display each alert's summary on the welcome page.

So there you have it. My specific examples rely on the presence of lookup views in the systems in question, so if you don't control those systems things are certainly more difficult. There are really only 2 unique code techniques used on this page, and I think those two cover every welcome page message I've ever written. I'm sure some of you can come up with others, though.

Note: it's entirely possible there are bugs or typos in this code, as I'm writing it from memory at home. I know how it works, but I don't have access to the databases in question right now so there may be syntax or possibly even logic errors. It's also absolutely certain that there are more efficient and/or more elegant ways to obtain this information. I will eagerly welcome any tips on how to improve this code, of course. Just don't expect me to be surprised that it isn't perfect. *grin*

Technorati Tag: Show-n-Tell Thursday