HCL Notes/Domino お客様事例: エームサービス株式会社

2021/9/23 - 読み終える時間: ~1 分

HCL Notes/Domino を20年以上に渡り利用されているエームサービス株式会社の事例を公開しました。

https://japan.zdnet.com/extra/hcl_202107/35173252/

現場の業務から社内ポータルまでカバーし、最近では RPA との連携へ拡張されて使われています。是非、ご一読ください。

Notes/Domino V12 特設ページにもリンクを置いています。

画像の説明

取材に協力いただきましたエームサービス株式会社に御礼申し上げます。


秘密は守られた。MarvelClient for HCL Nomad Web が出荷へ

2021/9/23 - 読み終える時間: 3 分

The Secret is Out: MarvelClient for HCL Nomad Web Is on Its Way! の翻訳版です。


秘密は守られた。MarvelClient for HCL Nomad Web が出荷へ

2021年9月17日

著者: Thomas Hampel / Director of Product Management, Domino, HCL Software

画像の説明

この数週間、数ヶ月の間に、多くの方からNomad Webの計画についてお問い合わせをいただきました。私たちが取り組んでいることを皆様にお伝えすることができないのは辛いことでした。しかし、ついにその日がやってきました。


私たちは、MarvelClient for Nomad Web を発表できることを嬉しく思います

HCL と panagenda は、MarvelClient を Nomad Web の新リリース (1.0.1) とともに提供するために努力してきました。利用権をお持ちのお客様は、HCL Software の HCL Software License Management Portal からダウンロードできます。


何が得られるのでしょうか

他のプラットフォームの Nomad や Notes と同様に、手にしてからすぐにいくつかの良いものを無料で手に入れること ができます。

  • Nomad Web の初歩的な概要を知ることができます。
  • notes.ini でユーザー設定やアプリケーション固有のパラメータや値などのコアな設定を管理することができます。
  • 既存の Notes クライアントからの設定やデスクトップの移行を一度だけ行い、ユーザーが Nomad Web を使い始めるきっかけを作ることができます。(初期リリースでは利用できません。Nomad Web 1.0.2で提供される予定です。)


まだまだありますよ

無料の機能は素晴らしい第一歩ですが、有料の MarvelClient モジュールも用意されており、より良い体験をすることができます。

  • 起動するたびに自己修復する適応型の設定を作成します。安定した信頼性の高い動作を確保し、問題の発生を未然に防ぎます。
  • Nomad ランドスケープの詳細な分析により、問題を発見し、対策を立て、変更の効果を監視する。
  • 設定や UI を標準化し、最初から理想的なユーザーエクスペリエンスを提供する。
  • エンドユーザーが Nomad Web、Nomad Mobile、Notes クライアントのすべてのインスタンス間をシームレスに移動可能
  • デバイスの紛失、交換、ブラウザキャッシュのリセットがあっても、Nomad Web の状態を自動的に復元することができます。

これらの機能により、管理者の労力を大幅に軽減し、ヘルプデスクのチケット数を 80%削減し、エンドユーザーの生産性を最大化することができます。


移行ローミングの話をしよう

Nomad Web へのワンタイムマイグレーションは、無料で利用できる機能の一つです。これにより、Nomad Web を初めて起動したユーザーは、自分の知っているクライアントに迎えられることになります。アイコンも、アプリケーションも、設定も、すべて揃っています。


この機能は、今年後半にリリースされる Nomad Web 1.0.2 で利用可能になりますので、お楽しみに

それまでに、MarvelClient Essentials で 従来の Notes クライアントの設定を継続的に収集することで、すでに準備を始めることができます。これらのローミングセットは、ユーザーごとにMarvelClient Analyze のデータベースに保存され、準備が整っています。すべての設定は、わずか数十キロバイトの中に含まれています。

移行ローミングが利用できるようになったら、希望するユーザーのセットに対してローミングをオンにするだけの簡単な作業です。それ以降は、Nomad Web の初回起動時に、panagenda のローミング技術がアップロードされた最新のローミングセットを見つけ出し、自動的に Nomad に引き継ぐことができます。これで完成です。


準備できていることを確認する

すべてのユーザーを Notes クライアントから Nomad Web に切り替える前に、いくつかの点を考慮する必要があります。

  • アプリケーションが Nomad Web でサポートされていない機能 を必要としていないか確認してください。例:pangenda iDNA Applications では、お客様のアプリケーションを分析することができます。
  • Nomad Web の動作には ID ボールトが必要ですので、必ず設定しておいてください。
  • Nomad Web が Domino サーバーに直接アクセスできないため、最新版の Nomad Server (Nomad Web のインストールされた Domino サーバー) が必要です。


ご質問やご意見はありませんか?

HCL と panagenda は、HCL Nomad Web の将来を形作るために、様々なお客様やパートナーと連絡を取り合っています。HCL と panagenda は、HCL Nomad Web の未来を形作るために、様々なお客様やパートナーと連絡を取り合っています。

もし皆様が HCL Nomad Web の次のリリースについて質問やアイデア、具体的な要件 をお持ちでしたら。panagenda 同様、皆様からのご連絡を心よりお待ちしております。


HCL Software サポートが ISO27001 認証を取得

2021/9/23 - 読み終える時間: ~1 分

HCL Software Support Achieves ISO 27001 Certification の翻訳版です。


HCL Software サポートが ISO27001 認証を取得

2021年9月20日

著者: Piet Gaarthuis / Director, Client Support 共著: Isha Gill / Senior Privacy & Security Specialist

画像の説明

この度、HCL Softwareの製品サポートチームがISO27001認証を取得したことをお知らせします。製品サポートチームのディレクターとして、サポート成熟度モデルの階段を1つ上ったことで、チーム全体をこれ以上ないほど誇りに思います。

ISO 27001は、最も広く認知され、国際的に受け入れられている情報セキュリティ規格のひとつです。組織がどのように情報セキュリティを管理すべきかを説明し、情報セキュリティマネジメントシステム(ISMS)の構築、実施、維持、および継続的な改善に関する要件を規定しています。

HCL Software Support社のISO 27001監査は、独立した監査法人であるビューローベリタスが実施しました。監査人は、Supportに実装されているセキュリティ管理をさまざまなパラメータで評価しました。それには、ユーザーのアクセス管理、セキュリティとプライバシーに関するトレーニング、運用上のセキュリティ、暗号化基準、パスワード管理などが含まれます。例えば、当社のアクセスコントロール手順は、規格の期待値を満たすように、すべてのサポートシステムで正式に実施されました。また、事業継続計画(BCP)の評価と改善を行い、事業の中断後、あらかじめ定められた時間内に、あらかじめ定められたレベルまでサポート業務を復旧させることをより確実にしました。また、HCLのIT部門や外部のサプライヤーなど、機能横断的なチームとのパートナーシップやコラボレーションを文書化し、テストした結果、ISO 27001規格に基づいて監査されたすべてのパラメータにおいて、十分かつ適切な管理を行うことができました。

すべてのサポート社員は、セキュリティとプライバシーに関する意識向上のためのトレーニングを成功裏に実施しました。サポート社のトレーニングプログラムは、私たちのすべての事業におけるセキュリティとプライバシーの重要性を強調する文化を育成します。

HCL Softwareサポートでは、情報セキュリティとプライバシーを真剣に考え、社内データとお客様からお預かりしたデータの両方を保護するための適切な手段を実施しています。

当社は、セキュリティは継続的な活動であると考えており、当社が事業を進化・拡大させていく中で、HCL Softwareのお客様には、当社が継続的なコンプライアンスを確保するために、セキュリティ態勢を改善していくことをご安心いただけます。

サポートのISO 27001認証は、HCL Software Trust Center Pageで公開されています。

画像の説明


HCL Compass Rest API の活用

2021/9/23 - 読み終える時間: 18 分

HCL Compass Rest APIs In Action の翻訳版です。


HCL Compass Rest API の活用

2021年9月20日

著者: Pradeesh S P / Technical Specialist, HCL Software

画像の説明

はじめに

この記事では、HCL Compass 2.0.2バージョンで提供されるRESTFULサービスについて説明します。HCL Compassでは、ウェブやデスクトップ・インターフェースの他に、Perl APIやJava Native Interfaceを使用することができます。これらの2つのオプションは、複雑で柔軟性に欠けているため、Compassを中心としたアプリケーションや統合の構築が難しく、時間がかかります。

HCL Compass REST APIは、開発者がHTTPベースのREST APIを使用してHCL Compassと対話することを可能にします。REST APIは、レコードの表示や修正、クエリの作成と編集、テキスト検索など、HCL Compassの多くの機能を実行するために使用できます。REST APIの機能は、コンポーネントとしてHCL Compassのインストールに含まれています。これは、Apache Tomcatインスタンス上に展開され、CQwebサービスから独立して実行されます。一度インストールすれば、あとはサービスを起動するだけで使い始めることができます。このブログでは、REST APIを利用してHCL Compassのデータと対話するPythonスクリプトを開発します。このスクリプトを作成しながら、一般的に使用されているRESTAPIのいくつかを紹介します。


この記事の内容

この記事は、プログラミングや、特定のタスクを実現するためのコードを提供するものではありません。単に、Compassデータと対話するためにREST APIを実用的な文脈で使用する方法を紹介するものです。もちろん、Pythonスクリプトを書くには、関数を使うなど、もっと簡単で効率的な方法があります。データ操作のコードの一部はスニペットに含まれておらず、ほとんどがREST APIと対話するためのリクエストモジュールの使い方を扱っています。


このスクリプトの役割

スクリプトを実行すると、システムで利用可能なリポジトリのリストを表示します。 パラメータとしてユーザー名、パスワード、データベースを入力することで、認証するリポジトリをリストから選ぶことができます。 選択したリポジトリに関連するデータベースを一覧表示します。 ユーザーにデータベースの提供を求め、そのユーザーに割り当てられたレコードを表示するためのクエリを構築する。 クエリを実行して、結果セットを表示します。 クエリを削除します。 REST サーバーからログアウトします。


このスクリプトで使用されるAPI

Repos API - Schema Repositories のリストを取得します。 Authenticate API - CCM REST サーバーへの認証を行います。 Databases API - スキーマリポジトリに関連付けられたデータベースを一覧表示する。 Folders API - クエリを作成する親フォルダーをリストアップする。 QueryDefs API - クエリ定義を作成する。 ResultSets API - クエリ定義を実行して、結果セットを構築します。 ResultSet API - 以前に実行された Query Definition の単一ページを取得します。 QueryDef API - クエリ定義を削除するためのものです。 Authenticate API - CCM Rest Server からログオフする。

では、これらのAPIを詳細に確認しながら、スクリプトを作成していきましょう。


1. スキーマリポジトリのリストの取得

最初のタスクは、ユーザーがスキーマリポジトリを選択できるように、スキーマリポジトリのリストを取得することです。これには、REPOS API、特にエンドポイントである/ccmweb/rest/repos を使用します。この目的のためには、GET HTTPリクエストを使用する必要があります。このデモでは、Python Requests モジュールを使用してREST APIスクリプトを作成します。そのためには、スクリプトにモジュールをインポートする必要があります。そして、request.get()関数を使用して、このAPIリクエストを送信します。request.get関数は、リポジトリのエンドポイントをURLとして受け取り、ヘッダを引数として渡します。この特定のAPIでは、期待されるヘッダーは次のとおりです。

'Content-Type': "application/json"

ヘッダー情報は headers という変数に保存され、URL は repo_endpoint という変数に保存されます。これは、Rest APIのリクエストを行うために、このスクリプト全体でrequestモジュールにパラメータを渡すための、標準的なテンプレートになります。

cont_type = “application/json”

headers={‘Content-Type’: cont_type}

repo_endpoint = “https://servername:8190/ccmweb/rest/repos

response = requests.get(

repo_endpoint,

headers=headers

)

上記のコードは、システムで利用可能なリポジトリのリストを取得します。


2. CCM RESTサーバーへの認証

システムでリポジトリが利用できるようになり、ユーザーがログインするリポジトリを選択できるようになったので、認証を行う必要があります。REST サーバーへの認証には、/ccmweb/rest/authenticate をエンドポイントとする Authenticate API を使用します。使用するHTTPリクエストはPOSTです。まず、ユーザーにユーザー名、パスワード、リポジトリ名、ログインしたいデータベースを入力してもらいます。以前のREPOS APIとは異なり、Authenticate APIでは、上記の情報をJSON形式でボディに送信する必要があります。ヘッダーとURLの他に、今回はボディデータもrequests.postメソッドで提供しなければなりません。また、リクエストが何らかの例外やエラーメッセージを発生させたかどうかを知る必要があり、そのために raise_for_status() メソッドを使用します。すべてがうまくいけば、このリクエストは認証トークンをJSON形式で出力します。これは、Compassのデータを取得または変更するための今後のAPIリクエストに使用する必要があります。このデータを操作してトークンを取得するためには、このJSON出力を処理してPythonの辞書データ構造に変換する必要があります。そのために、.json()メソッドを使用します。Json.dumps関数は、Pythonで処理できるようにjsonデータを文字列に変換します。前回のAPIコールと同じヘッダーを今回も渡していることに注目してください。

期待されるヘッダーは、「Content-Type」。"application/json"

eponame = input(“\nEnter Repository Name : “)

auth_url = “https://servername:8190/ccmweb/rest/authenticate

username = input(“\nEnter your username : “)

password = input(“\nEnter your password : “)

db1name = input(“\nEnter db name : “)

body_data={“username”:username,

“password”:password,

“repo”:reponame,

“db”:db1name

}

auth_response = requests.post(auth_url,headers=headers,data=json.dumps(body_data))

auth_response.raise_for_status()

auth_data=auth_response.json()


3. スキーマ・リポジトリに関連するデータベースの一覧表示

スキーマ・リポジトリに関連するデータベースの一覧を表示するには、エンドポイントがccmweb/rest/repos/repository name/databasesDatabases APIを使用します。HTTPリクエストは GET です。今回は、先ほどのAPIコールのヘッダーとは別に、Authentication Token(先ほどのAPIコールの後に出力として受け取ったもの)を以下のフォーマットで送る必要があります。

期待されるヘッダーは ‘Content-Type’: “application/json”,

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsInJlcG8iOiIxMC4wLjAiLCJleHAiOjE1NzM2NjE5NDUsImlhdCI6MTU3MzU3NTU0NSwiZGIiOiJTQU1QTCJ9.Lgdk9gPm6mFFGEnr6mRt7Vrq-nTnlP86ARKc16bP4syeTIvKQ55JX5r6aFXVC20xC2NwsjqbvAhd2f1r2PiIUA

requests.get関数では、URLとヘッダを渡しています。また、resay_for_status()を行い、.json関数でレスポンスを読み込んでいます。このAPIでは、必須のボディデータはありません。データベースを辞書として取得し、それを処理してユーザーがCompassデータへのアクセスを選択できるように表示する必要があります。

auth = “Bearer”+” “+auth_data[‘token’]

headers1={‘Content-Type’: cont_type,

‘Authorization’: auth

}

db_url = f”https://servername:8190/ccmweb/rest/repos/{RespositoryName}/databases

dbname_response = requests.get(db_url,

headers=headers1

)

dbname_response.raise_for_status()

dbnames = dbname_response.json()


4. 親フォルダのDBIDを取得してクエリを作成する

ワークスペース内のあるフォルダにクエリを作成する必要があります。そのためには、ルートワークスペースにどのようなフォルダがあるかを調べる必要があります。この例では、クエリは一時的なものなので、「Public Queries」フォルダに保存します。そのため、ワークスペース内の「Public Queries」フォルダの DBID を調べる必要があります。この目的のために Folders API を使用し、エンドポイントを /ccmweb/rest/repos/ リポジトリ名 /databases/ データベース名 /workspace/folders とします。 使用する HTTP リクエストは GET です。

期待されるヘッダーは、'Content-Type': "application/json",

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsInJlcG8iOiIxMC4wLjAiLCJleHAiOjE1NzM2NjE5NDUsImlhdCI6MTU3MzU3NTU0NSwiZGIiOiJTQU1QTCJ9.Lgdk9gPm6mFFGEnr6mRt7Vrq-nTnlP86ARKc16bP4syeTIvKQ55JX5r6aFXVC20xC2NwsjqbvAhd2f1r2PiIUA

requests.get関数にパラメータを渡し、いつものようにraise_for_status関数を使い、.json関数を使って出力されたレスポンスをキャッチする必要があります。このJSONデータをjson.dumps関数に渡します。この出力から、次のAPIで必要となるdbIdデータに興味があります。

parent_url = f”https://servername:8190/ccmweb/rest/repos/{RepositoryName}/databases/{DatabaseName}/workspace/folders

parent_dbid_response = requests.get(parent_url ,headers=headers1)

parent_dbid_response.raise_for_status()

parent_dbid_higher = parent_dbid_response.json()

parent_dbid = parent_dbid_higher[1][‘dbId’]


5. クエリ定義の作成

ユーザーからアクセスが必要なデータベースと親DBIDの入力を得たら、スクリプトの目的は、そのデータベース内のどの欠陥が所有されているかをユーザーに表示することです。このため、最初のステップでは、ログインユーザが所有するすべての欠陥を表示するためのクエリ定義を作成する必要があります。この目的のために、QueryDefs API を使用します。エンドポイントは /ccmweb/rest/repos/リポジトリ名/データベース名/workspace/queryDefs で、使用する HTTP リクエストは POST です。このAPIでは、従来のAPIと同様のヘッダが必要ですが、構築されるクエリの構造を形成するボディデータが必須となります。

期待されるヘッダは ‘Content-Type’: “application/json”,

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsInJlcG8iOiIxMC4wLjAiLCJleHAiOjE1NzM2NjE5NDUsImlhdCI6MTU3MzU3NTU0NSwiZGIiOiJTQU1QTCJ9.Lgdk9gPm6mFFGEnr6mRt7Vrq-nTnlP86ARKc16bP4syeTIvKQ55JX5r6aFXVC20xC2NwsjqbvAhd2f1r2PiIUA

本体のデータは以下のようになり、変数query_dataに格納されます。

query_data={ “name”: “MyDefects”,

“dbIdParent”: parent_dbid,

“primaryEntityDefName”: “Defect”,

“queryFieldDefs”: [

{

“fieldPathName”: “Headline”,

“isShown”: “true”

}

],

“filterNode”: {

“boolOp”: “BOOL_OP_AND”,

“fieldFilters”: [

{

“fieldPath”: “Owner”,

“compOp”: “COMP_OP_EQ”,

“values”: [username],

“stringExpression”: “= username”

}

]

}

}

ボディデータをもう少し詳しく見てみましょう。いつものように、ボディデータはJSON形式です。

name – Name of the query.

dbIdParent – The dbid of the parent directory where the query is to be created.

primaryEntityDefName – Record type name.

queryFieldDefs – fieldPathName is the field name.

isShown : true – To display the specific field in the result set.

filterNode – boolOp – AND – Operator for adding multiple filters to the query.

fieldFilters – These are the fields to provide as filters.

fieldPath : Owner – Field name of the filter

compOp – COMP_OP_EQ – Denotes Equal to

values : [username] – ユーザー名は、ユーザーの実際のユーザー名に置き換えられます。この条件では、フィールドOwnerが提供されたユーザー名と等しくなっています。したがって、クエリはオーナーが提供されたユーザー名であるすべてのDefectをリストアップする必要があります。

API用のパラメータの準備ができたので、これらを requests.post 関数に渡し、いつものように raise_for_status 関数を使用して、.json 関数を使用して出力レスポンスをキャッチします。json.dumps関数でJSONデータを渡します。この出力から、次のAPIで必要となるdbIdのデータに興味があります。

query_db = input(“\nEnter Database name to build query : “)

query_data={ “name”: “MyDefects”,

“dbIdParent”: parent_dbid,

“primaryEntityDefName”: “Defect”,

“queryFieldDefs”: [

{

“fieldPathName”: “Headline”,

“isShown”: “true”

}

],

“filterNode”: {

“boolOp”: “BOOL_OP_AND”,

“fieldFilters”: [

{

“fieldPath”: “Owner”,

“compOp”: “COMP_OP_EQ”,

“values”: [username],

“stringExpression”: “= username”

}

]

}

}

query_url = f”https://servername:8190/ccmweb/rest/repos/{RepositoryName}/databases/{DatabaseName}/workspace/queryDefs

query_response = requests.post(query_url,headers=headers1,data=json.dumps(query_data))

query_response.raise_for_status()

query_out = query_response.json()

query_dbid = query_out[‘dbId’]


6. クエリ定義の実行と結果セットの構築

前のステップで Query Dbid を受け取ったので、これを使ってクエリの実行と結果セットの構築を行う必要があります。これらの操作はいずれも ResultSets API で行います。使用する HTTP リクエストは POST です。この目的のために、次のエンドポイントを使用します。/ccmweb/rest/repos/repositoryname/databases/databasename/workspace/queryDefsquerydbid/resultsets。使用するヘッダーは、前のステップと同じです。

期待されるヘッダーは ‘Content-Type’: “application/json”,

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsInJlcG8iOiIxMC4wLjAiLCJleHAiOjE1NzM2NjE5NDUsImlhdCI6MTU3MzU3NTU0NSwiZGIiOiJTQU1QTCJ9.Lgdk9gPm6mFFGEnr6mRt7Vrq-nTnlP86ARKc16bP4syeTIvKQ55JX5r6aFXVC20xC2NwsjqbvAhd2f1r2PiIUA

このAPIでは、ボディデータの受け入れが必須となっています。もし特定のパラメータがない場合は、以下のように空の json を渡すことができます。

query_exec_data={

}

これ以外にも、URL、データ、ヘッダーが requests.get 関数に渡されます。いつものように、ここでも raise_for_status、json.dumps、.json の各関数を使います。出力結果から、次のAPIリクエストに渡すための「result_set_id」が得られることを期待しています。

query_exec_url = f”https://servername:8190/ccmweb/rest/repos/{RepositoryName}/databases/{DatabaseName}/workspace/queryDefs/{Querydbid}/resultsets

query_exec_data={

}

query_exec_response=requests.post(query_exec_url,headers=headers1,data=json.dumps(query_exec_data))

query_exec_response.raise_for_status()

query_exec_results = query_exec_response.json()

resultset_id = query_exec_results[‘result_set_id’]


7. クエリの結果セットのユーザーへの表示

いよいよ結果セットをユーザーに表示します。これには、ResultSet API を使用し、エンドポイントとして /ccmweb/rest/repos/repositoryname/databases/databasename/workspace/queryDefs/querydbid/resultsets/resultsetid を指定します。前のステップの出力としてresultsetidを取得しました。HTTPリクエストはPOSTです。パラメータとしてURLとヘッダを指定するだけです。

期待されるヘッダは ‘Content-Type’: “application/json”,

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsInJlcG8iOiIxMC4wLjAiLCJleHAiOjE1NzM2NjE5NDUsImlhdCI6MTU3MzU3NTU0NSwiZGIiOiJTQU1QTCJ9.Lgdk9gPm6mFFGEnr6mRt7Vrq-nTnlP86ARKc16bP4syeTIvKQ55JX5r6aFXVC20xC2NwsjqbvAhd2f1r2PiIUA

Python Prettytableパッケージを使って、結果を表形式で表示します。結果セットの出力は、辞書形式で提供されます。そこから行の値を取得して、必要な値をPythonのリストとして抽出します。クエリ構成データでは、表示フィールドにHeadlineというフィールドのみを要求しましたが、出力にはデフォルトでdisplayNameが含まれており、これはレコードのID以外の何物でもありません。

result_set_url = f”https://servername:8190/ccmweb/rest/repos/{RepositoryName}/databases/{DatabaseName}/workspace/queryDefs/{Querydbid}/resultsets/{Resultsetid}”

result_set_response = requests.get(result_set_url,headers=headers1)

result_set_response.raise_for_status()

resultset_results = result_set_response.json()

second_final = resultset_results[‘rows’]

headline_value = []

id_value = []

for i in second_final:

headline_value.append(i[‘values’])

id_value.append(i[‘displayName’])

x.add_column(“ID”,id_value)

x.add_column(“Headline”,headline_value)

print(x)


8. クエリ定義の削除

次の作業は、作成したクエリを削除して、スクリプトを実行するたびに新しいクエリが作成されるように、Compass のデータベースに表示されないようにすることです。これには QueryDef API を使用し、エンドポイントを /ccmweb/rest/repos/reposittoryname/databases/databasename/workspace/queryDefs/querydbid とします。このためのHTTPリクエストはDELETEです。パラメータとしてurlとheadersを受け取ります。

期待されるヘッダーは ‘Content-Type’: “application/json”,

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsInJlcG8iOiIxMC4wLjAiLCJleHAiOjE1NzM2NjE5NDUsImlhdCI6MTU3MzU3NTU0NSwiZGIiOiJTQU1QTCJ9.Lgdk9gPm6mFFGEnr6mRt7Vrq-nTnlP86ARKc16bP4syeTIvKQ55JX5r6aFXVC20xC2NwsjqbvAhd2f1r2PiIUA

これまでのAPIリクエストで使われていた通常の機能とは別に、今回の違いは、何の出力も受け取らないということです。この場合、クエリが正常に削除されたかどうかをどうやって知ることができるでしょうか?それには、HTTPステータスコードを利用します。通常、HTTPレスポンスコードが200の範囲にあれば、リクエストが成功したことを意味します。そこで、HTTPレスポンスからステータスコードを取得するために、response.status_code関数が必要になります。これを条件文に渡すことで、クエリの削除が成功したかどうかを検証することができます。

remove_query_url = f”https://servername:8190/ccmweb/rest/repos/(RepositoryName}/databases/{DatabaseName}/workspace/queryDefs/{Querydbid}”

remove_query_response = requests.delete(remove_query_url,headers=headers1)

remove_query_response.raise_for_status()

remove_query_final_response = str(remove_query_response.status_code)

if remove_query_final_response.startswith(’20’):

print(“\nRemoving Query Successful”)

else:

print(“\nRemoving query failed! Please manually remove”)


9. CCM REST サーバーからのログオフ

クエリの出力をユーザーに表示することができたので、意図したタスクはすべて完了しました。あとは、セッションを蓄積してサーバに負荷をかけないようにするために、サーバからログオフするだけです。この目的のために、Authenticate APIを使用し、エンドポイントを/ccmweb/rest/authenticate/logoff とします。HTTPリクエストはPOSTです。先ほどのAPIリクエストと同様に、パラメータとしてURLとヘッダーのみを受け取ります。前のステップで行ったように、ログアウトが成功したかどうかを知るための出力はありませんので、ステータスコードも調べます。

期待されるヘッダーは 'Content-Type': "application/json",

Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJhZG1pbiIsInJlcG8iOiIxMC4wLjAiLCJleHAiOjE1NzM2NjE5NDUsImlhdCI6MTU3MzU3NTU0NSwiZGIiOiJTQU1QTCJ9.Lgdk9gPm6mFFGEnr6mRt7Vrq-nTnlP86ARKc16bP4syeTIvKQ55JX5r6aFXVC20xC2NwsjqbvAhd2f1r2PiIUA

logout_url=”https://servername:8190/ccmweb/rest/authenticate/logoff

logout_response = requests.post(logout_url,headers=headers1)

logout_response.raise_for_status()

logout_final_response = str(logout_response.status_code)

if logout_final_response.startswith(’20’):

print(“\nLogout Successful”)

else:

print(“\nLogout Failed!”)


スクリプトの完全な出力

スクリプトの完全な出力は以下の通りです。システム内のリポジトリの一覧が表示されます。RESTサーバへの認証のために、ユーザ名、パスワード、データベースを入力する必要があります。

次に、ユーザが所有するレコードをリストアップするためのクエリを作成するために親ディレクトリを見つけます。レコードを作成して表示した後、クエリを削除してRESTサーバーからログアウトし、途中でエラーが発生した場合は報告します。

The repositories available on this server are

———————————–

CadenceTest RestAPIDemo

Authenticating to Compass Rest API server!

Enter Repository Name : RestAPIDemo

Enter your username : admin

Enter your password :

Enter db name : RESTD

Listing the Databases for the repository RestAPIDemo

The database name(s) are as follows

RESTD

restn

Building a Query to display records assigned to you

Enter Database name to build query : RESTD

Executing the Query

Displaying the Result Set

+—————+———————————–+

| ID | Headline |

+—————+———————————–+

| RESTD00000041 | [‘Testing RestAPI Demo Record 1’] |

| RESTD00000042 | [‘Testing RestAPI Demo Record 2’] |

+—————+———————————–+

Removing the Query

Removing Query Successful

Logging off

Logout Successful


結論

これで、COMPASS HTTP REST APIの使用を実演するための簡単なスクリプトを作成するという、我々がやろうとしたことは達成されました。これが、HCL Compassのデータを使ったより複雑なアプリケーションやインテグレーションの開発に役立つことを期待しています。


参考文献

https://help.hcltechsw.com/compass/2.0.2/com.hcl.compass.doc/webhelp/oxy_ex-1/com.ibm.rational.clearquest.oslc_cmrest_api.doc/topics/c_rest_api_introduction.html


HCL Compass の eSignature パッケージ機能

2021/9/23 - 読み終える時間: 4 分

eSignature package feature in HCL Compass https://blog.hcltechsw.com/compass/esignature-package-feature-in-hcl-compass/

HCL Compass の eSignature パッケージ機能

2021年9月20日

著者: Garima Hans / HCL TECHNICAL SPECIALIST

画像の説明

eSignatureとは?

電子署名(e-signature)とは、署名者を識別するための信頼できる方法を提供し、その人を電子文書の内容に拘束する電子的手段のことです。

なぜeSignatureが重要なのか?

電子署名は、コンパスの問題を解決するために、ユーザー認証とアクティビティの追跡を提供することで、データ・セキュリティの向上に役立ちます。 例えば、電子署名は、Compass環境を米国FDAに準拠させるために必要となる場合があります。

  • すべてのレコードタイプにアクセスするためのユーザー認証を、各移行や変更の前に実施できます。
  • 承認記録の承認/拒否時に電子署名を要求することをサポートします。
  • トランジションの履歴とその作成者を専用パネルに表示します。

このような仕組みになっています。 あるレコードタイプにeSignatureパッケージを適用する。 そのレコードタイプのレコードには、eSignatureフィールドの新しいタブが含まれます。ユーザー名」「パスワード」「署名ログ」「Is Current」です。署名が必要な場合、ユーザー名とパスワードは必須フィールドとなり、そうでない場合は読み取り専用となります。

eSignatureパッケージはどのように適用できるのか

パッケージを適用できるのは、スキーマ管理者権限を持つユーザーまたはスーパーユーザー/コンパス管理者のみです。Compass管理ツールがインストールされているマシンから適用する必要があります。

  1. HCL Compass Designerを起動します。
  2. eSignatureパッケージを適用したいスキーマリポジトリに接続します。

画像の説明

  1. スキーマバージョンを右クリックし、パッケージの適用をクリックします。

画像の説明

  1. 適用する eSignature パッケージとそのバージョンを選択します。

画像の説明

  1. 有効にしたいレコードタイプを選択します。

画像の説明

  1. 完了をクリックして、選択したパッケージをインストールする。

  2. インストールが完了したら、最新のスキーマバージョンの変更を確認して、ユーザーDBをアップグレードする必要があります。この作業は元に戻すことができませんので、DBA と共にバックアップを取ることを忘れないでください。

画像の説明

画像の説明

WebUIでレコードタイプにeSignatureを設定する

次のステップは、CompassのWebUIで行います。 あなた(または指定されたユーザー)は、選択したレコードタイプとデジタル署名を取得するアクションのためにeSig_Configを作成する権限を持っている必要があります。必要なオプションを選択し、保存をクリックします。

eSig_Configレコードには、署名するレコードタイプを選択するためのフィールドと、そのタイプのレコードがいつ署名されるかを示すために使用する2つのオプションが用意されています。ステート」と「アクション」です。レコード タイプがステートフルの場合は、State と Action の両方のオプションが使用できます。レコードタイプがステートレスの場合は、アクションのみが利用可能です。レコード タイプを変更すると、ステートとアクションの選択はクリアされます。

eSig_Config レコードに対してアクションベースの基準とステートベースの基準の両方を選択した場合、指定したタイプのレコードがいずれかの基準を満たす場合には、署名が必要となります。

画像の説明

署名が必要な場合、ここで入力されたユーザー名とパスワードは、HCL Compass環境へのログインに使用されたユーザー名とパスワードと比較されます。アイデンティティが一致した場合、変更が受け入れられ、署名が記録されます。IDが一致しない場合は、エラーメッセージが表示され、データベースへの変更は行われません。

セットアップが完了すると、誰かが既存のレコードや新しいレコードを変更した場合、変更を保存するためにeSignatureのユーザー名とパスワードのフィールドが必須となります。

画像の説明

eSignature Logに表示される情報は以下の通りです。

  • 記録に署名した人のユーザー名。
  • ユーザーの印刷名
  • ユーザーのグループ・メンバーシップ
  • 実行中のアクション。
  • レコードの最終状態。
  • アクションのタイムスタンプ。

署名は、署名が適用されてからレコードが変更されていない場合にのみ有効です。読み取り専用のフィールドIs Currentには、レコードへの最後の変更に署名が含まれている場合は値「True」が、そうでない場合は値「False」が格納されます。

画像の説明

eSignature」タブには、レコードの署名履歴を表示するフィールド「eSignature Log」があります。このフィールドには、署名が行われた変更のみが含まれます。

eSigログはカスタマイズも可能です。詳しいカスタマイズ方法については、https://help.hcltechsw.com/compass/2.0.2/com.hcl.compass.doc/webhelp/oxy_ex-1/com.ibm.rational.clearquest.schema.ec.doc/topics/sch_pkgs/c_customize_esig.html を参照してください。

あなたの組織では、スキーマにeSigパッケージのような同様の要件がありますか?下記のディスカッションにご参加ください。


HCL Unica Journey のエクスポートとインポート機能

2021/9/23 - 読み終える時間: 3 分

Export and Import Functionality in HCL Unica Journey の翻訳版です。


HCL Unica Journey のエクスポートとインポート機能

2021年9月22日

著者: Lalitkumar Dudhe / Unica Technical Support Consultant

画像の説明

テンプレートとは、Journeyから保存されたタッチポイントやコントロールのグループのことです。テンプレートを使用すると、1つまたは複数のJourneyを一度だけ設計・構成し、テンプレートとしてエクスポートできます。テンプレートには、データ定義、エントリーソースマッピング、使用されたコントロールやタッチポイントなどの設定が保存され、どのJourney環境でもインポートすれば利用できるようになります。

HCL Unica Journeyバージョン12.1.1のリリースでは、ジャーニーのエクスポートとインポートの機能が提供されています。これにより、ジャーニーの開発は、本番ではない別の環境で行うことができるようになりました。テストのサインオフ後に同じものを本番環境に複製する必要がありますが、完全に手直しする必要はありません。

この機能の主な利点は以下の通りです。

  • 開発は非生産環境で行えます。これにより、本番環境をクリーンに保てます。
  • 非本番環境から本番環境にジャーニーを移行する際、リワードは必要ありません。
  • それはちょうどワンクリックプロセスのジャーニーの移行です。
前提条件

この機能を利用するための唯一の要件は、移行元と移行先のHCL Unica Journeyのバージョンが12.1.1であることです。構成上、この機能を有効にするための設定はありません。

プロセス

以下は、HCL Unica Journeyでジャーニーをエクスポートおよびインポートするための手順です。

  1. ソース環境で、別のJourney環境に移行する必要のあるJourneyにナビゲートします。移行するJourneyは、どのような状態(Published、Draft、Paused、Completed)でもOKです。

  2. 以下のスクリーンショットのように、「More Actions」をクリックし、「Export Journey」をクリックします。

画像の説明

  1. このアクションでは、2つのファイルが作成されます。1つはZIPファイルで、Entry Sourceに関連する.csvファイル、ジャーニーの実際のロジックである.serファイル、エクスポートされたジャーニーのメタデータを含むJourneyMetaDataファイルが含まれていると予想されます。2番目にエクスポートされるファイルは.crcファイルです。

  2. ジャーニーをターゲットのJourney環境にインポートする必要がある場合は、Journeysセクションに移動し、「Import Journey」ボタンをクリックします。

画像の説明

  1. 次のダイアログボックスで、エクスポート操作中に作成されたファイル(.zipと.crc)の両方を選択します。

:zipファイルのみ、またはcrcファイルのみを選択した場合は、「Select at least 2 files to proceed(続行するには少なくとも2つのファイルを選択してください)」というエラーメッセージが表示されます。

  1. インポート操作が完了すると、Journey が作成され、以下のように Draft 状態になっていることが確認できます。

画像の説明

  1. インポートのたびに、以下の詳細がソースジャーニーからターゲットジャーニーにコピーされます。
  • エントリソースはソースシステムと同じですが、新しいエントリソースコードが作成されます。
  • ソースシステムと同じデータ定義は、新しいデータ定義コードで作成されます。
  • ジャーニー - フォルダ構造、名前や説明などのジャーニーの詳細がコピーされます。すべてのリンクおよび配信タッチポイント - 名前と説明がコピーされますが、リンク・インスタンスがターゲット環境で異なる可能性があるため、タッチポイントは未構成のままとなります。メールテンプレートは、Deliver にはそれぞれ割り当てられません。
  • エンゲージメント・スプリット - インポート後にDeliverタッチポイントにテンプレートが割り当てられないため、Deliverの場合はリンククリックのドロップダウンを除き、すべての詳細がコピーされます。
  • ジャーニーのマイルストーンがコピーされます。各マイルストーンに関連するエントリーソースは、マイルストーンの条件とともにコピーされます。
  • すべてのジャーニーゴールがコピーされます。Deliverの場合、リンククリックのドロップダウンはコピーされません。
  • Journey De-Duplicationの設定はそのままコピーされます。

:オファー統合設定やパーティション設定はコピーされません。

  • 一度にエクスポートできるJourneyは1つだけです。ただし、エクスポートした同じファイルを使って、ターゲットシステムで複数回ジャーニーをインポートできます。(ただし、同じエクスポートされたファイルを使って、ターゲットシステムでジャーニーを複数回インポートすることは可能です。)

:JourneyにCRMタッチポイントが設定されていて、そこに目標が設定されている場合。ジャーニーをターゲットシステムにインポートする際、ゴールの編集ページにエラーなくアクセスするためには、CRMタッチポイントをターゲットシステムで再度設定する必要があります。

以上が、ある環境から別の環境にJourneyを移行するための簡単な手順です。


HCL Software、PEAK Matrix社のデジタル・エクスペリエンス・プラットフォーム (DXP) ベンダー・プロバイダー・レポートでリーダーに選出される

2021/9/23 - 読み終える時間: ~1 分

HCL Software ではポータルプラットフォームとして HCL Digital Experience (DX) 製品を開発・販売しています。

この度、PEAK Matrix社のデジタル・エクスペリエンス・プラットフォーム (DXP) ベンダー・プロバイダー・レポートでリーダーに選出されました。ニュースリリースを出しましたのでご覧ください。

ニュース: HCL Software、PEAK Matrix社のデジタル・エクスペリエンス・プラットフォーム (DXP) ベンダー・プロバイダー・レポートでリーダーに選出される


HCL Nomad Web 1.0.1 をリリースしました

2021/9/17 - 読み終える時間: ~1 分

2021年9月17日、HCL Nomad Web がダウンロードできるようになりました。今回のリリースでは日本語IMEに対応し、日本語環境でも利用できるようになりました。

  • パッケージ名: HCL_Nomad_Web_1.0x
  • 名称: HCL Nomad for web browsers 1.0.1

1.0.1 のリリースに合わせてリリース情報や制限事項のドキュメントを更新しています。リリース情報の中に、新機能や制限事項等の情報が記載されています。

HCL Nomad Web の製品ページ も更新しましたのでご覧ください。

画像の説明


このブログについて

HCL Japan の Software 部門の複数担当者で HCL Software 全般について記しています。

Tags

Academy Accelerate Accelerator Actian Aftermarket Cloud Ambassador AoC AppDev Pack AppScan ASoC BigFix BigFix Workspace CAA CDP Clara Client Applicatin Access Cloud Native Commerce Common Local License Server Compass Connections Connnections CVE-2021-44228 DevOpes Velocity DevOps DevOps Code ClearCase DevOps Code RealTime DevOps Deploy DevOps.Launch.AppScan DevOps Model RealTim DevOps Model RealTime DevOps Plan DevOps Test DevOps Velocity Digital Experience Discover Domino Domino Leap Domino Volt Domino管理者アップデート認定試験対策 DQL DRYiCE DX Enterprise Integrator event General HCAA HCL Ambassador HCL Ambassadors HCL Domino REST API HCL OneTest Embedded HCL Z and I Emulator HCL Z and I Emulator for Transformation HCLSoftware U Hero history HTMO iAutomate iControl iNotes IZSAM KEEP Launch Launch.DevOps Leap Link MarvelClient Model Realtime nds2019 ndv12beta Nippon Noets/Domino Nomad Nomad Mobile Nomad Web notes Notes/Domino notes-domino-9-10-limited-supportability-as-of-202204 Notes/Domino V12 Notes/Domion notescons Now OneDB OneTest OnTime REST RTist SafeLinx Sametime SoFy Total Experience Traveler Traveler for Microsoft Outlook Unica Unica Discover Unica Interact UrbanCode Deploy UrbanCode Velocity Velocity Verse VersionVault Volt Volt MX Volt MX Go Volt MX サンプルアプリ Wordload Automation Workload Automation youtube Z Z Abend Investigator Z and I Emulator Z and I Emulator for Transformation Z and I Emulator for Web Z and I Emulator for Web Client Z Asset Optimizer Z Data Tools Z Software Asset Manager ZAI ZAO ZIE ZIE for Transformation ZIE for Web ZIE for Windows ZIET ZIETrans ZIEWeb イベント ガイド クラウド サポート サポート技術情報 サポート終了 セキュリティ セキュリティー セキュリティー脆弱性 テクてく Lotus 技術者夜会 ニュース ノーツコンソーシアム パートナー ライセンス 九州地区 Notes パートナー会 出荷日 研修