この度、「Notes/Domino ファミリーフォーラム」を開設しました。このフォーラムは、Notes/Domino やその他関連製品についての情報共有、質問、知見を深めていただくための場所です。どうごご利用ください。
いくつか注意事項があります。
お客様間での相互扶助の場としてもご活用ください。このフォーラムでのご質問について、HCL は回答、問題解決の義務を負いません。そのような対応が必要な問題については、技術サポートにお問い合わせください。
HCL として専任の管理者による常時モニターを行っていません。HCL より回答をさせていただく場合もございますが、主たる業務の範囲外でありベストエフォートの内容となります。ご了承ください。
フォーラム内の情報は、HCLからの発言を除き、HCLが保証をするものではございません。
HCL Software サポートトップ画面からの行き方
WFH での課題の一つに、チームワークの困難さがあります。HCL Connections はチームがリモートで仕事をすることを前提に組まれたソフトウェアであり 、10年以上の歴史があります。これについて解説した、英語版ブログ記事 How to Create and Keep an Engaged Workforce の翻訳版を掲載します。
働きがいのある労働力の作り方と維持方法
2020年7月1日
著者: Adam Gartenberg / HCL Software
チームを鼓舞し、仕事に没頭させることは、重要な取り組みです。このことは、世界中で、リモートで仕事をするチームが増えている今、これまで以上に重要になっています。最近のギャラップ社の調査 (*1) によると、仕事に真に従事している社員は3分の1にすぎないとのことです。ギャラップ社は、エンゲージメントレベルの高い組織は生産性が高いだけでなく、一株当たりの利益も4倍に増加していると述べています。
従業員のエンゲージメントが低下する理由の一つに、仕事に必要な情報を見つけられない、あるいは情報不足が挙げられます。社員は、自分の役割に必要な情報を探すために、週に8時間もの時間を費やしていると言われています(つまり、20%の時間、週に1日は仕事ができていないことになります)。HCL Connections にはコミュニケーションのハブになる機能が備わっており、関連する情報をより迅速かつ効率的に提供できます。コミュニティは、より多くの仕事をこなすために必要な専門家と人々を結びつけるのに役立ちます。
ファイルがどこにあるのか、誰がどのように送信したのか、どのバージョンが最新のものなのかがわからないと、チームは仕事をする上で必要な情報を探すのに何時間も何週間も浪費してしまうことになります。Connections の共有ドキュメントリポジトリでは、ファイルはひとつのインスタンス(真に単一のバージョン)として管理しています。つまり、個人のフォルダでも、コミュニティで共有されているものでも、同じバージョンのファイルとして利用可能な状態になっています。どのコミュニティにいても、そのファイルにアクセスする人は常に最新バージョンを見ることができるということです。
組織の成功の基本は、ポジティブで生産的な職場環境と文化を作ることです。チームメイトと頻繁に交流する社員は、洞察力を共有し、プロジェクトに積極的に貢献し、問題解決に積極的に取り組む傾向があります。チームと人を中心とした企業文化を築くことが、成功の鍵となります。Connections には、(新規 Connections 参加者用の) オンボーディング・ウィザードが用意されており、新入社員が専門知識をどこで見つければよいのか、また、どのチームに参加すればよいのかを容易に把握できるようになっています。また、新製品の発表、グローバル・マーケティング・キャンペーン、人事部のコーポレート・コミュニケーションなどのプロジェクトでは、チームの共通の目標や活動を簡単にまとめ、共有できます。また、ユーザーがカスタマイズした Connections のホームページでは、ユーザーが必要とする情報、関連する情報をまとめて表示され、ユーザーが直接アクセスできます。さらに、Connectionsには、プロジェクトやタスクを管理するツールである Kudos Activities Plus が備わっており、プロジェクト管理用のテンプレートが含まれています。これにより、全員が最新の情報を共有し、同じ状況認識のもとで集中力を維持して業務に取り組むことができます。
HCL Connections は、人を中心としたデジタル・ワークプレイスを提供し、企業が本当に重要なこと、すなわち、人とビジネスの成果に集中できるようにします。従業員のエンゲージメントを高めることが、成功への第一歩なのです。
1 ギャラップ調査「従業員のエンゲージメントが米国で上昇中」2018年8月26日。 https://news.gallup.com/poll/241649/employee-engagement-rise.aspx
HCL Connections の製品ページ: https://www.hcljapan.co.jp/software/products/connections/
2020年も後半に入りました。ちょっと先のことを書きたいと思います。
2020年6月に OpenNTF のイベントにおいて、HCL からプレゼンテーションが行われました。そこで使われたスライドの 1 枚がこれです。
スライド下に時間軸がかかれていますが、今は「2020/21」のあたりになります。
2020年後半からは、このロードマップにしたがって、製品がリリースされていく予定です。ご期待くださいませ。
Cloud サービス終了に関連して、サポート技術情報「Notes クライアントでバックグラウンドレプリケーションのスレッドを増やす方法」を作成しました。ピン留されている「Cloud サービス終了のお知らせ」にもリンクを設定してあります。
2020年6月18日、OpenNTF 主催のイベントにおいて、HCL から数名の社員が参加して講演を行いました。その際に、今後に向けた取り組みの一つとして、Notes リッチテキストの互換性に関することが紹介されました。便利であり、Notes を特徴付ける項目のひとつであるリッチテキストについて、データの互換性をいかに確保していくかについて、研究がされています。
これについて書かれた英語版ブログ Sharing Domino Data: How Do You Solve a Problem Like Formatted Text? の翻訳版を掲載します。
本記事は、実現された製品に関するものではありません。今後に向けた、研究開発活動の一つであることにご注意ください。
翻訳者注: 概念的な内容について適切な翻訳が難しい部分がありました。理解が難しい場合は原文の参照をお願いします。途中に YouTube への参照があり、本内容の理解の補助となります。
Domino のデータを共有する。フォーマットされたテキストのような問題を解決するには?
2020年6月24日
著者: Paul Withers / Technical Architect, HCL Labs
Domino データを Notes/Domino プラットフォームの外で共有する際に、 Notes リッチテキストの再現忠実性は長い間問題となっていました。この問題について考える場合、一般的な出発点は、Notes リッチテキストのフィールドレンダラ/エディタと Notes リッチテキストアイテムの保存形式となるでしょう。しかし、これらはあまりに厳しい制約事項であり、その中でうまく収まるようなソリューションを見つけることは困難であり、私たちが考えられる範囲を越えています。
HCL Labs では、より根本的なアプローチをとっています。最近、新しいメンバーが入社してきたときには、箱の外で考えるのではなく、箱に火をつけるように指示されました。その結果、誰にでも合うとは限らないアプローチになってしまうかもしれません。しかし、私たちが Project Rosetta (社内の内部的なコンセプト実証プロジェクト) に与えられた使命は、Domino の外で使用するためのフォーマット化されたコンテンツの忠実性を保つための革新的なソリューションを見つけることであり、それにはひとつの必須条件がありました。デジタルソリューションのCTOであるジェイソン・ロイ・ゲイリーは、DNUG のローンチイベントと最近の OpenNTF のウェビナーでその成果を説明しました。40:27-50:44の10分間のプレゼンテーションはこちらからご覧いただけます。
用語について
初期のアクションのひとつは用語について非常に具体的にすることでした。Domino の読者にとって「リッチテキスト」という言葉は、Notes エディタや特定のストレージフォーマットと表裏一体の関係にあります。その結果、私たちは意識的に「フォーマットされたテキスト (formatted text) 」の扱いに言及する努力をしてきました。この件について議論している人には、間違った思い込みを避けるためにも、同じことをすることを強くお勧めします。
この間、2つのラジカルな選択肢がテーブルに残されていました。それは、Notes ではこのコンテンツのために別のエディタ/レンダラが必要になる可能性があるということと、既存のコンテンツがその利点を活用したい場合には、一度だけの変換が必要になる可能性があるということです。また、2つの重要な期待も認識していました。それは Notes リッチテキストを置き換えることを意図したものではないことと、既存の Notes リッチテキストをすべて変換する必要がないことです。なせなら、コンテンツが Notes クライアントでのみ使用されている場合や、サードパーティのソリューションがすでに問題を管理できている場合は、現状を受け入れられるからです。
出発点
Domino 以外の標準的なエディタには何があり、それらはどのようなフォーマットを使用しているのでしょうか?これは単純な質問のように思えますが、明らかになったのは、Notes リッチテキストエディタは 3 つの特定の目的のために使用されており、それぞれが特定のパラダイムと相互運用可能なフォーマットを持っているということです。
"1. 文書処理" (Document processing)
Domino では、ポリシーや手順書のような複雑で厳密にフォーマットされたコンテンツを管理するために、リッチテキストエディタやアイテムが使用されているのを時々見かけることがあります。そのようなコンテンツを扱うアプリケーションでは、変更追跡のような複雑な、文書処理機能を似せた設計がされています。Domino 以外では、このようなコンテンツは通常、Microsoft Word や HCL Connections Docs、Google Docs、Collabora などの共同編集ツールなど、特定の文書処理ツールで管理されています。
長年の抵抗の末、各ベンダーは相互運用性のための標準フォーマットである OOXML に移行しました。このストレージ・フォーマットには、文書処理エディタではオープンに編集できない、著者やタグなどのメタデータが含まれています。しかし、これらのメタデータは固定されており、範囲も限定されています。エディタはカスタムメタデータの操作を許可していません。また、エディタは一度に1つのファイルを編集することしかできません。
「一度保存すれば、どこでも共有できる」という試みにもかかわらず、セキュリティやアクセスの複雑さから、コンテンツがコピーされてしまうことがよくあります。ドキュメントは、すべての画像や埋め込みファイルなどが含まれた、1つの目立たないパッケージとして送信されます。これは一般的に、HTTPや電子メールの送信には大きすぎるファイルの結果となります。そのため、ユーザーはファイルを圧縮するか、Connections のような製品や SFTP のような一時的な転送プロトコルなど、安全なファイル共有ソリューションにコピーする必要があります。
これは非常に特殊なパラダイムであり、事実上メタデータを追加せずにリッチテキスト項目だけでフォームをマッチングさせるというものです。私たちはこれが有効なユースケースであることを認めていますが、狭義のユースケースです。その場でレンダリングしながら、Microsoft Word のような外部エディタで編集できるような形式でコンテンツを保存できないかどうかを調査するのは興味深いことです。しかし、それは現在のスコープとしては適切ではありませんでした。
2. メール
メールは常に Notes/Domino の中核をなすものでした。Domino が発売された当時、メールはまだ広く使われていませんでした。実際、MIME が定義されたのは 1992 年になってからです。しかし、MIME は Domino 以外での相互運用性のためのデファクトスタンダードとなっています。Domino の外からメールを受信した場合、それは MIME として保存されます。Domino ドメインからのメールのみが Notes Rich Text として保存されます。
繰り返しになりますが、特定のメタデータがありますが限定されています。MIME メールの場合、アドレスが保存されるアイテムタイプは Text ではなく、RFC822 Text です。これは Domino 内部では別のデータ型ですが、Notes クライアントは (おそらく) 特定の方法で解釈するようにプログラムされています。それは興味深く、有益な情報です。
ストレージ構造もこのユースケースでは非常に特殊です。メールは送信者のみがソースから参照されます。他の誰もが自分のメールのコピーを受け取ります。すべての受信者が参照する「単一バージョンの真実」を保存しようとしたことはありません。その結果、流通するのは、文書処理と同様に、テキスト、画像、ファイルを含む単一のパッケージとなります。そのため、最近の多くのメールは外部画像を参照したり、Connections Files や Box のような中央サービス上のファイルにリンクしたりしています。
これもまた、非常に特殊なパラダイムであり、アプリケーションの典型的な使用法とは一致しません。Domino がこのコンテンツを Notes リッチテキストではなく MIME として保存し、Notes クライアントに Notes リッチテキストではなく MIME を使用する代替のエディタ/レンダラがあれば、メールの相互運用性はより簡単になるでしょうか?それは現在の調査の範囲を超えています。しかし、繰り返しになりますが、このタイプのコンテンツは対象外となりました。
3. フォームのフィールドでフォーマットされたコンテンツ
第三のシナリオは、フォーム内の任意のフィールドでフォーマットされた内容です。エディタは文書処理ツールでもメールクライアントでもありません。様々なエディタが使用されていましたが、出力は 2 つのカテゴリに分類されます。HTML とマークダウンです。
マークダウンの編集には、2 種類のエディタがあります。最初のタイプは IDE (VS Code) またはスタンドアロン (Joplin) のエディタで、これらはマークダウンファイルのみを編集するように設計されています。文書処理ツールと同様に、これらは対象外です。2 番目のタイプは、OpenNTF の Web サイトやブログの Stephan Wissel のコメントエリアのエディタのように、アプリケーションに埋め込むことができるマークダウンエディタです。これらは Domino アプリケーションのためのエディタの種類とより密接に関連しています。また、TinyMCE のような HTML としてコンテンツを提供するエディタや、Vaadin リッチテキストエディタのようなフレームワーク固有のエディタとも密接に対応しています。
ドキュメントプロセッサやメールエディタとは、他にもいくつかの重要な違いがあります。第一に、コンテンツはコピーされることを意図したものではなく、参照されることを意図したものです。第二に、画像とファイルの添付ファイルは通常別々に保存されているため、コンテンツを表示しているクライアントが何であれ、それらをキャッシュすることができます。実際、WordPress のようなブログプラットフォームでは、これらのリソースを別々に保存することが義務付けられており、エディタはこれを強制しています。Domino でも、Declan Lynch 氏の Blogsphere テンプレートは、アセットを別々に保存するというアプローチをとっています。第三に、1 つのフォームに複数のフォーマットされたテキストエディタがあるかもしれません。第四に、フォーマットされたコンテンツに隣接するメタデータ、つまり他のフィールドはランダムであり、2つのフォームに同じメタデータが含まれることはほとんどありません。
以上の三つが Project Rosetta がターゲットとしたシナリオです。この分析からわかるように、Notes リッチテキストエディタとアイテムの機能には重要な違いがあります。しかし、私たちが対象としたユースケースは、Domino 以外で共有することを意図したコンテンツのみを対象としています。
アーキテクチャーの選択
私たちの概念実証には単純な目標がありました。コンテンツを HTML またはマークダウンとして管理し、理想的には両者を変換して Domino に保存できるようにすることの実現可能性を探ることです。
通常、コンテンツはどちらか一方で入力されます。マークダウンは、意味づけされた基本的なフォーマットで素早く編集するための、素晴らしい柔軟性のあるアプローチであり、利用する場面でも興味深いものになるでしょう。また、ノートブロックのような HTML では容易に利用できない、マークダウンで利用可能な選択肢もあります。しかし、例えばマーケティングや HR のユーザーがコンテンツをマークダウンとして入力することを期待することは現実的ではないことも理解しています。マークダウンと HTML とその逆の間で変換することはこの問題を解決し、Domino のローコードビジョンのために議論されてきたローコード/プロコードの往復アプローチに類似しています。
私たちは、Project Keep の上に API レイヤーを構築しました。私たちが抱えていた課題は、他のフィールドと共にこのコンテンツを送信する場合、どのようにして保存すべきデータ型を決定するかということでした。Keep や Domino HTTP では、添付ファイルはすでにアップロードされ、フィールドデータへのアクセスについては、別個の REST 呼び出しで取得されていした。そこで、ここでも同様のアプローチをとりました。この時点でのフローは、1回の呼び出しでドキュメントを作成し、別の呼び出しで添付ファイルや画像をアップロードし、Content-Typeを "text/ HTML "または "text/マークダウン"としてフォーマットされたコンテンツをアップロードまたは取得するというものです。これは変更できますか?もちろんです。
技術的には、Keep は Java であり、Java では HTML 操作のための標準ライブラリーは JSoupであり、マークダウン変換のための標準ライブラリーはflexmarkです。
サーバー上の2つの出力タイプの間でこの操作を維持する利点は、クライアントが HTML またはマークダウンを話す必要があればよいことです。マークダウンの異なるフレーバー (方言) は将来的に課題となるかもしれませんが、それは先の話です。アプリ開発者にしてみれば、かれらは独自のエディタを持っていて、私たちは一貫した変換を提供するわけです。サーバー上で処理することで、HTML をクリーニングするフェーズも可能になります。これは、現時点ではお話しできませんが、多くの潜在的な革新的な機会を開くことになるので、私はこの方法を維持することを特に強く望んでいます。
確かに、誰も解決できないような問題を解決しようとしているのかもしれません。しかし、研究開発とは、問題を別の方法で考え、これまでに提案されなかった解決策を考え出すことです。イカルスのように、より高く飛ぶ勇気があっても、落ちても構わないということです。
モバイルから Web へ、そして生の HTML /マークダウンの上に適切なエディタで Nomad が何を扱えるかを考え、Webへ、そしてモバイルへと戻っていくデモで、私たちがやろうとしていたことは達成できたと思っています。確かに完全なものではなく、Notes クライアント/Nomad 上での作業が必要になります。そして、私が言ったように、これはすべてのシナリオをカバーしているわけではありません。しかし、より普遍的なものを使って、Notes リッチテキストの特殊性なしに Domino にフォーマットされたコンテンツを出し入れできることを実証しています。これは、非 Domino データベースから NSF にフォーマットされたコンテンツを移行するための新しい方法を開き、非伝統的 (non-traditional) な聴衆にアピールしています。また、セッションの最後に Jason が示したように、フォーマットされたコンテンツのために Notes Rich Text を超えて考えることは、EWS (Exchange Web Services) のような非伝統的 (non-traditional) なクライアントや転送フォーマットのための要件です。
2020年6月23日、「クラウドネイティブな HCL Digital Experience の新リリースでビジネスクリティカルな状況に対応」のニュースを発表しました。
How HCL Connections Helps Close the Gap in Crisis Management - HCL SW Blogs 英語版ブログで 5 Myths about Domino You Need to Stop Believing Right Now がポストされました。その翻訳版を掲載します。
今すぐ捨てるべき Domino に関する誤った 5 つの神話
2020年6月2日
著者:Matt Engstrom / Software Sales, Regional Sales Director & Product Specialist
ユニコーンは毒水を飲めるようにしたり、病気を治したりすると言われているので、実在することを望む人もいます。確かにどちらもそうであれば良いのでしょうが、ユニコーンは空想の産物に過ぎません。Domino は神話に出てくるような優美な生き物ではありませんが、過去30年間にわたり、大企業でそのセキュリティー、汎用性、拡張性、価値を証明してきました。それがあまりにも長く続いていることと、献身的で熱狂的な顧客コミュニティー (「チーム・イエロー」とも呼ばれています) が続いており、Domino は伝説的な地位を獲得しています。その一方で、「Domino プラットフォームは古い」、あるいは「時代遅れである」などの誤解も長い間続いています。しかし、真実から目を背けることはできません。これらの神話のいくつかを説明し、今日の Domino で何が可能なのかをお見せしましょう。
HCL Nomad は、HCL Domino アプリケーションの力を、デスクトップの枠を超えて、ユーザーが必要な場所に直接もたらすものです。アプリケーションを、比類のないセキュリティーやオフライン機能をモバイルでも利用できます。Apple iPhone と iPad、Android スマートフォン、Android と Chrome OS タブレットでアプリを最小限の労力で利用できます。HCL Nomad の詳細についてはこの機能シートをご覧ください。
Notes クライアントを使用して Domino アプリにアクセスすることはもちろんできますが、Web ブラウザー用にアプリを書くことができるようになっています。既存アプリをブラウザー上で動作するように変更したり、新しいアプリをブラウザーアクセス用に記述したりすることができます。この例では、Web 用に書かれた注文処理用の社内アプリで、営業チームが毎日使用しているものです。
LotusScript と XPages に精通した Domino 開発者と管理者には深謝してやまないところですが、私たちはお客様の幅広いスキルと才能を開放し、お客様の投資を将来的に確かなものであることを証明したいと考えています。
今では、JavaScript の開発者であれば誰でも Domino のデータやプロセスを含む新しいアプリケーションを強化、統合、構築することができます。この例は、React で書かれた Web UI を使って構築されたトラッキングアプリケーションです。クールなフィルター一式を備えています。
HCL Domino V11 はこれまでで最もオープンなプラットフォームです。Domino に備わった統合機能により、他のツールやアプリケーションを高いレベルで統合させ、より活用することができます。
ここでは、私たちが実現させたいくつかの統合を紹介します。左側は、リアルタイムのデータ検証を可能にする社内の営業アプリと CRM システムの連携・統合です。右側は、アプリと Slack を連携・統合させて、チャネル内での即時通知を実現しています。ユーザーは Slack 内で、提出された提案書の承認や拒否を直接行うことができ、アプリ内で設定されたワークフローに従ってドキュメントの処理を進められます。
Domino アプリは堅牢であり高い信頼性を有しています。これが、当社のお客様のほとんどがアプリの再設計を考えたことがなかったり、Dominoにはそのような柔軟性がないと思い込んでいる理由でしょう。
ここでは、今日のデザイン基準に合わせてアプリを近代化した例をいくつかご紹介しましたが、私たちは最近、別のブログ記事も書きました。私たちは、複雑でビジネスに不可欠なアプリを一新しただけでなく、モバイルデバイスでも動作するようにしました。
Domino V11。ファンタジーではなく、ファンタスティック。Dominoを使ってみましょう。デモの依頼 もできます。
2020年5月29日、英語版ブログに Domino Volt - Getting on with Business, Lightning Fast! がポストされました。その翻訳版を掲載します。
Domino Volt でビジネスを回す、しかも超高速!
2020年5月29日
Martin Lechleider
Director, Product Management, HCL Domino Volt
COVID-19 の時代には、組織は従来のソリューションから離れて適応しなければならず、我々は問題をすばやく解決し、別の方法で行うことを学んでいる最中にあります。最近のウェビナーでは、HCL Domino Volt が、ビジネスの重要でミッションクリティカルな部分が稼動し続け、リモートの従業員をサポートし、新しいプロセスを構築する方法を示しました。また、ビジネス上の課題に最も近いユーザーが、IT 部門の支援を最小限に抑えてこれらの新しいプロセスを簡単に構築できることを示しました。
人事と財務が会社の給与予算と在宅勤務の従業員の調査を管理するのに役立つ一時帰休のアプリケーションを作成し、デモを行いました。さらに、5つの重要な教訓と、最初の Domino Volt ワークフローベースのアプリケーションを構築するために推奨するベストプラクティスを示しました。ここでリプレイを見ることができます。
いつものように、出席した方々はとても活発で、たくさんの素晴らしい質問がされました。これらの質問とその答えを以下に示します。
今日、チームは単に機能するテクノロジー以上のものを必要としています。Domino は、ビジネスを実行する堅実な (rock-solid) アプリを提供するために何千もの企業から世界中で信頼されている実証済みのプラットフォームです。さて、取りかかりのお手伝いをいたしましょう。まず、Sandbox の無償アカウントを取得して、Web ブラウザーを使って Domino Volt アプリケーションの作成を開始しましょう。ソフトウェアのインストールは必要ありません。
一時帰休アプリとアンケートのデモ
Q:デモアプリを共有されますか。
A:はい、Sandbox で .volt ファイルが共有されます。
Q:これらのアプリの作成にはどのくらい時間がかかりましたか。
A: 一時帰休のアプリケーションは3週間 (HCL Domino Volt の学習に費やした時間を含む)、最初のアプリケーションの構築から学んだ教訓を反映させ、アンケートのアプリケーションの場合は1週間でした。
Q:デモでは、「接続の問題があります」に対して「はい」と回答した場合、アンケートでサポートチケットが開かれました。チケットを開く代わりにサポート BOT セッションを開始できますか。
A: はい。Domino Volt のローコード機能を使って、特定の要件を満たせるようにアプリケーションを設計できます。BOT でサポート機能を提供し、必要な場合にのみチケットを開くことは、非常に効果的な設計のように思えます。
Q: アンケートの質問は動的またはカスタマイズできますか。
A: はい。Domino Volt を使用すると、アプリケーションにルールを組み込み、ビジネスロジックに基づいて質問することができます。これには、ユーザーが特定のオプションを選択した場合にのみに追加質問を表示したり、あるいは、ユーザーが誰であるかや組織での役割に基づいて追加質問を表示するようば場合が考えられます。
Q: アンケートの回答を含むダッシュボードを表示することはできますか。
A: はい、これは可能です。デモ では、Survey Analyst ロールとしてログインするときの例をお見せしました。デフォルトでは Domino Volt は収集したデータのビューとそのデータのグラフを表示します。
一般的な Domino Volt 機能
Q: Domino Volt はリレーショナルまたは NoSQL データベースを使用しますか。
A: Domino Volt は、すべてのデータとアプリケーションを Domino NoSQL データベースに格納および管理します。詳細については最近のブログ投稿をご覧ください。
Q: Domino Volt アプリはどのデバイスでも動作しますか。
A: はい。Domino Volt アプリはモバイル対応です。ラップトップ、タブレット、スマホで動作する Web アプリです。
Q: Domino Volt アプリは、オフラインで使用できる Nomad と互換性がありますか。
A: Domino Volt で作成されたアプリは Domino アプリであり、HCL Nomadで使用できます。ただし、Nomad での Domino Volt アプリの使用には制限があり、定義した Web エクスペリエンス、そしてクライアント側のロジックは動作しません。
Q: Excel フィルターのようなビューフィルター機能はありますか。
A: 現在、Domino Volt ビューのビューにフィルターを追加できます。追加のフィルタータイプは、次の Domino Volt リリースで計画されてい ます。
Q: JDBC アクセスでリレーショナル DB と連携・統合できますか。
A: 現在、Domino Volt では、統合に REST と Web サービスに依存しています。ただし、将来的には、リレーショナルデータベースへのネイティブアクセスを提供する予定です。
Q: 「ビュー」で列を並べ替えるにはどうすればよいですか。
A: テーブルコントロールでは、列ヘッダーをクリックしてその列をソートできます。
Q: 誰もが投稿できる便利なコードやアプリのスニペットのカタログがあればいいと思います。
A: HCL ではすでにスニペットを共有するスペースがあり、Sandbox で利用できます。
Q: REST を知らない人のために、Domino Volt から Domino ディレクトリーのデータに簡単にアクセスできるようにする予定はありますか。
A: はい。Domino ディレクトリーからの Domino データをアプリケーションに連携・統合する方法を改善することを優先させて開発しています。次の Domino Volt リリースでこれらの改善のいくつかが見られることを期待してください。
Q: HCL Leap から Domino Volt にファイルをインポートできますか。
A: Leap 9.2 から Domino Volt にファイルをインポートできます。ただし、 Domino Volt がまだサポートしていないものがあります。たとえば、匿名アクセスや動的な役割の割り当てなどです。どちらも Domino Volt のロードマップにあります。
Q: サービス呼び出しを構成するコーディングの種類について説明できますか。
A: サービスをアプリケーションに統合するには、アクセスする API の知識と、REST サービスの仕組みに関する基本的な知識が必要です。Domino Volt での「コーディング」部分とは選択したり結びつけをすることであり、それによりアプリでのサービスの動作方法を構成することができます。これには、URL、必要な認証、アプリからサービスへの入力とサービスからアプリへの出力をどのようにマッピングするかなどが含まれます。
Q: Domino Volt で署名を行うことはできますか。
A: この機能は、JavaScript ライブラリーを使用して追加できます。Domino Volt フォーラムにあります。
Q: Domino Volt は、Domino などの新しいリリースでも、既存のアプリの互換性を保証しますか。
A:ソフトウェアのどのリリースで作成したアプリであっても完全にサポートされることを原則に製品を開発しています。次のリリースにアップグレードしても、デプロイした内容が壊れることはありません。
Q:技術的なセッションはありますか。
A: HCL Digital Solutions アカデミーにご注目ください。アプリケーションの構築方法について開発者を教育するのに役立つことを目指しています。間もなくリリースされる予定です。
HCL Domino Volt のロードマップ
Q: Domino Volt はいつ匿名アクセスをサポートしますか。
A: 次のリリースで匿名アクセスをサポートする予定です。
Q: パートナーや企業が Domino Volt ベースのアプリケーションを一覧または宣伝できる HCL ライブラリーまたはカタログの計画はありますか。
A: はい、ビジネス パートナーと顧客がアプリケーションとコードを利用できるようにする手段を提供する予定です。詳細 は後日発表します。
Q: ユーザーが Domino Volt ベースのアプリをオフラインで使用できるようにする計画はあり ますか。
A: はい。オフラインサポートを備えたモバイルクライアントがロードマップに含まれています。
Q: 動的な役割の割り当てをサポートする計画はありますか。リクエストの作成者に基づいて承認者またはレビュー担当者を決定する必要があります。
A: はい、次のリリースで追加する予定です。
Q: Domino Volt は Dojo を内部で使用しています。Dojo の最新バージョンの使用に関する予定はありますか。
A: HCLは、Domino Voltのコアテクノロジー (JavaScriptライブラリーを含む) を更新することで、お客様に付加価値を提供できることを認識していますが、計画されたスケジュールはありません。
Q: Domino Volt のモバイルに関するロードマップはどのようになっていますか。
A: カメラ、GPS、QR、バーコードリーダー、タッチジェスチャーなどのモバイル機能のサポートが予定に含まれています。アプリをオフラインで使用して、接続時に同期する機能も入っています。
Q: Domino i Volt は IBM iSeries で利用できますか。
A: Windows と Linux 以外の追加のプラットフォームサポートを検討しています。
Q: Domino のようにカスタムビューを作成できるようになるのはいつですか。
A: Domino Volt の表示機能を改善することは、私たちの優先事項の1つです。今後のリリースでは、この領域の改善していく予定です。
Domino Volt のライセンスとインストール
Q: 一部のユーザーに Domino Volt のライセンスを付与できますか。
A: HCL Domino Volt は、ユーザーごとのライセンスである Domino CCB ライセンスで利用が許諾されます。メールと同様に、Domino Volt は組織内のすべての人を対象としています。
Q: Domino Volt を使用するにはどのような インフラストラクチャーとソフトウェアが必要ですか。
A: Windows または Linux で実行される HCL Domino v 11.0.1 および HCL Domino Volt が必要なすべてです。
免責事項: HCLの計画、方向性、および意図に関する声明は、HCLの独自の裁量により、予告なしに変更または撤回される場合があります。潜在的な将来の製品に関する情報は、当社の一般的な製品の方向性を概説することを目的としており、購入の決定を行う際にこれに依存するべきではありません。潜在的な将来の製品に関して言及されている情報は、資料、コード、または機能を提供することを約束、約束、または法的義務ではありません。潜在的な将来の製品に関する情報は、いかなる契約にも組み込まれない可能性があります。当社の製品について説明されている将来の機能の開発、リリース、およびタイミングは、当社の単独の裁量に留まります。パフォーマンスは、制御された環境での標準HCLベンチマークを使用した測定と予測に基づいています。ユーザーが経験する実際のスループットまたはパフォーマンスは、ユーザーのジョブストリームでのマルチプログラミングの量、I/O構成、ストレージ構成、処理されるワークロードなどの考慮事項を含む多くの要因によって異なります。したがって、個々のユーザーがここで述べた結果と同様の結果を達成できるという保証はありません。