May 31, 2015

私がxPagesに手を染めないのは・・・・

テーマ:Lotus General

ここの読者の皆さんは、Notes/DominoのBlogなのに流行の?xPagesの記事が一つもないのか?と思われている方もいらっしゃると思います。




理由は簡単で、xPagesのSkillは一切持ち合わせていません。(笑

というか、Skillを身に着けようと全く思わないからなのです。



Notes/Dominoと言えば、LegacyなClient/Server Applicationですが、Client/Server Applicationだから出来る機能が沢山あるわけです。



それを流行じゃないとか、見た目が悪いとかといった理由で、近代的な?WebやSmart Phone、Tabletで動くようにするというのはどうも気が引けます。



Notes/Dominoは、End User開発で様々なApplicationが作成され、それが今も使われていると思います。

近年ではEnd User開発はされなくなってしまいましたが、それでも、気軽に開発が可能なApplication開発Platformとして使われていることも多いでしょう。



元々、Notes/DominoはLegacy HostのApplication Backlogを解消するToolとして日本で活用されたことを思い出して頂きたいと思います。


目的は、業務を効率的に遂行するためのApplicationをいち早く開発して、Releaseすることでした。




それが、今ではどうなんでしょう?



今、Notes/Dominoで動いているApplicationを近代化する??



それによって、何か新しい価値は産まれるでしょうか??



「Mobileで使う利便性」なんて言葉が聞こえて来そうですが、それを実現する為に投資するCostを考えるとどうなんでしょう??



Applicationの本質は変わらずに、Mobile利用だけ出来るようになったとして、どれだけの価値を産むのか??



疑問ばかりです。




今のSmart PhoneのApplicationを見てみると、LineやFacebook、Twitterに代表されるSNS系のApplication、Shop系のApplication、天気予報、NewsなどConsumerを対象としたApplicationが殆どです。

Smart Phoneで会社の業務をするとしたら、Mailを参照したり、一部Workflow Applicationの承認処理を行ったりする程度が一般的なのではないかと思います。

LineなどのApplicationを見てみると、文字入力を求められるApplicationはお世辞にも効率が良いとは思えない訳で、逆に効率を下げてしまっています。

まあ、入力に慣れた若い世代は別として、役職者などの年代を考えると、入力は無理で、Workflowの承認ボタンを押す程度が限界ということだと思えてなりません。


やはり、Deviceの特性を考えた利用方法を考えないと役に立つApplicationは作れないのかも知れません。




と考えると、Notes/DominoのApplicationをxPagesでTablet/Smart Phone対応したとすると、一体何が出来るのか?疑問になってしまうのです。


皆さんご存知のように、xPagesもWeb Applicationですから、EditorはCKEditorを使うことになりますが、これはHTML Editorですが、Notes/DominoのApplicationはRichtext Fieldを持った物が多いです。

xPagesで文書を編集して保存したりすると、Richtext特有の内容は破棄されてしまいます。

つまり、文書を編集するようなApplicationには向かないですし、そもそも、Device特性として文字入力機能の生産性が低い訳ですからわざわざxPages化する意味はないのではないかと思われて仕方ありません。




私が、Notes/Dominoを好きになったのは、手軽に業務改善が出来ることです。


業務改善は、生産性を上げることが目的ですので、xPagesにすることで生産性を後退させるようなことは私はしたくありません。



Tablet/Smart PhoneのApplicationはそのDevice特性を考慮して新規に作るものであって、xPagesを使って既存のNotes/DominoのApplicationを無理やり近代化するものではないのではないかと思うのです。


IT部門は新しい技術を採用し、Userにその利便性を訴求したいのかも知れません。


でも、それが本当に正しいアプローチなのか、今一度、業務改善という観点で見直した方が良いのかも知れません。



 

いいね!した人  |  コメント(4)  |  リブログ(0)
最近の画像つき記事
 もっと見る >>
May 03, 2014

Notes/Domino 9.0.xのDesigner Helpは中身が少ない?

テーマ:Lotus General
これまで余り気にしていなかったのですが、Lotus ScriptのClass/Property/Methodを探そうとして、今頃気が付いたのですが、Notes/Domino 9.0.1のDesigner HelpにはLotus ScriptやJavaのClassなどの文書が含まれていません。

これでどうやって開発しろというのか?、少し疑問に思ってしまいます。

私は、仕方なく、Notes/Domino 8.5.3のHelpをCopyして利用していますが、Notes/Domino 7.0.xからUpgradeされた場合などは、Helpは7.0.xと9.0.xの物しか利用できず、開発上問題になるのではないかと思います。

7.0.xは既にSupportが切れており、これに対応するために9.0.xにUpgradeされる場合も多いかと思いますが、Upgrade時には、8.5.3のClient Moduleも入手して、HelpをServerにReplicaして参照出来るように準備しておいた方が賢明です。

Notes/Dominoは、Client/Server環境での開発は諦めてしまったのでしょうか?

X-Pagesばかり強調されている今日この頃ですが、世の中の多くのUserはまだまだClient/Server環境で使っており、現行Userが不便になるような変更をするのはどうかと思います。
 

いいね!した人  |  コメント(4)  |  リブログ(0)
April 15, 2014

常識は本当に常識なのだろうか?

テーマ:Lotus General

様々な経験から?とか言うと何か重みを感じてしまう人もいるかも知れませんが、これまで常識だと思っていたことを疑ってみたことはあるでしょうか?



例えば、Dominoの世界ではDB Maintenanceと言えば、決まったようにFixup/Updall/Compactを順番に流していきます。


Webを探すと、昔からのようにこの順序に意味があるように書かれていたりする文献もあるようですが、皆さんご存知の通り、DBが壊れてしまった場合はFixup、View Indexの再構築がUpdall、DBの圧縮がCompactで、それぞれ意味があって実行しているのです。


しかし、世の中では、定期メンテナンスと称して、必ずと言って良いほど、Fixup/Updall/Compactの順序で行われているのではないでしょうか?


今の世の中、大規模Userの場合は、1 Serverに配置されたDBの容量が1TBを超えることなど珍しくはないでしょう。


このような環境でDB Maintenaceを従来通りのやり方でやっていたのでは、DB Maintenanceの為の夜間のBatch Windowがどんどん長くなり、運用に耐えられなくなる現象が出ているのではないでしょうか?


こんな状況でDB Maintenanceすると、Compactだけでも数時間を要するのではないかと思います。


破損文書を残すためにFixup -Nなんかを行うと、2500DB/300GB程度であっても4時間近くかかり、UpdallやCompactも同様に長時間かかってしまい、結局、Maintenanceに10時間とか20時間とかかかってしまっている場合を見かけます。


これがこれまでの常套手段であり常識だとして、そのまま運用を続けると、5年後、10年後にはこのシステムは破たんします。


では、どうすれば良いのか?


それは、常識と思っていることを一旦捨てて、ちゃんと考えてみることです。


通常の運用でFixupはDBが破損しない限り実行する必要はないでしょう。


最新のDominoでは、DBが破損していることが発見されると、Dominoが自動的にFixupを実行します。

唯一、出来ないのが、システム系のDBで、names.nsfや2次Addressbook、Log,nsf、Admin4.nsf、Reports.nsf、Events4.nsf、Busytime.nsf(Clubusy.nsf)、Cldbdir.nsf、Mail.boxなどです。

これらのDBは定期的にServerを停止して、Offlineでfixupを流してやる必要がありますが、これも個別に処理している事例が多いと思います。

Job SchedulerでDominoを停止し、順番に、System DBのMaintenanceを流すという処理を行っている場合が多いのではないでしょうか?

この運用を行っていると、DominoのMaintenanceが必要なDBが追加されてしまうと、Job SchedulerのBatch Jobを直さなければならなくなり、Dominoの運用担当者だけでは対処ができなくなってしまいます。


こんな時に便利なのが、Dominoが提供するIndirect Fileです。

Technoteなどでも紹介されており、ご存知の方も多いと思いますが、File_Name.indというファイルを作成し、その中にMaintenance対象DBを記述しておけば、そのDBを順次Maintenanceしてくれるというものです。

実際のCommandは以下のように行います(Windowsの場合は、最初に"n"を加えてください)。


 fixup <options> File_Name.ind

 compact <options> File_Name.ind

 updall <options> File_Name.ind


設計置換が必要な場合は、


 design -i File_Name.ind


というような形で行います。


Design Taskのみ、ファイル単位の指定をする場合は -f 、Indirect Fileを利用する場合は -iのOption指定が必要です。


これであれば、上記の内容をJob SchedulerのBatch Jobに登録しておけば、後は、Domino担当者がFile_Name.indの内容をMaintenanceするだけでMaintenance対象のSystem DBが変わったとしても対応が出来るのです。


さて、これでSystem DBの定期Maintenanceは出来ましたが、次はUser DBのMaintenanceとなります。

上記に書いたように、User DBはDominoが自動Fixupしますので、Fixupは基本的に必要がありません。

行うべきなのは、Updall -RとCompactでしょう。


従来の常識?からすると、Updall -R/Compactの順番で流すのではないでしょうか?

しかし、基本に戻って考えてみると、この順序で流す意味はどこにあるのでしょうか?

「UpdallでView Indexを再構築してから、CompactするとDBは完全に綺麗な状態にまでCompactが行われる!」

確かにそうかも知れませんが、それにどれ程の意味があるのでしょうか?

Compactを行ってDBを綺麗な状態にしてから、Updallを流した方が処理効率は上がると思われます。

これも、従来から常識と思われている手順を踏むから起こることです。

少し試してみたことがありますが、通常長い時間が掛かっているUpdallがCompact後に流すと、すんなり終わってしまいました。

私の経験上では、Fixup -N/Compact/Updall -Rの順番に流した場合、5:3:1くらいの時間割合で処理が終わることが分かりました。


しかし、皆さん、面倒だからと、CompactやUpdallを単純に流して運用されているのではないでしょうか?


この場合、Updall/Compact TaskはRoot Directoryから順番にDBをMaintenanceしていくことになります。

今のH/W環境を考えると、Domino Serverは、利用しているCPUなど能力の高いCPUを使いこなせず、能力の高いDiskのI/O処理能力も使いこなせず、単に順次処理することにより、多大な時間が掛かってしまうことを経験されているのではないでしょうか?


昔の環境であれば、DominoでもCPUを70%とか使っていたと思いますが、今の環境ではCPUなど数%か20-30%程度の利用率なのではないかと思います。


そういう環境であれば、マルチ処理が非常に有効な手段となります。

Maintenance Taskを全体に対して複数流すことも出来ますが、この際は、同じDB Listから順番に処理するため、競合が起こり、Errorを出しながらMaintenane Taskが行われて行きます。

それでも、時間はかなり短縮されますが好ましいことではありません。


運用として、基本的にDominoのData RootにDBを配置しない設計にされており、Sub FolderにDBが格納されている環境であれば、Sub Folder毎にマルチで流すことにより、より効率的に処理が行えます。


例えば、2500DB/300GBのデータを持つDBがあり、これらが10個のSub Folderに分散配置されていたとしましょう。

これを普通にFixup -Nを順次処理すると、かなりH/W能力の高い環境でも3-4時間かかってしまいます。

では、Sub Folder毎に処理すると、一つのTaskは250DB/30GBの処理を行う訳ですが、結果は40-50分程度で終了するのです。

1/4程度の時間で処理されていることになり、かなりの時間削減になります。


勿論、Sub Folderに分けられていない環境でも先に述べたIndirect Fileを利用するとマルチ処理することは可能になりますが、DBが増えて行く環境ではINDファイルのメンテナンスが面倒になりますので、基本は、Sub Folderを適切に作成して運用するのが現実的だと思います。

上手な運用をするなら、Job Schedulerからは、server -c "load compact <options> File_Name.ind"を発行し、Indirect FileにFolderを記述して、適切な容量、DB数を均等化することでしょう。


常識を考え直してみると、意外と改善は沢山できるということがお分かり頂けたのではないでしょうか?




最後になりますが、Server移行の際は、FTPやOS Copyを使って、Fileを移行するのが当たり前です。

この際のCopyやFTP時間はどうしようもない範疇であり、実際のDominoの移行という観点からすると、無駄な時間かも知れません。

しかし、"過去の事例や実績、常識に基づき"、未だに、Offlineで全てのDB Maintenanceを行わなければならないと思っている方が今でもおられるようです。

こんなことをしたとしたら、土日を使っても1TBを超えるData移行は出来ないことは明らかです。

OfflineでMaintenanceしなければならないのは、一部のSyetem DBだけであり、User DBはOnline Maintenanceで十分なのです。

Onlineであれば容易にマルチ処理が行え、時間は大幅に短縮できるのです。


Offlineが必須なら、DominoはOnline Fixupを自動処理したりしないでしょう。

極稀に、Offlineでしか直せないようなDB破損もありますが、その場合はOfflineでも直らないCaseが殆どであり、今や、Offline MaintenanceはSystem DB以外意味がないと思います。


今の世に中では、停止時間を最小にしながら、適切なMaintenanceを行って移行することが極めて重要であり、更に停止なく移行することが求められてきている訳です。



運用や移行は常識だと思われていることを一旦捨てて、考え直す勇気が無い限り、現在のお客様の要件を満たすことはできないのではないかと思います。

 

 




いいね!した人  |  コメント(0)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。