【XPagesDy】A-2_コムチュア_20131106_公開用

【A-2】
NotesDB の
XPages 移行事例とそのポイント
XPagesDay 2013
2013年11月6日

コムチュア株式会社
グループウェアソリューション本部
グループウェアソリューション第２部

高橋
Copyright (C) 2008 COMTURE CORPORATION. All rights reserved.

歩

はじめに

■今日お話ししたいこと
• NotesDBのXPages化は新規のXPagesアプリ開発より
リスク「高」
• 「リスクポイント」を抑えて、トラブルを軽減
• 当社が経験からの「ポイント」

Web2.0 Powered by
Domino XPages

2

Notes資産をWeb化する理由
• NotesDBの資産を継続して利用したい
• 他社製品への移行も検討したが費用が高い
• Notesクライアントでの運用は端末へのインストールが
必要となるためやめたい
• 自分の端末以外でも自分の権限でアプリケーションを操
作したい
• IDファイルの管理をやめたい
等々
3

NotesDBをWeb化する

XPagesという選択肢
■Web開発技術 XPages
• IBM Domino8.5からのWeb開発技術
• Web2.0ベースアプリケーションを実現
• WYSIWYGで効率化開発が可能
• JavaServer Facesをベース技術に採用

4

簡単にNotesDBをXPagesに置き換えられるのか？
いろいろ言われていますが

そんなことはありません。
（現状では）

■「移行」時の懸念点
■アプリのメンテナンス性
■Dojo Toolkit
5

XPages以外の方法を考えてみる

XPagesが最適です。
■他社製品への移行
・「運用」まで含めた検討が困難
■XPagesが持つ多種多様な機能
・既存NotesDBを利用
・いままでのNotesのWeb化ではできなかった
機能の実現

工夫により資産を生かした
効率的なWeb化が可能

6

XPages化のトラブルを軽減するために

当社の経験をお話します
■NotesDBをXPages化するポイント
①Webアプリにすることによる「意味」を明確に
②NotesDB→XPagesにするときの「くせ」を把握
③効率的に開発するための手法
④XPages化した後の運用を意識

トラブルを軽減

運用
開発

開発
運用

プロジェクトの成功へ
7


NotesDBをXPages化するポイント



8

プロジェクト開始理由
■ Web化にするための様々な理由
・iNotesメールの利用に合わせてアプリもWeb化へ
・ポータルのポートレット
・社外からアプリを利用
・モバイルからアプリを利用
・Notesクライアントライセンス削減による
ライセンスコストの削減
and so on....

各社それぞれのビジョン

9

はじめに意識すること
■ 目的を逆転させない
・Web化は最終目的のための「手段」
・NotesクライアントでできることをWeb化するのでは
なく、Web化することで「何ができるようになる」の
かを考える
■ 認識を共有する
・プロジェクトに関わる「すべてのメンバ」で共有
・お客様の社内でも共有

10

なぜならば

Notesクライアント＞＞ Webアプリ
■Notesクライアントの全機能のWeb化は不可能
■アプリ単位の機能で評価ではなく、全体のワーク
スタイルを含めた「Web化の評価」が必要

「Notesクライアント」でできること

Web化することで
「何ができるようになる」のか

11




12

開発フェーズでの問題点

• 製品不具合
• 仕様（ NotesオブジェクトとJavaの概念）
• プログラムの「作り込み度合」のバランス

データロストの危険性！！
具体的にどのような「くせ」に
直面してきたかをご説明します
※当時はND853

13

当たり前のことが「当たり前でない」
• 日付・時刻フィールド≠日時フィールド
– Java（XPages）の世界は日時型
– 日付だけ、時刻だけとかは存在しない
– じゃあ、Notesの日付型ってどうなるの？
• XPagesで保存すると日付がずれます（常にGMT）
– PA問合せの結果仕様との回答あり（当時）
– その後FP等で修正された

？
14

最大の難関「リッチテキストフィールド型」
•
•
•
•

リッチな本文情報＋添付ファイル
フォント設定/リンク挿入
任意の場所に「画像も直接張り付きます」
任意の場所に「添付ファイルも貼り付きます」

Notesならではの
便利なデータ型
15

難関理由

NotesとXPagesの型の差異
• リッチテキストフィールド→MIME型
• リッチテキストフィールド→リッチテキスト型
–
–
–
–
–

本文設定するとMIME型
ファイルだけ貼るとリッチテキスト型
文字とファイルを添付するとMIME型
何も添付も入力もせずに保存したら・・・？
テキスト型のアイテムを表示すると？（昔テキストフィールド）

16

リッチテキストフィールドの逃げ道
• 本文レイアウトとファイル添付を別々のリッチテキスト
フィールドで実装していればほぼ大丈夫
– 新規アプリでリッチテキストフィールドが問題にならない理由の
１つ

• Notesの開発はたいてい「１フィールドに本文とリッチ」
– データにファイルが添付されていると分離も困難

• プログラムで操作をすると即エラー
– リッチテキスト操作をプログラムで対応することは避ける
ファイルエリアと本文エリアが分かれている
ほうが安全

17

対応したリッチ障害
• CK Editor
– 1画面に2つおいて、画像挿入ボタン押下でエラー
– OS、CK EditorVer、DominoVerによって発生有無あり

• Notesで作成した文書をCK Editorで保存すると

本文が消える

– Notesの余白設定が問題
– 文書リンク貼ると余白は自動設定される

• 同じファイル名をアップロードすると文書に同名でアッ
プロードされる
– 削除できない
18

まだまだある
• ファイルダウンローダに表示される「更新日」は何の更新日？

• ファイルダウンローダに表示される「ごみ箱」アイコンが参照
時でも表示される
• リッチテキストフィールドに初期式が入っているとファイルが添
付されているのか、されていないのかわからない

• 文書リンクが開かない
• 保存するとリッチテキストの一番始めの空白が消える

19

まだまだまだある
• 同名ファイルをアップロード後のナンバリング対応が適当

• 同名ファイルを39個添付でHTTPタスクダウン
• ファイル名に半角ブラケット（[ ]）が入っているとファイルが
３つに増殖する

さらに・・・
• NotesWeb（FormWeb）のアプリからXPagesへの移行は、
Notes→XPagesよりも「1.5」倍困難
※当社実績値より

20

リッチ以外にも気を付ける点
• 「30」制限
– 添付ファイルの表示数（ファイルダウンロード）
– ビューの表示行数
– 繰り返しコントロールの繰り返し数

• 全角英数字はNG
– Designer画面ではわかりづらい
– 英数字は半角Only
– 全角英数字フィールドがある場合は「データ変換」

・・・・等々

21

このような状態を解決するために

XPagesの「くせ」に
対抗するためには・・・
• メーカ：PA・技術サポート＆Hotfix
• ベンダ：障害特定・HF検証・回避PG
• お客様：運用回避

「運用影響を最も低く」
を考える

22

XPagesの「くせ」に対応中は

障害管理・Hotfix管理は大切
– お客様社内での情報共有、ベンダのPJ管理
– IBMとの共有

23




24

開発において

最重要ポイント

「部品化」
• 品質の安定
• 開発効率の向上
• メンテナンスの簡易化
25

部品化の重要性
•
•
•
•
•

開発物のアプリ数は多い
全ての開発者が高スキルを持っているとは限らない
XPages開発者はとても少ない
Notes開発者は多くはない
XPages＝GUI？・・標準だけでは「部品化には遠い」

XPagesだからこそ
部品化が求められます
26

どんな部品？

効率アップする「部品」とは
• 誰にでも、簡単
– 使いやすいことが必要

• できるだけ標準
– Hotfix適用/Dominoバージョンアップに対応
– 誰でも部品の中身を解析可能

• 標準で不足する部分はツールを活用
– Java/Extension Libraryの利用（なくても「動く」こと）

• 部品のバージョンアップは随時可能な設計
27

部品をうまくつかうために
• 全体判断は「部品」で実施
– プロジェクトでのXPages化可否判定はすべて「部品」で行う
– 各アプリ開発担当は開発に集中

• 「部品」のアップデート時は「既に開発したXPagesアプ
リ」に影響が発生しないように
– 部品のアップデートは積極的に！
– 部品のデグレ→各アプリの障害に

28

部品をつくるためには
• 部品開発にはある程度の技術スキルが必要

• 部品開発には「コミュニケーション」が必須

「くせ」への対応と「部品」で

開発課題をクリア！
29




30

XPagesリリース後

ここからが最大の

「山場」
を迎えます
31

なぜならば

エンドユーザ様の厳しいご意見
• 「イメージ」が違う

• 「○○」ができない
• 「使いづらい」
• 「遅い！」
• 「Notes」がよかった

「山」から転げ落ちてしまう場合も
32

そうなる前に

プロジェクト開始時点からの
「準備」が重要
• お客様：エンドユーザへの展開設計
受入テストシナリオ設計
• ベンダ：お客様サポート、説明会シナリオ作成

33

リリースに向かってお客様・ベンダが行うこと
• リリース前に説明会
– なぜWeb化するのか、Web化するとこのように変わる、という
デモ
– 仕様制限等は資料化して展開
– F to F での説明

• 「試金石」となるアプリを先行リリースで代用
– 見た目・操作に慣れるためのDB
– 全社共通掲示板等、簡単で全ユーザが利用するDBが理想

• 開発部隊、お客様フォロー部隊（SE）を分ける
– 開発を一定の進度で進めるためには役割分担が重要
34

リリース後の運用を考える
Notesアプリ環境はEUCで誰でも作れる
管理者がアプリの利用頻度を把握できない
管理者がアプリの個数を把握できない
DBの削除によりクラスタレプリカが失敗する

Web化後は

運用の変更が必要
35

Web化後の運用は

例えば
• 管理者承認のもとアプリを作成する
• アプリ開発部門を集約する
• 定期的にアプリの棚卸を行う
• 必ず「部品」を使ってXPages開発を行う

運用の設計はリリースまでに実施
36

継続的な資産の活用へ

XPages化を継続することで
資産の有効活用が可能に
プロジェクトの目的の達成

「ユーザ満足度」へ
37

移行のまとめ
• 製品不具合・仕様との対決
– NotesのデータをXPagesで利用する「くせ」
– 障害を切り分ける「知識」

• Notesクライアントは便利
– NotesクライアントをXPages化しない

• アプリリリース後、半年は勝負です
– 運用がどこまで浸透するか

38

さいごに

マイグレ以外のXPagesは？

「有り！」

• 「All In One」基盤
–
–
–
–

高度なセキュリティ、ユーザ管理等単体で総合環境を提供
Web開発環境もDominoサーバ内部で完結
文書型データ構造により高いメンテナンス性を維持
OneUI、標準コントロール、OpenNTF等提供されるツールによ
り「きれいなサイト」を簡易的に開発可能


39

当社XPages開発のご紹介
“Parts化してしまいましょう！”

「誰でも、かんたんに」をコンセプトに
XPages開発をサポートする部品群
ＣＯＭＴＵＲＥ

「コムチュア

パボック」
partsBox in Comture

• 必要技術スキル(CSJS,CSS,Dojo.Toolkit)でのUIを提供
• 様々な機能を実現しアプリケーションのWeb化を簡単に
• 標準機能で作成された部品はカスタムも可能
40

paBocはNotesDBマイグレ以外にも効果的

NotesDBマイグレではないXPages開発

外部向けサイト、内部向けWebアプリを

+ XPages
で構築を！
41

XPagesのさらなる発展を願って

ご清聴ありがとうございました。

42

【XPagesDy】A-2_コムチュア_20131106_公開用

More Related Content

What's hot

Similar to 【XPagesDy】A-2_コムチュア_20131106_公開用

Recently uploaded

【XPagesDy】A-2_コムチュア_20131106_公開用