INTJ - The Scientists

• Employee information is stored in a RDBMS as part of the HRMS. The employee ID is populated into the Domino Directory (yes it has a field for that). In an Notes application data is needed from the RDBMS. Instead of writing LCLSX code the application simply looks up the empPara document that is linked to the RDBMS using DECS. The document might not exist yet (if the user never had used that application before). If it does not exist it is created and populated just with the EmpID. When closed and reopened it will pull the employee information from the RDBMS. This is possible since the DECS task only monitors read/update. A scheduled agent removes documents when there is no more match in the Domino directory. In summary: if you can anticipate or know the primary key of a record you need, you can use DECS by not monitoring creation/deletion.
• Based on a workflow stored procedures in a Oracle database need to be triggered. Here some work both on the RDBMS and the Domino side was done, clearly separating both. An auxiliary table was created in Oracle with an INSERT trigger, that would execute the stored procedure using parameters given in that table and write back the success of the operation. Initially it was planned to purge the table regularly (using a Domino agent deleting the documents) but then audit loved the additional documentation, so just archival was established. During the project there were a lot of changes on both ends, however the approach of using a trigger driven table proved to be very efficient to separate the two environments minimizing interference. E.g. one stored procedure would generate a unique identifier according to some obscure, constantly changing rule. By storing that result into the aux table and creating (after reading the document linked to that table) a corresponding Notes document (again create was not monitored in that scenario) application flow was seamless.
• Enterprise parameter management [Updated] was created in a RDBMS application. Many Domino applications would need to use these parameters. Instead of having LotusScript code in every application doing RDBMS lookups DECS was used to populate and update a parameter NSF. In the activity the option "leave values in documents" was selected, so fast selections (like @DBColumn or NotesView.getColumnValues) would work. Since parameter changes happened rarely a copy of the populate keys agent from the DECSAdm database was created that would periodically shut down the activity for the parameter NSF (only the activity not the whole DECS server), pull the keys from the RDBMS based on the activity definition but only insert new keys (the original agent duplicates keys when you run it twice). Lastly it restarts the activities in DECS.

• You have retained your Notes clients: Don't do anything. Connect your other eMail system to the Domino system using SMTP and the SMTP router of Domino will convert the DocLink into a hyperlink using the notes:// protocol. Of course I presume you have configured your Domino server properly (hostname anyone). If your user typically use local replicated databases the links created will point to local databases using notes:///. That can be a problem if the receiving end doesn't use a local replica. In such cases use Geniisoft's CoexLinks.
• You web enable your application using the Domino http task (classic or XPages alike): you either need to touch all your applications and replace @MailSend/NotesDocument.send or use Geniisoft's CoexLinks. CoexLinks is an unobtrusive server tasks that does link conversion. It also takes care if users on Lotus Notes send you a DocLink. And NO. There is no magic button for web enablement. Depending on the code quality and structure of your applications it can be very easy or a little painful. See my session at Lotusphere to see what could be automated.
• Your messages use stored forms and that forms contain actions and buttons and the like: Sorry. You need to rework these parts.

• Replication: This is the clear choice for email and informational databases like document libraries, discussions, team rooms etc. The clear advantage: while you do other things the background replication task makes sure all information reaches your desktop. It also has the clear advantage of data being available off-line. Replication is less suitable for applications where you actually only need a small subset of the whole data (typically in workflow applications) or where data transmission is very expensive. You can tweak replication settings to accommodate that. E.g. in the location "Expensive" you only receive your email (and other) database(s) while in the location Internet all is replicated (The sending of new messages is handled by the router, so it will go out). You also can limit the amount of information replicated. (See your admin help for details)
• Mail routing: In workflow applications when requesting action or approval is is usual to just send an email with a link to the workflow document. For low bandwidth situation that could be changed to send a whole form that includes the action buttons. That form could be made part of the mail design (if it is generic enough) or could be send using "Store form in document". A decision maker would get the entire information in the inbox and can click the button (which would trigger a return mail to the mail-in enabled main application. The mail is stored there as documentation and the main document is updated.
• Forms Bin: This is the "other" end of the Mail routing concept. A central database contains all the forms for all the workflow application used by bandwidth challenged users and the look-up configuration as far as possible. This database gets copied onto the workstation (either when they are in good network condition or via CD-ROM). Users fill out forms there, but the forms don't get stored in the forms bin but get emailed to a mail-in database that is the main application. You could add a non-replicating "personal bin" to keep local copies. This way only documents that are relevant to the user are transmitted. The forms bin replicates (probably receive ony), so updates to the forms, form removals or new forms are properly reflected.
• Feed enablement: To get an overview on what is happening, what action is required pulling a summary through RSS into your favorite reader. While that is a read-only approach it might fit a lot of needs. Since Domino 702 there is a feed wizzard, that can generate feeds without touching your existing application. Of course you can take a peek into IBM's and Botstation and Instant Tech provide libraries for LotusScript. Works great on mobile devices too.
• MQ Enablement: This is a variation of the Forms Bin approach. Using the Expeditor Framework in the Notes8 client you can use MQ to send the data (with a little work - sample on request) it works on R6/R7 clients too. Advantage here: you application doesn't need to worry about on-line/off-line and the data transmitted is very small. Disadvantage: you need to get used to MQ (an obviously install it)
• Web enablement: Since 4.x it has been possible to render Notes form in the browser. There is a large body of knowledge out there how to do that. Of course you want to be very light for challenged bandwidth, add compression or use XPages which does a lot of optimization for you (you want to use Firefox for its better handling of JavaScript caching)