既にDECS(Domino Enterprise Connection Services)を使って、企業の基幹システム(例えば、DB2 UDB 、DB/400)からデータを取り出す強力なアプリケーションを皆さんがお持ちであると想定してみてください。このアプリケーションでは、DECSを使い複数のフォームをモニターしています。よく使われるフォームでは2,3のDECSアクティビティーだけを利用しますが、中には21もの異なるDECSアクティビティーを使ってデータを複数のエンタープライズ・テーブルから取り出し、アプリケーションで高度なことを実現しています。

セットアップが終了すると、しばらくの間はちゃんと動きますが、しばらくするとDominoデータベースに10万以上もの文書があるために、パフォーマンス問題が問題となり始めます。この問題の解決するため、オリジナルのDominoデータベースのコピーを8つ作成して、文書を等分に分散させました。そして、各ユーザーからのアクセスに対して、ユーザーが入力したキーに基づいてマスターのアプリケーションがそれぞれのデータベースへアクセスするようにしました。こうすることで、各データベースに保持する文書数が削減され、同時にパフォーマンスも向上させることができました。

データベースが一つならば、アプリケーションのすべてのフォームを50個のDECSアクティビティーで実現することは想像できなくはありません。一つのDominoデータベースを8つに分割するので、合計で400個のDECSアクティビティーが必要になります。50個のDECSアクティビティーなら管理できなくもないですが、400個になるとそうはいきません。例えば、フォームの設計を変更したとします。その結果、21個のDECSアクティビティーに影響がでたとします。すると、全体では168もの変更が必要になってきます。ちゃんと動かすには非常に工数がかかります。

このような状況を回避するには、DECSを使ってDB2からデータを取得する方法に工夫をしなければなりません。この記事ではその一つの方法を、従業員データベースを使いながら紹介します。(管理者用コードと従業員データの入った2つのサンプル・アプリケーション・データベースをSandboxからダウンロードできます。) この記事では、読者がDECSとDominoアプリケーションの開発をよく知っていることを前提としています。

サンプルのEmployeeフォーム

5つの異なるDECSアクティビティーが入っているサンプルのEmployeeフォームを改善しながら話を進めます。この作業の目標は、従業員に関する情報のサマリーを素早く表示させることにあります。この中には、これまでの従業員に関する履歴の情報も含まれています。最初に、Dominoで表示するデータが格納されているDB2のテーブルを見て、それからそれぞれに対応するDECSアクティビティーを見ていきます。最初のDB2のテーブルはEMPLOYEESで、以下の構造になっています。

これらのものは、DominoのEmployeeフォーム(下図参照)では、それぞれEMPID、FNAME、LNAME、DEPARTMENT、DOBに対応させていきます。

上に戻る

DB2との接続定義

DECSを使用する場合、基幹システムとの接続を定義する必要があります。下図は、DB2との一般的な接続定義文書です。(テーブルやビューやプロシージャーが特に設定されていないので「一般的」と読んでいます。)

このように、一般的なDB2との接続設定を行う際に必要なものはDB2データベース接続名です。(DB2クライアントで設定されているもの)。具体的には、ユーザー名とパスワードです。接続文書をこのように作ることで、複数のアクティビティーでこの文書を共有して使うことができます。

上に戻る

従業員情報のマッピング

ここで、従業員情報とマッピングするDECSアクティビティーを作成して、DB2とDominoアプリケーション間でつながるようにします。

従業員の基本データ
最初のDECSアクティビティー「EMPLOYEES」をみてみましょう。

一方の側は、アクティビティーが監視するDominoアプリケーションです。これはDominoデータベースのファイル名です(empdata.nsf)。ファイルを選択した後で、監視するDominoアプリケーションのフォームを選択します。もう一方はLotus Connectionです。この例では、新規に作成されたDB2の接続文書(DB2 TOOLSDB)を参照しています。この接続を選択したあとで、作業を行うDB2テーブルを選択します。ここでは、DB2ADMIN.EMPLOYEESが選択されています。

ここまでの作業で、DominoとDB2双方についてどのように設定するかが分かりました。次に、DominoフォームのフィールドをDB2テーブルのカラムにマッピングする必要があります。DECSでは、ひとつ、あるいは複数のキーが必要で、それを使って、どのレコードを返してDomino文書で表示するかを決めますこの例では、Employee IDがキーです。DB2とDomino Employeeフォーム双方とも、このフィールドは、EMPIDです。

キー・マッピングが終わると、今度はRealTimeフィールドをマッピングします。このフィールド名もまた双方とも同じもので、作業がやりやすくしています。RealTimeフィールドにマッピングされているのでは、FNAME、LNAME、DOB、DEPARTMENT.です。最後に、どの文書イベントを監視する対象にするかを、このアクティビティーに対して指定します。ここでは、Openが選択されています。これは既にDECSを扱ったことのあるユーザーにとっては、すぐ分かる内容と思われます。

Salaries
次のアクティビティーに目を向けてみましょう。次は、従業員の給与情報をマップするものです。次のDB2テーブルを見てみましょう。

これらのカラムをDomino EmployeeフォームのSalaryセクションにあるBASEとBONUSフィールドに接続したいと考えています。これを行うのに、SALARIESという名称のDECSアクティビティーを作成します。このアクティビティーはデフォルト・オプションのセクションだけが入ったものですので、ここでは示しません。

Dominoアプリケーション側では、empdata.nsfとそのデータベースにあるEmployeeフォームを監視しています。(EMPLOYEESアクティビティーで行った通りです。) Lotus Connection側では、データ・ソースは再度DB2 TOOLSDBになります。この接続を選択した後で、操作を行うDB2テーブルを選択します。このアクティビティーでは、DB2ADMIN.SALARIESです。このキーはEMPLOYEESアクティビティーであるEMPIDと同じものです。このRealTimeフィールドはBASEとBONUSです。再度、モニターを行うイベントはOpenです。

業務履歴
業務履歴に関する情報もマッピングします。次のDB2テーブルを見てみましょう。ここには複数値データが入っています。複数値データとは、各アイテムにつき表示させるべきリザルト・セットが複数行あることを意味しています。

これらのDB2のカラムをDominoの複数値フィールドにマッピングします。この複数値フィールドは、DECSアクティビティーのフィールド・マッピング・セクションではBinaryとして表示されます。そして、これらのカラムをDomino EmployeeフォームのJob HistoryセクションにあるHIST_DEPARTMENT、TITLE、POSITION_CODE、START、ND、CURRENTにマッピングします。全てのフィールドがDB2テーブルでのカラム名とは必ずしも一致しないケースがここで最初にでてきましたので注意してください。

ここで、JOB_HISTORYという名称のDECSアクティビティーを作成します。

このアクティビティーでは、以前のアクティビティーと同じDominoアプリケーションを使用します。DB2側で使用されるテーブルはDB2ADMIN.JOB_HISTORYです。キー・フィールドは再度EMPIDです。同じフィールド名を持つ部分がマッピングされます。(CURRENT、END、START. TITLE、POSITION_CODE) DominoアプリケーションのHIST_DEPARTMENTフィールドはDB2テーブルのDEPARTMENTにマッピングされます。再度、モニターするイベントはOpenに設定します。Options Multi-Value Dataにある、複数値データ・フィールドの使用(Use multi-value data fields)のチェックが外れていること、またSTARTフィールドを使って降順でソートされていることに注意してください。

パフォーマンス・レビュー(業績評価)
ここで、業績評価をどのように扱うかについて見てみましょう。次のテーブルを見てください。ここでも複数値を使っています。

これはEmployeeフォームのPerformance Historyセクションの下にある、YEAR、RATING、SUMMARYの各フィールドにマッピングされます。これは、REVIEWS というDECSアクティビティーで使って実現します。

Domino側では前のアクティビティーの設定と同じです(empdata.nsfとEmployeesフォームの選択)。DB2側は、DB2ADMIN.REVIEWSを使うことが示されています。データを一致させるキーは再度EMPIDです。また、RealTimeフィールドは双方で同じ名前のフィールドを使います。(RATING、SUMMARY、YEAR) 再度モニター・イベントはOpenを指定します。
これは複数値ですので、Use Data Fields Optionにチェックを入れます。加えて、最近の情報が先に表示されるように、YEARフィールドで降順となるように設定します。SUMMARYフィールドには、Dominoで実際に見られるものより多くのデータを保持できます。これを修正するには、Post Open Eventの計算式をDECSアクティビティーに追加して、最初の60文字だけを表示するようにします。Event Optionsタブを開き、Post-Open FormulaにFIELD SUMMARY:=@left(SUMMARY;60);""を追加します。

関連性(DEPENDENTS)
最後に従業員の関連性に関する情報をマッピングします。DB2テーブルは以下の通りです。

従業員は、複数の関連性をもっていますので、複数値データとなります。この情報を格納するDominoアプリケーションのフィールドは、DEP_FNAME、DEP_LNAME、RELATION、DEP_DOBです。これらのフィールドは、EmployeesフォームのDependentsセクションにあります。 DEPENDENTSと名付けられたデータ用のDECSアクティビティーを示します。

ここに示したイラストDominoアプリケーション側のセットアップを示しています。これは先ほどのアクティビティーと同じものです。DB2側で使われるテーブルはDB2ADMIN.DEPENDANTSです。キー・フィールドは再度EMPIDです。RealTimeマッピングセクションの下には、異なる名称のフィールドがあります。Dominoのフィールド、DEP_DOB、DEP_FNAME、DEP_LNAME、RELATIONは、以下のDB2テーブルのカラムに順にマッピングされます。DOB、FNAME、LNAME、RELATION。再度、モニターするイベントはOpenです。そして複数値データの使用(Use multi-value data fields)のオプションを選択します。

上に戻る

アプリケーションの最適化

これでアプリケーションが完成しました。Dominoアプリケーションの文書を開くと、DB2テーブルに格納されたそれぞれに対応したデータが取り出され、Dominoアプリケーションのフォームの各セクションに表示されます。最初に、従業員IDと名前が来て、次いで給与、業務履歴、業績評価、関連性が並びます。

この形は最も美しい形とはいえませんが、ここで取り上げる例としては適したものです。

アクティビティー数の削減
さて、どのようにしてこのアプリケーションの設計を最適化して、必要とされるアクティビティーを削減できるかについて話をしたいと思います。Dominoアプリケーションをコピーして分割できるかもしれないことを思い出してください。この一つのフォームについて8つのコピーができることは、8つのDECSアクティビティーを管理、維持していかなければならなくなります。各アクティビティーで20のDB2への接続を行うこと許可した場合、DominoアプリケーションとDB2双方の負荷は急激に上昇することになります。

これをシンプルにする一つの方法には、DB2のストアード・プロシージャーを使うことがあげられます。ストアード・プロシージャーを使って、各テーブルから予め設定した手順でデータを取り出したリザルト・セットが返ってくるようにできます。この方法では複数値データでもそうでない場合でも利用できます。これを行うには、全てのテーブルから、全ての列を持ってきた「スーパー・テーブル」が必要になります。新たに統合したアクティビティー文書を作成し、フィールド・マッピング・セクションのフィールドを埋めます。このテーブルには、フェッチしたデータのリザルト・セットを保持します。幸いなことに、キー・フィールドであるEMPIDは全てのテーブルで共通であり、探そうとするデータをこのキーで見つけることができます。この場合、カラム名は他のテーブルでも同じである場合には、名前を変える必要があります。これと同じことは既にDominoアプリケーションのEmployeeフォームで行っています。

新たなDB2テーブル(EMPLOYEE_APP)はこのようになります。

このテーブルには、INDEXというカラムがあります。これはキー・フィールドであり、すべてがうまく動作するようにするためのものです。ストアード・プロシージャーによりデータがテーブルに入力された際に、オリジナルの各DECSアクティビティーのINDEXにはレコードに関連した値を持ちます。リザルト・セットに2つのレコードが含まれていた場合、ひとつのレコードはテーブルの最初の行に書き込まれます。2のINDEXを持ったリザルト・セットのどの列は、例えばREVIEWS DECSアクティビティーを参照します。これをメッセージとして、これらのレコードのみを見つけて、対応する複数値フィールドを埋めることができます。

以下に示すDB2のストアード・プロシージャーは、このテーブルを作成するものです。DECSのキー・フィールドであるEMPIDはこのプロシージャーにおける唯一の入力パラメーターです。

CREATE PROCEDURE DB2ADMIN.EMPLOYEE_SUMMARY (IN EMPID INT )
RESULT SETS 1
LANGUAGE SQL
P1: BEGIN
DECLARE EMPID_VAR INT;

/* This will be the cursor that we will fetch from for the result set */
DECLARE cursor1 CURSOR WITH RETURN FOR
SELECT * FROM DB2ADMIN.EMPLOYEE_APP
WHERE DB2ADMIN.EMPLOYEE_APP.EMPID = EMPID_VAR;

SET EMPID_VAR = EMPID;

/* First clean up from any previous runs */
DELETE FROM DB2ADMIN.EMPLOYEE_APP WHERE 
DB2ADMIN.EMPLOYEE_APP.EMPID = EMPID_VAR;

/* Get wanted fields from EMPLOYEES and SALARIES tables */
INSERT INTO DB2ADMIN.EMPLOYEE_APP (EMPID, INDEX, FNAME, LNAME, 
DEPARTMENT, DOB, BASE, BONUS)
SELECT DB2ADMIN.EMPLOYEES.EMPID, 0, FNAME, LNAME, DEPARTMENT, 
DOB, BASE, BONUS FROM
DB2ADMIN.EMPLOYEES, DB2ADMIN.SALARIES WHERE DB2ADMIN.EMPLOYEES.EMPID =

DB2ADMIN.SALARIES.EMPID AND DB2ADMIN.EMPLOYEES.EMPID = EMPID_VAR;

/* Get wanted multi-value fields from JOB_HISTORY table */
INSERT INTO DB2ADMIN.EMPLOYEE_APP (EMPID, INDEX, HIST_DEPARTMENT, TITLE,

POSITION_CODE, START, END, CURRENT)
SELECT DB2ADMIN.JOB_HISTORY.EMPID, 1, DEPARTMENT, TITLE, POSITION_CODE,

START, END, CURRENT FROM
DB2ADMIN.JOB_HISTORY WHERE DB2ADMIN.JOB_HISTORY.EMPID = EMPID_VAR;

/* Get wanted multi-value fields from REVIEWS table */
INSERT INTO DB2ADMIN.EMPLOYEE_APP (EMPID, INDEX, YEAR, RATING, SUMMARY)
SELECT DB2ADMIN.REVIEWS.EMPID, 2, YEAR, RATING, SUMMARY FROM
DB2ADMIN.REVIEWS WHERE DB2ADMIN.REVIEWS.EMPID = EMPID_VAR 
ORDER BY YEAR DESC;

/* Get wanted multi-value fields from DEPENDENTS table */
INSERT INTO DB2ADMIN.EMPLOYEE_APP (EMPID, INDEX, REL_FNAME, REL_LNAME,

RELATION, REL_DOB)
SELECT DB2ADMIN.DEPENDANTS.EMPID, 3, FNAME, LNAME, RELATION, DOB FROM
DB2ADMIN.DEPENDANTS WHERE DB2ADMIN.DEPENDANTS.EMPID = EMPID_VAR;

/* Finally, open the result set cursor */
OPEN cursor1;

END P1

ストアード・プロシージャーにおける潜在的な問題は、同じ従業員ID文書を同時に、別の2人が開いた場合、DB2ADMIN.EMPLOYEE_APPテーブルで競合が発生し、不整合な結果を創り出してしまうことです。これを防ぐには、Dominoアプリケーション側で文書ロックの仕組みを使います。これにより同時に一人の人物しか文書を開くことができなくなります。もっと強力な解決策としては、新規にテーブルをダイナミックに作成して、一時的にリザルトを保存することです。あるいは、ロックやセマフォを使ってアクセス制御を行う方法です。

これで、EMPLOYEE_SUMMARYという新規のDECSアクティビティーをひとつ作成できました。このアクティビティーを使って殆ど他の全ての作業を行います。

Dominoアプリケーション側はまだ、empdata.nsfとEmployeeフォームを使います。DB2側は、新たなスーパー・テーブルであるDB2ADMIN.EMPLOYEE_APPを使います。フィールド・マッピングに関して、キー・フィールドは今度もEMPIDです。RealTimeフィールドは前に使ったDECSアクティビティーのRealTimeフィールドと同じです。(全てまとめて表示されています)監視するイベントは再度Openです。(Dominoアプリケーションのフォームにある、STARTとENDを、HIST_STARTとHIST_ENDに変更したことに注意してください。詳しくは後述。) 複数値データが使用されています。

ソートが使用されていないことに注意してください。ストアード・プロシージャーの作成の段階で制御できるので、以下のコードを加えてREVIEWSのデータを選択します。REVIEWSのデータは、前のアクティビティーで複数値データをソートしています。 ソートが使用されていないことに注意してください。ストアード・プロシージャーの作成の段階で制御できるので、以下のコードを加えて、REVIEWSのデータを選択します。REVIEWSのデータは前のアクティビティーで、複数値データが格納されています。

/* Get wanted multi-value fields from REVIEWS table */
INSERT INTO DB2ADMIN.EMPLOYEE_APP (EMPID, INDEX, YEAR, RATING, SUMMARY)
SELECT DB2ADMIN.REVIEWS.EMPID, 2, YEAR, RATING, SUMMARY FROM
DB2ADMIN.REVIEWS WHERE DB2ADMIN.REVIEWS.EMPID = EMPID_VAR 
ORDER BY YEAR DESC;

Yes。DECSはソートが可能です。しかし、DB2はこれらの処理に最適化されていますので、DB2で処理を行います。そうすれば高速化できます。 DECS Event OptionタブのOpenイベントセクション・タブでは、DB2ADMIN.EMPLOYEE_APPテーブルから直接は読み込まないものを示しています。

DB2ADMIN.EMPLOYEE_SUMMARYというストアード・プロシージャーをコールします。これは前に定義したものであり、希望するリザルト・セットを返すものです。このプロシージャーはEPMIPのINPUTパラメーターが必要です。つまり、これまでやってきたようなSelectメソッドを使ってリザルト・セットを取得していた方法は使えません。代わりに、ストアード・プロシージャーを起動して、リザルト・セットを取得します。

Dataメッセージング
最初に行うデータ・メッセージングは、EMPLOYEE_SUMMARYアクティビティーのEvent Options/Openタブにあります。(前の図を参照) キー・フィールドであるEMPID以外のリザルト・セットでフェッチされた各フィールドは複数値データです。これはEMPLOYEE_APPテーブルがどのように埋められているによります。オリジナルのEMPLOYEESとSALARIESアクティビティーは一つのリザルト・セットしか返しませんでした。

これらのフィールドの中から不必要な残りの要素を消す簡単な方法を以下に示します。

@SUBSET関数はリスト・フィールドから最初の要素だけを取り出すために使われています。これは複数値データを持たない各フィールドに対して一回ずつコールされます。これらのフィールドは、FNAME、LNAME、DEPARTMENT、DOB、BASE、BONUSになります。これにより、単数値フィールドはDECSが返したリスト・フィールドの最初の要素だけを持つことになります。これは簡単な部分です。複数値データはもっと複雑な処理が必要になります。複数値データの場合は必要に応じてデータに対してメッセージを送る、より複雑なPost-Open関数の開発が必要です。これはEmployeeフォームのQueryOpenイベントでLotusScriptを使って行うとかなり楽になります。このコードはNotes 6が必要になります。Notes R5クライアントではNotesDateTime配列を同様に処理できないためです。私たちが使うコードでは、新たに配列を作成して、単一のDECSアクティビティーで前に使った単一のテーブルに対応した各INDEXで検索したものを、INDEX値として持ちます。

コードは以下の部分から始まります。

Sub Queryopen(Source As Notesuidocument, Mode As Integer, Isnewdoc As Variant,

Continue As Variant)
Dim doc As notesdocument
Set doc = source.Document

これらの配列は、必要とする既にあるフィールドのデータのみを保持するものです。

Dim tmpArray1() As String
Dim tmpArray2() As String
Dim tmpArray3() As String
Dim tmpArray4() As String

Dim tmpIntArray() As Integer

Dim tmpDateArray1() As NotesDateTime
Dim tmpDateArray2() As NotesDateTime

Dim count As Integer
Dim tmpIndex As Integer

これは、リザルト・セットで返される、実際のデータ行の数+1を示しています。

count = Ubound(doc.HIST_DEPARTMENT)

このコードは、データが取りうる最大サイズを配列が保持できるようにするものです。

Redim tmpArray1(count)
Redim tmpArray2(count)
Redim tmpArray3(count)
Redim tmpIntArray(count)
Redim tmpDateArray1(count)
Redim tmpDateArray2(count)

この行は、Job Historyアクティビティーからのフィールドを伝達する処理を行います。

tmpIndex = 0
For i = 0 To count
' We only care about records with INDEX having a 1
If(doc.INDEX(i) = 1) Then
tmpArray1(tmpIndex) = doc.HIST_DEPARTMENT(i)
tmpArray2(tmpIndex) = doc.TITLE(i)
tmpArray3(tmpIndex) = doc.POSITION_CODE(i)
tmpIntArray(tmpIndex) = doc.CURRENT(i)

' The reason that START and END became HIST_START and HIST_END
' is that they are Lotus Script key words.
Set tmpDateArray1(tmpIndex) = 
New NotesDateTime(doc.HIST_START(i))
Set tmpDateArray2(tmpIndex) = 
New NotesDateTime(doc.HIST_END(i))
tmpIndex = tmpIndex + 1
End If
Next
tmpIndex = tmpIndex -1

テンポラリーの配列のサイズの調整を行い、必要とされるサイズにします。

Redim Preserve tmpArray1(tmpIndex)
Redim Preserve tmpArray2(tmpIndex)
Redim Preserve tmpArray3(tmpIndex)
Redim Preserve tmpIntArray(tmpIndex)
Redim Preserve tmpDateArray1(tmpIndex)
Redim Preserve tmpDateArray2(tmpIndex)

新しい配列で文書内のフィールドを置き換えます。

doc.HIST_DEPARTMENT = tmpArray1
doc.TITLE = tmpArray2
doc.POSITION_CODE = tmpArray3
doc.CURRENT = tmpIntArray
doc.HIST_START = tmpDateArray1
doc.

このコードは、可能な限り最大サイズに変更して、Reviewsアクティビティーからのフィールドを伝達します。

Redim tmpArray1(count)
Redim tmpArray2(count)
Redim tmpIntArray(count)

tmpIndex = 0
For i = 0 To count
' Only records with INDEX of 2 are wanted now
If(doc.INDEX(i) = 2) Then
tmpArray1(tmpIndex) = doc.RATING(i)
tmpArray2(tmpIndex) = Left(doc.SUMMARY(i),60)
tmpIntArray(tmpIndex) = doc.YEAR(i)
tmpIndex = tmpIndex + 1
End If
Next
tmpIndex = tmpIndex -1

このラインはテンポラリーの配列を必要とされる実際のサイズに変更します。

Redim Preserve tmpArray1(tmpIndex)
Redim Preserve tmpArray2(tmpIndex)
Redim Preserve tmpIntArray(tmpIndex)

新しい配列で文書内のフィールドを置き換える必要があります。

doc.RATING = tmpArray1
doc.SUMMARY = tmpArray2
doc.YEAR = tmpIntArray

次に、可能な限り最大サイズに変更して、Dependentsアクティビティーからのフィールドを伝達します。

Redim tmpArray1(count)
Redim tmpArray2(count)
Redim tmpArray3(count)
Redim tmpDateArray1(count)

tmpIndex = 0
For i = 0 To count
' Only records with INDEX of 3 are wanted now
If(doc.INDEX(i) = 3) Then
tmpArray1(tmpIndex) = doc.DEP_FNAME(i)
tmpArray2(tmpIndex) = doc.DEP_LNAME(i)
tmpArray3(tmpIndex) = doc.RELATION(i)
Set tmpDateArray1(tmpIndex) = 
New NotesDateTime(doc.DEP_DOB(i))
tmpIndex = tmpIndex + 1
End If
Next
tmpIndex = tmpIndex -1

最後に、テンポラリーの配列を必要とされるサイズに変更します。

Redim Preserve tmpArray1(tmpIndex)
Redim Preserve tmpArray2(tmpIndex)
Redim Preserve tmpArray3(tmpIndex)
Redim Preserve tmpDateArray1(tmpIndex)

新しい配列で文書内のフィールドを置き換えます。

doc.DEP_FNAME = tmpArray1
doc.DEP_LNAME = tmpArray2
doc.RELATION = tmpArray3
doc.DEP_DOB = tmpDateArray1

' DONE!
End Sub

上に戻る

まとめ

この手法は、DECSでこれまで管理されていたDominoアプリケーション・フォームに手を加えて実現するものでした。しかし概して、Domino、Notes、DECSにかかる負担を大幅に下げ、Dominoアプリケーションについてもデータに関する作業量がこれまでよりも下がりました。加えて、複数のDominoデータベースに分散することでスケーラビリティーを向上させつつも、各データベースにつきEmployeeフォームの一つのDECSアクティビティーだけで済ませています。(本来は5つ)このように、ちょっとした創造性で処理を高速化することが出来、管理を容易にでき、かつスケーラブルにすることができることが、このアプリケーションのデモでお分かりいただけたかと思います。

参考文献

• この記事で使用したサンプル・コードがダウンロード可能です。
  
  
• "Using DB2 stored procedures with LSX, LC, LEI, and DECS" (Scott Morris著)では、DB2とDECSと他のIBM/Lotus技術を統合する方法が記されています。
  
  
• パフォーマンス・パースペクティブのコラム、"Optimizing LEI 6 performance with Virtual Documents and DB2"では、Lotus製品とDB2の統合についての深い内容が書かれています。
  
  
• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• サンプルのEmployeeフォーム
• DB2との接続定義
• 従業員情報のマッピング
• アプリケーションの最適化
• まとめ
• 参考文献
• 著者について
• コメント