IBM Lotus Software
Total Page:16
File Type:pdf, Size:1020Kb
AD210 Application Development and Deployment for DB2-Enabled IBM Lotus Domino Server John Curtis Tom McGary IBM Software Group Agenda DEMO – “The OmniLink View” Basic IBM Domino/DB2 Enablement, with DB2 Access Views System Configuration Planning Application/Data Planning Creating DB2 Access Views and Query Views Query View Complexity and Design Filtering Function Library Overview Opening remote documents DEMO – “The Ultimate Inbox” DEMO The OmniLink View Content Disclaimers NOT a substitute for really learning DB2 SQL IBM DB2 SQL Workshop and DB2 SQL for Experienced Users http://www- 304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_descripti on&courseCode=CF120 http://www- 304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&c ourseCode=CF131 Publications: SQL Reference Volumes 1 and 2 (SC09-4844-00 and SC09-4845-00) Content Disclaimers (continued) NOT a substitute for really learning DB2 Administration/Tuning IBM DB2 Universal Database Administration Workshop for Windows/UNIX http://www- 304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=course_description&co urseCode=CF231 DB2 UDB Performance Tuning and Monitoring Workshop http://www- 304.ibm.com/jct03001c/services/learning/ites.wss?pageType=course_description&courseC ode=CF412&country=us&language=en Publications: Administration Guide: Implementation (SC09- 4820-00), Administration Guide: Performance (SC09-4821-00) and System Monitor Guide and Reference (SC09-4847-00) Online documentation: http://publib.boulder.ibm.com/infocenter/db2help/index.jsp Terminology/Acronyms DAVs or DB2 Access Views - Mechanism (DB2 View) to expose Domino data to the outside, relational world QVs or Query Views - Mechanism (Domino View) for rendering relational data using Domino views DAVPOP or DB2 Access View populator – Domino process to initialize DAVs with Domino data Federation – incorporating data from multiple sources into a central composite 2 types Domino database federation – JOINs/UNIONs across different NSFs (well, DB2NSFs) DB2 federation – pulling in data from foreign relational stores (other DB2 instances or Oracle, etc) Domino/DB2 and DB2 Access View Enablement Attend Session ID105 for more detail Setting up IBM Domino Server for DB2 Essentially, follow the directions For DB2 Access, remember to create the id file first Read documentation carefully, follow to the letter DB2 Access View Setup Use default DB2UserID for QVs if possible Keeps DB2 superuser credentials from normal QV use Application Planning Discovering Hybrid Applications - Questions What portions of corporate relational data are the most valuable to participate in Domino applications? Reduce redundancy (Re)organize presentation Enrich content, etc. Ease of implementation important (e.g. ETL is costly) What Domino databases easily “join” to present data never seen together before? What portions of Domino data are the most valuable to participate in relational applications (not covered this session) Which applications would benefit most from having Messaging/discussion/workflow data in relational form? Application Planning (continued) More Questions: What new applications are implied by the Domino/relational melding? Messaging reports, document access from outside Domino What transformation/design modification would best enable hybrid applications? Join keys, name field standardization, data uniformity HOW WELL DO YOU KNOW YOUR DATA? From Domino - Items, Forms, Views From Relational – databases, tables, columns, applications Configuration Planning Server Configuration Will DB2 run on the same (local) or different (remote) server? Advantages of DB2 on a dedicated server 64-bit memory support Disk configuration Separate tuning and administration Possible consolidation of multiple Domino servers onto a single DB2 server Will non-Domino relational data be part of the application? If yes, where will it reside and how will it be accessed? Remote access (that is, to another RDBMS) needs planning and configuration Materialized Query Tables (MQTs) – temporary local copies of relational data kept up to date automatically Configuration Planning Application Data planning How much processing will be done on the DB2/Domino Server? Full blown databases – allow for complete processing on the Domino/DB2 server Skeleton replicas (one way – in) Keep only the fields necessary to render Query View(s) Since remote documents can be opened, this is all you may need Savings are at least 95% in disk Enables consolidation of many database for highly federated QVs Interface is laborious (working on it) Configuration Planning (continued) How much processing will be done on the DB2/Domino Server (continued)? Query View – only databases Good for developing Query Views apart from production data Allow for independent (from data) access control Domain issues Repetitive work – exporting DAVs and QVs across the enterprise Creating the Design Objects DB2 Access Views What they are: Mechanism to expose Domino data to the outside, relational world Updatable DB2 Views (functionally equivalent in SQL to tables), with one row per document where rows contain Copies of selected Domino document fields, available in relational form Security information (e.g. $Readers) Domino system/navigational data (#noteid, #unid, #modified) Creating the Design Objects (continued) DB2 Access Views (continued) How they work User Defined Function (UDF) executes for every SQL statement Checks Domino privileges at database and document level Passes through SQL to DB2 Populated in DAVPOP – batch process making copies Maintained under normal NSF core updating API calls Overhead Disk footprint – even with indexes, 3% is the most measured Update costs – 8-12% extra time (wallclock) Creating the Design Objects (continued) DB2 Access Views (continued) Form-based vs. All forms – updating consideration Small cost to make form a DB2 column to add to WHERE clause Fewer DAVs = less updating/fewer objects If only one form is of interest, save space and map its documents only Including extra fields Always included #noteid, $Readers Unless you have a reason not to, include these GMT Conversion – makes date math very straightforward Creating the Design Objects (continued) DB2 Access Views (continued) Choosing columns – be thorough but judicious Know your data or you will learn about it as you go Plan for federation in advance (JOINs, UNIONs, etc.) Error avoidance/data mapping Truncation Lists and ranges vs. single occurrences Strong data typing – clean up multi-typed Domino fields Creating the Design Objects (continued) DB2 Access Views (continued) DAVPOP Debugging problems – need mechanism to get documents by NoteID Check lengths, types and occurrences Ongoing criteria enforcement – if you had problems populating, problematic data may get replicated in again Creating the Design Objects (continued) Query Views What they are Mechanism for rendering relational data using Domino views Temporary SQL query results No persistent footprint in Domino Solution for Domino view explosion Document-backed Aggregate, report data Combination How they work Map SQL query column values to Domino view columns Every time the QV is opened, it rebuilds, firing the SQL query The SQL query can be different each time Creating the Design Objects (continued) Query Views (continued) Choosing view columns – As usual in view design, but consider multiple sources and shapes of data E.g. a federated “subject” or “author” column Less is better (use SQL to your advantage) Categories and responses supported, multi-value permutation works via Lotusscript Explode Selection criteria (WHERE clause) Can be specified at runtime More restrictions are better than fewer Common restrictions (e.g. form = ‘Memo’) can be supplied via additional DB2 views ORDER BY Overridden by any Domino View column collation Useful in UNION (ALL) selects Creating the Design Objects (continued) Query Views (continued) Implicit columns (mentioned under DAVs, part of why you want them:) #noteid – for opening federated documents #oid – to support @ functions like @Created #unid – to support app calls using UniversalID Non-Domino data will not have these, but via JOINs these can be supplied e.g. – to open a Domino-resident description document from a view with relational-based manufacturing parts: SELECT a.cost, a.partno, a.partdesc, a.supplier, B.#noteid FROM corporate.parts a LEFT OUTER JOIN dom.description b ON a.partno = b.partno Creating the Design Objects (continued) Query Views (continued) SQL selection SQL columns are mapped to view columns based upon column value (type formula) = SQL column name The SQL “AS” clause projects any name to be mapped across any SQL table (e.g. SELECT rtrim(doctype) AS type FROM table) Column Construction can get ornate: SELECT lastname || ‘, ‘ || firstname || ‘ phone: ‘ || phone AS contact Query View Complexity and Design Simple Query Views Self contained, where document data in this database (i.e. using its DAV(s) only) can be: Filtered Reformatted Re-categorized Most common uses: Replace/augment existing views Replaced views create savings by eliminating update/updall processing New reports Query View Complexity and Design (continued) Complex Query Views Query references data in this database (using its DAV(s)) and at least one other source (either another DAV or relational table) Use JOIN or UNION Simplest – adding column(s) to the SELECT list: SELECT a.#noteid, a.from AS FROM,