WebOTX Manual V10.4 (第4版) 目次を表示

---

6. コンフィグレーション

本章では、WebOTX Portalに関する設定項目について説明します。

属性値の取得・設定を行なうには次の方法があります。

• 運用管理ツールより設定
• 運用管理コマンド(otxadmin)により設定

運用管理ツール、運用管理コマンドの操作方法については、[ 運用管理コンソール ] や [ 統合運用管理ツール(WebOTX Administrator) ]、[ 運用管理コマンド(otxadmin) ] を参照してください。

設定項目に関する詳細は、[ 6. 付録 > 6.1. MO定義リファレンス ] を参照してください。

6.1. 各種設定

ここでは、WebOTX Portalの各種設定項目について説明します。

6.1.1. ポータルに関する設定

Dotted-name：server.portal

6.1.2. ストレージに関する設定

Dotted-name：server.portal.portal-storage

ストレージに対する基本的な設定のプロパティ

分散キャッシュに関するプロパティ

6.1.3. 永続ユニットに関する設定

Dotted-name：server.portal.portal-storage.persistence-unit.<永続ユニット名>

永続ユニットに関するプロパティ

6.1.4. ディレクトリサーバに関する設定

Dotted-name：server.portal.directory-server

(※1)設定ファイル上には暗号化された文字列が格納されます。
チューニング方法については、Windowsの場合は [インストールガイド(Windows版) > 3. インストール方法 > WebOTX Portalのインストール後の作業 > EnterpriseDirectoryServerへの接続設定] を、Linuxの場合は [インストールガイド(Linux版) > 4. インストール > 4.3. インストール後の作業 > 4.3.8. EDSへの接続設定] を参照してください。

Caution
"password"が空の状態では通信できませんので、必ず設定してください。また、"password"を既定値から変更した場合、EDS上の次のDNのエントリのuserPassword属性値も変更する必要があります。
DN : uid="portaluser" ,ou="config" ,o="webotxportal" , c="JP"

6.1.5. アクセス権に関する設定

Dotted-name：server.portal.access-control

6.2. 設定ファイル情報

ここでは、運用管理コマンド、統合運用管理ツールから設定できない項目にについて説明します。

6.2.1. 認証連携ポートレットの設定

以前のバージョンでは認証連携ポートレットで使用する認証連携サービスをファイルで設定する必要がありましたが、WebOTX Portal V9.1ではコマンドで設定します。
詳細は[ コマンドリファレンスガイド > 1. ポータル > 1.1. 運用ツール > 1.1.15. ポートレットで利用可能な認証連携サービスの登録 ]を参照してください。

6.2.2. メニューポートレットの設定

MenuPortlet.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/portlet/webotx-portal-portlet/MenuPortlet/MenuPortlet.properties

メニューポートレットに関する設定を行うファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

6.2.3. RSSリーダーポートレットの設定

RssPortlet.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/portlet/webotx-portal-rssportlet/RssPortlet.properties

RSSリーダーポートレット特有の設定を行います。

portlet.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/portlet/portlet.properties

ポートレットで共通の設定を行うファイルです。HTTP通信やプロキシサーバに関する設定を行います。

6.2.4. ポートレット基盤の設定

container.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/portletbase/container.properties

ポートレット基盤の設定を行うファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

6.2.5. 認証連携サービスの設定

AuthenticationLinkConfiguration.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/authentication/AuthenticationLinkConfiguration.properties

認証連携サービスに関する設定を行うファイルです。通常は、変更不要です。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

AuthenticationLinkWebConfiguration.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/authentication/AuthenticationLinkWebConfiguration.properties

認証連携サービスのHTTP(S)通信に関する設定を行うファイルです。通常は、変更不要です。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

6.2.6. 認証の設定

PortalConfiguration.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/authentication/PortalConfiguration.properties

WebOTX Portalの認証に関する設定を行うファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）、もしくはPortalConfiguration.properties の再読み込みコマンドの実行が必要となります。

common-session.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/common/common-session.properties

WebOTX Portalの認証に関する設定を行うファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

client-config.xml

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/common/client-config.xml

WebOTX Portalの認証に関する設定を行うファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

6.2.7. 認証委譲機能の設定

SSOConfiguration.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/authentication/SSOConfiguration.properties

WebOTX Portalの認証委譲機能に関する設定を行うファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

6.2.8. 画像の設定

6.2.8.1. ロゴの設定

6.2.8.2. faviconの設定

6.2.9. 表示文字列の設定

displaystrings.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/resources/words/displaystrings.properties

WebOTX Portalに表示される一部の文字列を変更するための設定ファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

• ファイルパスに示すパスが存在しない場合は、フォルダ/ファイルを作成してください。
• ファイル保存時の文字コードは UTF-8(BOMなし) で保存してください。

Memo
WebOTX Portal V8.3 からアップグレードした場合は、組織ツリーのトップノードに表示される文字列「組織」（日本語）/「Organization」（英語）が、前述の既定値に変更されます。本製品バージョンでも旧バージョンと同様の表示を行う場合は、以下の設定を行ってください。
com.nec.webotx.portal.rootnode.single-company.string.ja=組織
com.nec.webotx.portal.rootnode.single-company.string.en=Organization

Memo
マルチテナント環境で本設定を行う場合は、表示文字列を変更したい会社ごとに設定ファイルを作成してください。
ファイル名は以下の形式で作成する必要があります。
displaystrings.<会社ID>.properties
<会社ID> 部分にはディレクトリサーバ(EDS)で設定した会社IDを設定してください。

6.2.10. ログインポートレットの設定

LoginConfiguration.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/authentication/LoginConfiguration.properties

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

6.2.11. ゲストユーザの設定

ゲストユーザとは、ログイン前画面を使用するための仮想ユーザです。認証前にログイン前画面にアクセスした場合、ゲストユーザとして扱われます。
ゲストユーザのアカウントは、EDSとは別に下記のファイルで管理されます。

AnonymousUserDefault.properties

ファイルパス：${WEBOTX_INSTANCE_ROOT}/config/portal/directoryserver/AnonymousUserDefault.properties

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセスグループの再起動）が必要となります。

6.2.12. お知らせポートレットの設定

AnnouncePortlet.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/portlet/webotx-portal-announceportlet/AnnouncePortlet.properties

お知らせポートレットの基本動作に関する設定を行うファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセルグループの再起動）が必要となります。

Priority.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/portlet/webotx-portal-announceportlet/Priority.properties

お知らせポートレットの重要度に関する設定を行うファイルです。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセルグループの再起動）が必要となります。

6.2.13. 任意スキーマの設定

config.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/directoryserver/config.properties

ユーザリソース全般の設定を行うファイルです。ここでは任意スキーマ機能に関係する設定項目について説明します。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセルグループの再起動）が必要となります。

CustomSchemaConfiguration.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/directoryserver/CustomSchemaConfiguration.properties

ユーザリソース 任意スキーマ機能のスキーマ定義に関する設定を行うファイルです。
(※標準のスキーマ構成に従うディレクトリサーバを用いて WebOTX Portal を運用する場合、本設定ファイルは必要ありません)

接続先ディレクトリサーバのスキーマ構成が WebOTX Portal の定める標準の構成と異なっている場合は、 上記ファイルパスと同じフォルダにある CustomSchemaConfiguration.properties.sample というファイルを雛形として、 接続先ディレクトリサーバのスキーマ構成に合わせて本設定ファイルを作成してください。

設定の変更を有効にするためにはWebOTXドメインの再起動（Advancedモードの場合はプロセルグループの再起動）が必要となります。

6.2.14. グラフ表示ポートレット/地図表示ポートレットの設定

DataviewPortlet.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/portlet/webotx-portal-dataviewportlet/DataviewPortlet.properties

グラフ表示ポートレット/地図表示ポートレットに関する設定を行うファイルです。

設定の変更を有効にするには WebOTX ドメインを再起動（Advanced モードの場合はプロセスグループを再起動）してください。

File.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/portlet/webotx-portal-dataviewportlet/File.properties

グラフ表示ポートレット/地図表示ポートレットが利用する CSV ファイルに関する設定を行うファイルです。

設定の変更を有効にするためには WebOTX ドメインの再起動（Advanced モードの場合はプロセスグループの再起動）が必要となります。

MapData.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/portlet/webotx-portal-dataviewportlet/MapData.properties

地図表示ポートレットが利用する地図データファイルに関する設定を行うファイルです。

設定の変更を有効にするためには WebOTX ドメインの再起動（Advanced モードの場合はプロセスグループの再起動）が必要となります。

6.2.15. 生体認証のログイン情報の設定

LoginPortlet.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/portlet/webotx-portal-loginportlet/LoginPortlet.properties

生体認証でログインするための設定を行うファイルです。

設定の変更を有効にするには WebOTX ドメインを再起動（Advanced モードの場合はプロセスグループを再起動）してください。

6.2.16. 認証方式設定

PortalConfiguration.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/authentication/PortalConfiguration.properties

システム認証方式の設定を行うファイルです。

設定の変更を有効にするには WebOTX ドメインを再起動（Advanced モードの場合はプロセスグループを再起動）してください。

ユーザ認証方式で認証を行う場合は、EDSに設定を行います。

6.2.17. 顔認証(NeoFace Monitor)ユーザカスタム設定

NFMLoginPortlet.properties

ファイルパス：${INSTANCE_ROOT}/config/portal/portlet/webotx-portal-loginportlet/NFMLoginPortlet.properties

顔認証(NeoFace Monitor)のクライアントAPIを呼び出すために必要な情報の設定を行うファイルです。

設定の変更を有効にするには WebOTX ドメインを再起動（Advanced モードの場合はプロセスグループを再起動）してください。

6.3. 分散キャッシュの利用

ここでは、分散キャッシュに関する設定について説明します。

WebOTX Portalの分散キャッシュでは、キャッシュの更新通知を分散システム内でブロードキャストするためにEhcacheを利用し、通知手段としてJMSを採用しています。 分散キャッシュを利用する場合は、JMS関連の設定も必要となります。

6.3.1. 分散キャッシュ利用設定

ここでは、分散キャッシュ利用時に必要となる設定について説明します。 更新通知に利用するJMSサーバは、JMSサーバクラスタ構成とすることも可能です。分散システム内の全ドメインのJMSサーバをJMSサーバクラスタ構成とし、各ドメインの分散キャッシュからはローカルのJMSサーバに接続することによって、WebOTXドメインの起動順序を意識する必要がなくなります。

以下では、JMSサーバクラスタを利用しない場合と、利用する場合に分けて設定手順を説明します。JMSサーバクラスタを利用していない環境から、JMSサーバクラスタを利用するように変更するための手順は、「5.3.3.1. JMSサーバクラスタの設定追加」を参照してください。

6.3.1.1. JMSサーバクラスタ利用なし

JMSサーバクラスタを利用しない場合は、更新通知に利用するJMSサーバを1つ決定し、次の手順に従ってJMS関連の設定を行ってください。

1. JMSサーバ上にTopicと、Queueの物理的な送信先を作成します。先に決定した、更新通知に利用するJMSサーバ(分散システム内で一つ)に対して作成します。送信先名は任意です。

   Topic：

   otxadmin> create-jmsdest --desttype topic <送信先名>
   

   Queue：

   otxadmin> create-jmsdest --desttype queue <送信先名>
   

   例) 物理的な送信先名を、portalTopic(Topic)、portalQueue(Queue)として作成する場合

   otxadmin> create-jmsdest --desttype topic portalTopic
   otxadmin> create-jmsdest --desttype queue portalQueue
   

2. Topicコネクションファクトリリソースと、Queueコネクションファクトリリソースを作成します。複数のドメインが存在する場合は、すべてのドメインで作成してください。

   Topicコネクションファクトリリソース：

   otxadmin> create-jms-resource --restype javax.jms.TopicConnectionFactory --wojmsBrokerHostName <接続先のJMSサーバのホスト名> --wojmsBrokerHostPort <接続先のJMSサーバのポート番号> --wojmsAckOnAcknowledge=false --wojmsAckOnProduce=false --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 <JNDI名>
   

   Queueコネクションファクトリリソース：

   otxadmin> create-jms-resource --restype javax.jms.QueueConnectionFactory --wojmsBrokerHostName <接続先のJMSサーバのホスト名> --wojmsBrokerHostPort <接続先のJMSサーバのポート番号> --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 <JNDI名>
   

   接続先のJMSサーバのホスト名、ポート番号は、先に決定した更新通知で利用するJMSサーバが動作しているホスト名と、ポート番号を指定します。JNDI名は、それぞれ、分散キャッシュ (server.portal.portal-storage.distributedCache) の replicationTopicConnectionFactoryBindingName プロパティと、getQueueConnectionFactoryBindingName プロパティで設定した名前を指定してください。

   例) コネクションファクトリリソース名を、jms/portalTCF(TopicConnectionFactory)、jms/portalQCF(QueueConnectionFactory)とし、接続先となるJMSサーバのホスト名をhost1、ポート番号を9700として作成する場合

   otxadmin> create-jms-resource --restype javax.jms.TopicConnectionFactory --wojmsBrokerHostName host1 --wojmsBrokerHostPort 9700 --wojmsAckOnAcknowledge=false --wojmsAckOnProduce=false --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 jms/portalTCF
   otxadmin> create-jms-resource --restype javax.jms.QueueConnectionFactory --wojmsBrokerHostName host1 --wojmsBrokerHostPort 9700 --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 jms/portalQCF
   

3. TopicとQueueの送信先リソースを作成します。複数のドメインが存在する場合は、すべてのドメインで作成してください。

   送信先リソース(Topic)：

   otxadmin> create-jms-resource --restype javax.jms.Topic --wojmsDestinationName <物理的な送信先名> <JNDI名>
   

   送信先リソース(Queue)：

   otxadmin> create-jms-resource --restype javax.jms.Queue --wojmsDestinationName <物理的な送信先名> <JNDI名>
   

   物理的な送信先名は、1 で作成した送信先名を指定してください。 また、JNDI名は、それぞれ、分散キャッシュ (server.portal.portal-storage.distributedCache) の replicationTopicBindingName プロパティと、getQueueBindingName プロパティで設定した名前を指定してください。

   例) 送信先リソース名を、jms/portalTopic(Topic、物理的な送信先名：portalTopic)、jms/portalQueue(Queue、物理的な送信先名：portalQueue)として作成する場合

   otxadmin> create-jms-resource --restype javax.jms.Topic --wojmsDestinationName portalTopic jms/portalTopic
   otxadmin> create-jms-resource --restype javax.jms.Queue --wojmsDestinationName portalQueue jms/portalQueue
   

4. JMSサーバ対するプロパティと、分散キャッシュ利用の設定を行います。複数のドメインが存在する場合は、すべてのドメインに対して設定後、ドメインを再起動してください。

   otxadmin> set server.jms-service.property.wojmsConnectionPooling=false
   otxadmin> set server.portal.portal-storage.enableDistributedCache=true
   otxadmin> set server.portal.portal-storage.basicConfiguration={{com.nec.webotx.portal.storage.error.action.undefined.rule,default},{com.nec.webotx.portal.storage.error.action.not.found.key,default},{com.nec.webotx.portal.storage.cache.definition.name,cache1},{com.nec.webotx.portal.storage.default.persistence.unit.name,unit_001},{com.nec.webotx.portal.storage.cache.enabled,true},{com.nec.webotx.portal.storage.error.action.not.found.rule,default},{com.nec.webotx.portal.storage.initialize.cache,true},{com.nec.webotx.portal.storage.distributed.cache.enabled,true}}
   

   上記コマンドでは、基本設定 (basicConfiguration) に対する値は、「com.nec.webotx.portal.storage.distributed.cache.enabled」プロパティ以外、すべて既定値で設定しています。既定値を変更している場合は、それぞれ適切な値に変更して設定してください。

6.3.1.2. JMSサーバクラスタ利用あり

分散システム内の全ドメインのJMSサーバをJMSサーバクラスタ構成とし、各ドメインの分散キャッシュからはローカルのJMSサーバに接続することによって、WebOTXドメインの起動順序を意識する必要がなくなります。

ここでは、分散キャッシュの設定とJMSサーバクラスタの設定を同時に行う場合の手順について説明します。JMSサーバクラスタを利用していない環境から、 JMSサーバクラスタを利用するように変更するため手順は、「5.3.3.1. JMSサーバクラスタの設定追加」を参照してください。

ここで説明する手順は図5.3.1-1に示すとおり、分散システムを構成するドメインが3台で、そのドメイン上で動作するJMSサーバ3台をJMSサーバクラスタ構成とする場合を想定したものです。

JMSサーバクラスタを利用した分散キャッシュ設定

1. JMSサーバクラスタを構成するすべてのJMSサーバに対して、JMSサーバクラスタ利用のための設定を行います。設定内容は、すべてのJMSサーバで同一にしてください。

   otxadmin> set server.jms-service.enableCluster=true
   otxadmin> set set server.jms-service.clusterBrokerList=<ホスト1>:<ホスト1のJMSサーバのポート番号>[,<ホストn>:<ホストnのJMSサーバのポート番号>]
   

   例) host1のdomain1で起動するJMSサーバ(ポート番号:9700[デフォルト])と、host2のdomain1で起動するJMSサーバ(ポート番号:9700[デフォルト])、host3のdomain1で起動するJMSサーバ(ポート番号:9700[デフォルト])でJMSサーバクラスタを構成する場合

   otxadmin> set server.jms-service.enableCluster=true
   otxadmin> set server.jms-service.clusterBrokerList=host1:9700,host2:9700,host3:9700
   

2. 1 で対象としたすべてのJMSサーバに対して、TopicとQueueの物理的な送信先を作成します。

   Topic：

   otxadmin> create-jmsdest --desttype topic <送信先名>
   

   Queue：

   otxadmin> create-jmsdest --desttype queue <送信先名>
   

   例) 物理的な送信先名を、portalTopic(Topic)、portalQueue(Queue)として作成する場合

   otxadmin> create-jmsdest --desttype topic portalTopic
   otxadmin> create-jmsdest --desttype queue portalQueue
   

3. Topicコネクションファクトリリソースと、Queueコネクションファクトリリソースを作成します。複数のドメインが存在する場合は、すべてのドメインで作成してください。 コネクションファクトリリソースの接続先はJMSホストのMOで設定されているものとなり、デフォルトはローカルドメインのJMSサーバとなります。通常はデフォルトのままで問題ありません。

   Topicコネクションファクトリリソース：

   otxadmin> create-jms-resource --restype javax.jms.TopicConnectionFactory --wojmsAckOnAcknowledge=false --wojmsAckOnProduce=false --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 <JNDI名>
   

   Queueコネクションファクトリリソース：

   otxadmin> create-jms-resource --restype javax.jms.QueueConnectionFactory --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 <JNDI名>
   

   JNDI名は、それぞれ、分散キャッシュ (server.portal.portal-storage.distributedCache) の replicationTopicConnectionFactoryBindingName プロパティと、getQueueConnectionFactoryBindingName プロパティで設定した名前を指定してください。

   例) コネクションファクトリリソース名を、jms/portalTCF(TopicConnectionFactory)、jms/portalQCF(QueueConnectionFactory)として作成する場合

   otxadmin> create-jms-resource --restype javax.jms.TopicConnectionFactory --wojmsAckOnAcknowledge=false --wojmsAckOnProduce=false --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 jms/portalTCF
   otxadmin> create-jms-resource --restype javax.jms.QueueConnectionFactory --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 jms/portalQCF
   

   Memo
   JMSホストのMOに設定されているホスト名は、次のコマンドで確認できます。

   otxadmin> get server.jms-service.jms-host.default_JMS_host.host
   

   
   
4. TopicとQueueの送信先リソースを作成します。複数のドメインが存在する場合は、すべてのドメインで作成してください。

   送信先リソース(Topic)：

   otxadmin> create-jms-resource --restype javax.jms.Topic --wojmsDestinationName <物理的な送信先名> <JNDI名>
   

   送信先リソース(Queue)：

   otxadmin> create-jms-resource --restype javax.jms.Queue --wojmsDestinationName <物理的な送信先名> <JNDI名>
   

   物理的な送信先名は、1 で作成した送信先名を指定してください。 また、JNDI名は、それぞれ、分散キャッシュ (server.portal.portal-storage.distributedCache) の replicationTopicBindingName プロパティと、getQueueBindingName プロパティで設定した名前を指定してください。

   例) 送信先リソース名を、jms/portalTopic(Topic、物理的な送信先名：portalTopic)、jms/portalQueue(Queue、物理的な送信先名：portalQueue)として作成する場合

   otxadmin> create-jms-resource --restype javax.jms.Topic --wojmsDestinationName portalTopic jms/portalTopic
   otxadmin> create-jms-resource --restype javax.jms.Queue --wojmsDestinationName portalQueue jms/portalQueue
   

5. JMSサーバ対するプロパティと、分散キャッシュ利用の設定を行います。複数のドメインが存在する場合は、すべてのドメインに対して設定後、ドメインを再起動してください。

   otxadmin> set server.jms-service.property.wojmsConnectionPooling=false
   otxadmin> set server.portal.portal-storage.enableDistributedCache=true
   otxadmin> set server.portal.portal-storage.basicConfiguration={{com.nec.webotx.portal.storage.error.action.undefined.rule,default},{com.nec.webotx.portal.storage.error.action.not.found.key,default},{com.nec.webotx.portal.storage.cache.definition.name,cache1},{com.nec.webotx.portal.storage.default.persistence.unit.name,unit_001},{com.nec.webotx.portal.storage.cache.enabled,true},{com.nec.webotx.portal.storage.error.action.not.found.rule,default},{com.nec.webotx.portal.storage.initialize.cache,true},{com.nec.webotx.portal.storage.distributed.cache.enabled,true}}
   

   上記コマンドでは、基本設定 (basicConfiguration) に対する値は、「com.nec.webotx.portal.storage.distributed.cache.enabled」プロパティ以外、すべて既定値で設定しています。既定値を変更している場合は、それぞれ適切な値に変更して設定してください。

otxadmin> list-jms-services
------------------------------------------------------------
Broker ID Address                               State
------------------------------------------------------------
          host1:9700                            OPERATING
          host2:9700                            OPERATING
          host3:9700                            OPERATING
コマンド list-jms-services は正常に実行されました。

6.3.2. 分散キャッシュ設定解除

ここでは、分散キャッシュの設定を解除する方法について説明します。

6.3.2.1. JMSサーバクラスタ利用なし

ここでは、JMSサーバクラスタを利用していないときに、分散キャッシュの設定を解除する方法について説明します。

1. 分散キャッシュ機能を無効化します。

   otxadmin> invoke server.portal.portal-storage.disableCache
   

2. JMSサーバ対するプロパティを削除し、分散キャッシュの設定を解除します。複数のドメインが存在する場合は、すべてのドメインに対して設定後、ドメインを再起動してください。

   otxadmin> set server.jms-service.property.wojmsConnectionPooling=
   otxadmin> set server.portal.portal-storage.enableDistributedCache=false
   otxadmin> set server.portal.portal-storage.basicConfiguration={{com.nec.webotx.portal.storage.error.action.undefined.rule,default},{com.nec.webotx.portal.storage.error.action.not.found.key,default},{com.nec.webotx.portal.storage.cache.definition.name,cache1},{com.nec.webotx.portal.storage.default.persistence.unit.name,unit_001},{com.nec.webotx.portal.storage.cache.enabled,true},{com.nec.webotx.portal.storage.error.action.not.found.rule,default},{com.nec.webotx.portal.storage.initialize.cache,true},{com.nec.webotx.portal.storage.distributed.cache.enabled,false}}
   

   上記コマンドでは、基本設定 (basicConfiguration) に対する値は、「com.nec.webotx.portal.storage.distributed.cache.enabled」プロパティ以外、すべて既定値で設定しています。既定値を変更している場合は、それぞれ適切な値に変更して設定してください。
   

3. 更新通知で利用するJMSサーバ上に存在するTopicと、Queueの物理的な送信先を削除します。

   otxadmin> delete-jmsdest <送信先名>
   

   削除の場合、Topic、Queueともに同じコマンドです。

   例) 送信先名が、portalTopic(Topic)、portalQueue(Queue)である物理的な送信先を削除する場合

   otxadmin> delete-jmsdest portalTopic
   otxadmin> delete-jmsdest portalQueue
   

4. Topicコネクションファクトリリソースと、Queueコネクションファクトリリソースを削除します。複数のドメインが存在する場合は、すべてのドメインで削除してください。

   otxadmin> delete-jms-resource <JNDI名>
   

   削除の場合、Topicコネクションファクトリリソース、Queueコネクションファクトリリソースともに同じコマンドです。

   例) コネクションファクトリリソース名が、jms/portalTCF(TopicConnectionFactory)、jms/portalQCF(QueueConnectionFactory)であるコネクションファクトリリソースを削除する場合

   otxadmin> delete-jms-resource jms/portalTCF
   otxadmin> delete-jms-resource jms/portalQCF
   

5. TopicとQueueの送信先リソースを削除します。複数のドメインが存在する場合は、すべてのドメインで削除してください。

   otxadmin> delete-jms-resource <JNDI名>
   

   削除の場合、Topic、Queueの送信先リソースともに同じコマンドです。

   例) 送信先リソース名が、jms/portalTopic(Topic)、jms/portalQueue(Queue)である送信先リソースを削除する場合

   otxadmin> delete-jms-resource jms/portalTopic
   otxadmin> delete-jms-resource jms/portalQueue
   

6.3.2.2. JMSサーバクラスタ利用あり

ここでは、分散キャッシュとJMSサーバクラスタの設定解除を同時に行う場合の手順について説明します。なお、分散キャッシュの設定は残したまま、JMSサーバクラスタ設定のみを解除する手順については、「5.3.3.2. JMSサーバクラスタの設定解除」を参照してください。

1. 分散キャッシュ機能を無効化します。

   otxadmin> invoke server.portal.portal-storage.disableCache
   

2. JMSサーバ対するプロパティを削除し、分散キャッシュの設定を解除します。

   otxadmin> set server.jms-service.property.wojmsConnectionPooling=
   otxadmin> set server.portal.portal-storage.enableDistributedCache=false
   otxadmin> set server.portal.portal-storage.basicConfiguration={{com.nec.webotx.portal.storage.error.action.undefined.rule,default},{com.nec.webotx.portal.storage.error.action.not.found.key,default},{com.nec.webotx.portal.storage.cache.definition.name,cache1},{com.nec.webotx.portal.storage.default.persistence.unit.name,unit_001},{com.nec.webotx.portal.storage.cache.enabled,true},{com.nec.webotx.portal.storage.error.action.not.found.rule,default},{com.nec.webotx.portal.storage.initialize.cache,true},{com.nec.webotx.portal.storage.distributed.cache.enabled,false}}
   

   上記コマンドでは、基本設定 (basicConfiguration) に対する値は、「com.nec.webotx.portal.storage.distributed.cache.enabled」プロパティ以外、すべて既定値で設定しています。既定値を変更している場合は、それぞれ適切な値に変更して設定してください。
   

3. Topicコネクションファクトリリソースと、Queueコネクションファクトリリソースを削除します。複数のドメインが存在する場合は、すべてのドメインで削除してください。

   otxadmin> delete-jms-resource <JNDI名>
   

   削除の場合、Topicコネクションファクトリリソース、Queueコネクションファクトリリソースともに同じコマンドです。

   例) コネクションファクトリリソース名が、jms/portalTCF(TopicConnectionFactory)、jms/portalQCF(QueueConnectionFactory)であるコネクションファクトリリソースを削除する場合

   otxadmin> delete-jms-resource jms/portalTCF
   otxadmin> delete-jms-resource jms/portalQCF
   

4. TopicとQueueの送信先リソースを削除します。複数のドメインが存在する場合は、すべてのドメインで削除してください。

   otxadmin> delete-jms-resource <JNDI名>
   

   削除の場合、Topic、Queueの送信先リソースともに同じコマンドです。

   例) 送信先リソース名が、jms/portalTopic(Topic)、jms/portalQueue(Queue)である送信先リソースを削除する場合

   otxadmin> delete-jms-resource jms/portalTopic
   otxadmin> delete-jms-resource jms/portalQueue
   

5. JMSサーバクラスタ設定を解除します。すべてのJMSサーバに対して設定後、ドメインを再起動してください。

   otxadmin> set server.jms-service.enableCluster=false
   otxadmin> set server.jms-service.clusterBrokerList=
   

6. 更新通知で利用するJMSサーバ上に存在するTopicと、Queueの物理的な送信先を削除します。

   otxadmin> delete-jmsdest <送信先名>
   

   削除の場合、Topic、Queueともに同じコマンドです。

   例) 送信先名が、portalTopic(Topic)、portalQueue(Queue)である物理的な送信先を削除する場合

   otxadmin> delete-jmsdest portalTopic
   otxadmin> delete-jmsdest portalQueue
   

6.3.3. JMSサーバクラスタの設定と解除

6.3.3.1. JMSサーバクラスタの設定追加

既に分散キャッシュの設定を行っている場合に、更新通知に利用するJMSサーバをJMSサーバクラスタ構成に変更するための手順について説明します。

JMSサーバクラスタの設定追加

1. JMSサーバが起動していることを確認します。jms-pingコマンドを実行して「RUNNING」と表示されれば起動しています。起動していない場合は、start-jmsコマンドにより起動してください。

   otxadmin> jms-ping
   JMS Ping Status = RUNNING
   コマンド jms-ping は正常に実行されました。
   

2. コネクションファクトリリソースのJMSサービスの接続先をローカルホストに変更します。分散構成のすべてのコネクションファクトリリソースを変更してください。

   otxadmin> set server.resources.jms-resource.jms-connection-factory.<JNDI名>.wojmsBrokerHostName=localhost
   

   例) コネクションファクトリリソース名が、jms/portalTCF(TopicConnectionFactory)、jms/portalQCF(QueueConnectionFactory)であるコネクションファクトリリソースの接続先をlocalhostにする場合

   otxadmin> set server.resources.jms-resource.jms-connection-factory.jms/portalTCF.wojmsBrokerHostName=localhost
   otxadmin> set server.resources.jms-resource.jms-connection-factory.jms/portalQCF.wojmsBrokerHostName=localhost
   

3. JMSサーバクラスタを構成するすべてのJMSサーバに対して、JMSサーバクラスタ利用のための設定を行います。設定内容は、すべてのJMSサーバで同一にしてください。

   otxadmin> set server.jms-service.enableCluster=true
   otxadmin> set set server.jms-service.clusterBrokerList=<ホスト1>:<ホスト1のJMSサーバのポート番号>[,<ホストn>:<ホストnのJMSサーバのポート番号>]
   

   例) host1のdomain1で起動するJMSサーバ(ポート番号:9700[デフォルト])と、host2のdomain1で起動するJMSサーバ(ポート番号:9700[デフォルト])、host3のdomain1で起動するJMSサーバ(ポート番号:9700[デフォルト])でJMSサーバクラスタを構成する場合

   otxadmin> set server.jms-service.enableCluster=true
   otxadmin> set server.jms-service.clusterBrokerList=host1:9700,host2:9700,host3:9700
   

4. 3 で対象としたすべてのJMSサーバに対して、TopicとQueueの物理的な送信先を作成します。ただし、既に作成済みのJMSサーバでは、再作成する必要はありません。

   Topic：

   otxadmin> create-jmsdest --desttype topic <送信先名>
   

   Queue：

   otxadmin> create-jmsdest --desttype queue <送信先名>
   

   例) 物理的な送信先名を、portalTopic(Topic)、portalQueue(Queue)として作成する場合

   otxadmin> create-jmsdest --desttype topic portalTopic
   otxadmin> create-jmsdest --desttype queue portalQueue
   

5. ドメインを再起動します。

6.3.3.2. JMSサーバクラスタの設定解除

ここでは、分散キャッシュの更新通知で利用していたJMSサーバクラスタ設定を解除し、1つのドメインのJMSサーバを利用する設定に変更するための手順について説明します。

MSサーバクラスタの設定解除

1. Topicコネクションファクトリリソースと、Queueコネクションファクトリリソースの接続先を、更新通知で利用するJMSサーバが動作するホスト、ポート番号に変更します。分散構成のすべてのコネクションファクトリリソースを変更してください。

   otxadmin> set server.resources.jms-resource.jms-connection-factory.<JNDI名>.wojmsBrokerHostName=<接続先のJMSサーバのホスト名>
   otxadmin> set server.resources.jms-resource.jms-connection-factory.<JNDI名>.wojmsBrokerHostPort=<接続先のJMSサーバのポート番号>
   

   例) コネクションファクトリリソース名が、jms/portalTCF(TopicConnectionFactory)、jms/portalQCF(QueueConnectionFactory)であるコネクションファクトリリソースの接続先をhost2にする場合(ポート番号変更なし)

   otxadmin> set server.resources.jms-resource.jms-connection-factory.jms/portalTCF.wojmsBrokerHostName=host2
   otxadmin> set server.resources.jms-resource.jms-connection-factory.jms/portalQCF.wojmsBrokerHostName=host2
   

2. JMSサーバクラスタ設定を解除します。すべてのJMSサーバに対して設定後、ドメインを再起動してください。起動順序は、更新通知で利用するJMSサーバが動作するドメインを最初に起動する必要があります。

   otxadmin> set server.jms-service.enableCluster=false
   otxadmin> set server.jms-service.clusterBrokerList=
   

3. 更新通知で利用しないJMSサーバ上に存在するTopicと、Queueの物理的な送信先を削除します。

   otxadmin> delete-jmsdest <送信先名>
   

   削除の場合、Topic、Queueともに同じコマンドです。

   例) 送信先名が、portalTopic(Topic)、portalQueue(Queue)である物理的な送信先を削除する場合

   otxadmin> delete-jmsdest portalTopic
   otxadmin> delete-jmsdest portalQueue
   

6.4. 認証連携サービス

本章では、WebOTX Portal の機能の1つである認証連携サービスについて説明します。

6.4.1. はじめに

認証連携サービスとは、WebOTX Portalの画面から他のアプリケーションへの 簡易的なシングルサインオン環境を構築するためのサービスです。

認証連携サービスを利用すると、WebOTX Portalの画面上に表示されているリンクから、 ID・パスワードを再入力することなく、様々なWebアプリケーションの認証後の 画面を直接表示することができます。

なお、認証連携サービスを利用してWebOTX Portalの画面から起動できる "他のアプリケーション" とは、 "認証画面がHTML formで作られたWebアプリケーション" のことを指します。

認証連携サービスを利用しない場合の画面遷移

認証連携サービスを利用しない場合の画面遷移

認証連携サービスを利用した場合の画面遷移

認証連携サービスを利用した場合の画面遷移

6.4.2. 認証連携サービスの流れ

認証連携サービスは、まず指定されたサービスIDに基づいて、 連携対象のアプリケーションと連携するための情報を ディレクトリサーバ、およびデータベースサーバから取得します。

次に、ディレクトリサーバ、およびデータベースサーバから取得した情報とCGIパラメータに基づいて 連携方法と連携データを決定/生成します。

連携データはHTML formの形でWebOTX Portalユーザのブラウザに渡され、 ブラウザは連携対象アプリケーションに自動認証する処理を実行します。 自動認証する処理とは、 例えば連携対象のアプリケーションがWebアプリケーションの場合は、 そのアプリケーションの認証用ページに ユーザIDやパスワードなどの連携データのパラメータ名・値を POST(GET)する処理になります。

認証連携サービスの流れ

6.4.3. 連携データの生成

認証連携サービスは、連携対象アプリケーションに渡す ユーザID・パスワード・その他の連携データを、 運用コマンドでデータベースに登録したエントリの情報、 ディレクトリサーバに登録されたエントリの情報、 認証連携サービス呼び出し時のCGIパラメータに基づいて生成します。 ここでは、連携データがどのように作られるかを説明します。

6.4.3.1. 連携データの定義の所在

認証連携サービスは、以下の情報を使って連携データを生成します。

• (1) 運用コマンドで登録したサービスエントリ
• (2) ディレクトリサーバ上のユーザエントリのapLoginContext属性
• (3) 認証連携サービス呼び出し時のCGIパラメータ

(1) サービスエントリ

サービスエントリは、連携するアプリケーションの定義情報を 格納するためのエントリです。エントリを特定するキーとしてサービスIDが 使われます。アプリケーションに引き渡す連携データのうち、 システム全体で共通なものは、サービスエントリの属性に定義します。

サービスエントリの操作に関しては、コマンドリファレンスの 1. ポータル > 1.1. 運用ツール > 1.1.12. 認証連携Webアプリケーション登録 を参照してください。

認証連携サービスでは、起動する各アプリケーションに対して 以下の属性が必要となります。

注意
(*1) 認証サーバ連携機能を利用してWebOTX Portalの認証を行っている場合、 <PASSWORD> はポータルにログインしているユーザのパスワード情報に置換されません。

(2) apLoginContext属性

認証連携サービスでは、 ユーザ毎に異なるパラメータを利用して連携対象Webアプリケーションと 認証連携することもできます。例えば、次のような場合が該当します。

• ポータルへのログイン時とは異なるユーザIDを利用して、 連携対象アプリケーションと認証連携する
• ポータルへのログイン時とは異なるパスワードを利用して、 連携対象アプリケーションと認証連携する

このような場合には、 ディレクトリサーバ上のユーザエントリのapLoginContext属性に、 連携対象アプリケーションの単位で 認証連携時に必要な個人に依存するデータを格納することによって、 ユーザ毎に異なるパラメータを利用した認証連携を実現することができます。

ユーザエントリの操作に関しては、 2. ユーザ管理 > 2.1. ユーザリソース > 2.1.4. ユーザリソース操作 > 2.1.4.1. 個人の登録、追加、削除 を参照してください。

注意
apLoginContext属性の設定は、 ポータルログイン時に用いるユーザID/パスワードと異なるユーザID/パスワードを 使って連携対象アプリケーションの認証を行う必要がある場合のみ設定を行います。

apLoginContext属性の形式は以下の通りです。

サービスID;名前=値,名前=値, ...

サービスIDとセミコロン ';' (0x3b) に続けて、連携対象Webアプリケーションが 認証時に必要とするパラメータ名とパラメータ値を、 名前=値 の形式で指定します。

パラメータ名・パラメータ値に指定できる文字の種類や パラメータを複数指定する方法については、 サービスエントリのauthenticationItems属性と同様ですが、各パラメータの区切り文字には ',' (0x2c) を使用して下さい。

また、パラメータ値として <USERID>、<PASSWORD> が指定された場合は、サービスエントリのauthenticationItems属性と同様に、 現在ポータルにログインしているユーザ情報に置換されます。

注意
認証サーバ連携機能を利用してWebOTX Portalの認証を行っている場合、 apLoginContext属性の設定値は利用されません。

(3) CGIパラメータ

CGIパラメータは認証連携サービス呼び出し時に指定できるパラメータで、 認証連携ポートレットやメニューポートレットで設定することができます。

これらのポートレットにおけるCGIパラメータ設定方法については、 各ポートレットの説明を参照してください。

• 4. ビルトインポートレットの利用 > 4.5. 認証連携ポートレット > 4.5.2. ポートレットの設定
• 4. ビルトインポートレットの利用 > 4.6. メニューポートレット > 4.6.2. ポートレットの設定

注意
CGIパラメータのパラメータ値に <USERID>、<PASSWORD> を指定しても、 authenticationItems属性やapLoginContext属性のように ポータルにログインしているユーザ情報に置換されません。

6.4.3.2. 連携データの優先順位

5.4.3.1. 連携データの定義の所在 で説明したとおり、 認証連携サービスは以下の情報を使って 連携対象アプリケーションに渡すパラメータ名・値を決定します。

• (1) サービスエントリのauthenticationItems属性
• (2) ユーザエントリのapLoginContext属性
• (3) 認証連携サービス呼び出し時のCGIパラメータ

(1)〜(3)のそれぞれに同じパラメータ名が定義されている場合には (3)→(2)→(1)の優先順位で使用されるパラメータが決定されます。 また、(1)には定義されていて(2)、(3)には定義されていない項目に関しては、 (1)に定義されているパラメータが有効になります。

6.4.3.3. 連携データの生成例

ここでは、連携対象Webアプリケーション「WebKeiri」を例にとり、 連携データがどのように決定/生成されるのかを説明します。

Webアプリケーション「WebKeiri」がユーザを認証するときに必要とする データとして、以下の3つを想定します。

また、WebOTX PortalにログインしているユーザのユーザIDとパスワードが 以下のようになっていると仮定します。

(1) apLoginContextを利用しない場合

連携対象アプリケーションのユーザID・パスワードが ポータルのユーザID・パスワードと同じ場合で、かつ ユーザID・パスワード以外に個人に依存する連携データが無い場合には、 サービスエントリを定義するだけで認証連携することができます。

上記のように連携データを定義した場合、 以下のパラメータ名・値が連携対象アプリケーションに渡されます。

(2) apLoginContextを利用する場合

連携対象アプリケーションのユーザID・パスワードが ポータルのユーザID・パスワードと異なっている場合や、 ユーザID・パスワード以外に個人に依存する連携データがある場合には、 個人に依存する連携データをapLoginContext属性に定義する必要があります。

authenticationItems属性とapLoginContext属性の両方に uidとpwdが定義されているため、これらのパラメータ値については apLoginContext属性の定義が使われます。 従って、上記のように連携データを定義した場合、 以下のパラメータ名・値が連携対象アプリケーションに渡されます。

6.4.4. 認証連携サービスの呼び出し方

認証連携サービスは、認証連携ポートレットやメニューポートレットから 呼び出すことができます。 これらのポートレットの使い方については、各ポートレットの説明を参照してください。

• 4. ビルトインポートレットの利用 > 4.5. 認証連携ポートレット
• 4. ビルトインポートレットの利用 > 4.6. メニューポートレット

6.4.5. 難読化エンコード機能

認証連携サービスは、 ユーザのWebブラウザに返却するHTML formのパラメータ値(本来のパラメータ値)を 特定の方法で異なるパラメータ値に変換し、 HTMLソースに記述されたパラメータ値が露出した場合でも、 "本来のパラメータ値" が何であるのかを分かりづらくします。 この機能を、難読化エンコード機能といいます。

難読化エンコードされたパラメータ値は、 ユーザのWebブラウザがHTML formを連携対象Webアプリケーションに POST(GET)する直前にデコード("本来のパラメータ値" に復元)されます。 そのため、連携対象Webアプリケーションには "本来のパラメータ値" が送信されます。

認証連携サービスの設定ファイルを編集することによって、 難読化エンコード機能の有効/無効を設定することができます。 設定変更の詳細は、5.2.5. 認証連携サービスの設定を参照してください。

6.5. ホスト名(IPアドレス)の変更

ここでは、WebOTX Portal インストール後にマシンのホスト名やIPアドレスを変更するための手順について説明します。

6.5.1. WebOTX AS の設定

まず最初に WebOTX AS 側の設定を変更します。詳細については、「環境変数・JDK・ホスト名の設定変更」−「ホスト名の変更」を参照してください。

6.5.2. ポータルサーバの設定

分散キャッシュ機能有効時の設定

分散キャッシュ機能を有効にしている場合、運用管理コマンドで Topic/Queue コネクションファクトリを再作成します。

otxadmin> delete-jms-resource jms/portalTCF
otxadmin> delete-jms-resource jms/portalQCF
otxadmin> create-jms-resource --restype javax.jms.TopicConnectionFactory --wojmsBrokerHostName <IPアドレス> --wojmsBrokerHostPort <ポート番号> --wojmsAckOnAcknowledge=false --wojmsAckOnProduce=false --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 jms/portalTCF
otxadmin> create-jms-resource --restype javax.jms.QueueConnectionFactory --wojmsBrokerHostName <IPアドレス> --wojmsBrokerHostPort <ポート番号> --wojmsPortMapperSoTimeout=10000 --wojmsSocketConnectTimeout=10000 jms/portalQCF

WebOTX AS Standard/Enterprise のアドバンスドモードを利用している場合、次のコマンドも実行します。

otxadmin> set server.resources.connector-resource.jms/portalTCF.use-jmx-agent=true
otxadmin> set server.resources.connector-resource.jms/portalQCF.use-jmx-agent=true

ユーザ個別設定の変更

その他、配備済みポートレットの設定でポータルサーバのIPアドレスやURLを指定している場合や、ユーザリソースのサービスエントリのURL設定(authenticationURL, serviceURL, listenerURL)でポータルサーバのURLを指定している場合のように、利用者が個別に設定した情報においてIPアドレスやURLを設定している場合、それを変更します。

設定変更を行った場合、ドメインを再起動します。

6.5.3. データベースサーバの設定

データベースサーバが動作するマシンのホスト名、IPアドレスを変更した場合、次の設定変更が必要です。

otxadmin> set server.resources.jdbc-datasource.jdbc/portalDataSource.serverName=<データベースサーバが動作するマシンのホスト名またはIPアドレス>

さらに、データベースサーバに Oracle を利用している場合は、次の設定変更も必要です。

otxadmin> set server.resources.jdbc-datasource.jdbc/portalDataSource.dataSourceName=jdbc:oracle:thin:@<データベースサーバが動作するマシンのホスト名またはIPアドレス>:1521:orcl

ポート番号、SIDも変更する場合は、それぞれ 1521、orcl の部分も変更して下さい。

データベースサーバ側のホスト名、IPアドレス設定変更方法については、各データベースサーバのマニュアルを参照してください。

6.5.4. EDS の設定

EDS が動作するマシンのホスト名、IPアドレスを変更した場合、運用管理コマンドにより、次の設定変更が必要です。

otxadmin> set server.portal.directory-server.servername=<EDSが動作するマシンのホスト名またはIPアドレス>
otxadmin> set server.portal.directory-server.serverport=<EDSが動作するマシンのポート番号>

さらに、EDSをマスタ−スレーブ構成とした場合、マスタサーバのIPアドレスとポート番号の設定変更も必要です。

otxadmin> set server.portal.directory-server.masterservername=<EDSマスタサーバのIPアドレス>
otxadmin> set server.portal.directory-server.masterserverport=<EDSマスタサーバのポート番号>

EDS 側のホスト名、IPアドレス設定変更方法については、EDS のマニュアルを参照してください。

6.6. 複数永続ユニットの利用

ここでは、負荷分散を目的とした、複数永続ユニットを利用する場合の設定について説明します。

同時接続クライアント数が多いときに、利用する永続ユニットが1つだと、永続ユニットで保持するエンティティのキャッシュへのアクセスがボトルネックとなる場合があります。 このようなときに、複数の永続ユニットを利用して永続ユニットの負荷分散を行うことで、性能向上が期待できます。

複数永続ユニットの利用

Caution
ここで定義する永続ユニットの接続先となるデータベースは、すべて同一でなければなりません。 また、利用可能な永続ユニットは、unit_001からunit_010までの10個です。

ここでは、設定手順とともに、永続ユニットを3つ(unit_001、unit_002、unit_003)利用することを前提としたコマンド例を記載します。

複数永続ユニット利用のための設定イメージ

1. 利用する永続ユニットを登録します。

   otxadmin> add-persistence-unit <永続ユニット名>
   

   Memo
   永続ユニット名は、unit_<3桁の数字>で指定します。unit_001はインストール時に登録されます。
   
   例) 永続ユニットunit_002、unit_003を登録する場合

   otxadmin> add-persistence-unit unit_002
   otxadmin> add-persistence-unit unit_003
   

2. 永続ユニットの定義を変更します。JDBCデータソース名などを既定値から変更している場合には、変更を行います。既定値から変更を行っていない場合は、この手順は不要です。

   otxadmin> set server.portal.portal-storage.persistence-unit.<永続ユニット名>.unitProperties={{<プロパティ名>,<設定値>}[,{<プロパティ名>,<設定値>}]}
   

   永続ユニットのプロパティについては、表 5.1.3-2を参照してください。

   例) 永続ユニットunit_002のJDBCデータソース名を「jdbc/MyDataSource」に変更する場合

   otxadmin> set server.portal.portal-storage.persistence-unit.unit_002.unitProperties={{eclipselink.cache.shared.default,true},{eclipselink.cache.type.default,SoftWeak},{javax.persistence.transactionType,RESOURCE_LOCAL},{eclipselink.cache.size.default,1000},{javax.persistence.nonJtaDataSource,jdbc/MyDataSource}}
   

   上記コマンドでは、javax.persistence.nonJtaDataSourceプロパティ以外、すべて既定値を指定しています。既定値を変更している場合は、それぞれ適切な値に変更して設定する必要があります。

3. 負荷分散ルールのタイプと、利用する永続ユニット名のリスト、振り分けキーのリストを指定します。

   otxadmin> set server.portal.portal-storage.basicConfiguration={ ... ,{com.nec.webotx.portal.storage.persistence.unit.balancing.type,<負荷分散ルールのタイプ>},{com.nec.webotx.portal.storage.addon.munit.FactoryCacheClearImpl.unit.list,<永続ユニット名のリスト>}{com.nec.webotx.portal.storage.addon.munit.StepRoundRobinRuleImpl.key.list,<任意キーのリスト>}}
   

   Memo
   設定可能な負荷分散ルールのタイプは、roudrobin のみです。
   
   例) 永続ユニットとしてunit_001、unit_002、unit_003を利用し、振り分けキーとして、key1、key2、key3を順に利用する場合

   otxadmin> set server.portal.portal-storage.basicConfiguration={{com.nec.webotx.portal.storage.error.action.undefined.rule,default},{com.nec.webotx.portal.storage.error.action.not.found.key,default},{com.nec.webotx.portal.storage.cache.definition.name,cache1},{com.nec.webotx.portal.storage.default.persistence.unit.name,unit_001},{com.nec.webotx.portal.storage.cache.enabled,true},{com.nec.webotx.portal.storage.error.action.not.found.rule,default},{com.nec.webotx.portal.storage.initialize.cache,true},{com.nec.webotx.portal.storage.distributed.cache.enabled,false},{com.nec.webotx.portal.storage.persistence.unit.balancing.type,roundrobin},{com.nec.webotx.portal.storage.addon.munit.FactoryCacheClearImpl.unit.list,"unit_001\,unit_002\,unit_003"},{com.nec.webotx.portal.storage.addon.munit.StepRoundRobinRuleImpl.key.list,"key1\,key2\,key3"}}
   

   上記コマンドでは、com.nec.webotx.portal.storage.persistence.unit.balancing.type以外は、すべて既定値を指定しています。既定値を変更している場合は、それぞれ適切な値に変更して設定する必要があります。

   Memo
   この例では、key1、key2、key3の順で振り分けられるように指定していますが、例えば、key1 に重み付けを行う場合は、「key1,key1,key2,key1,key3」などのように指定します。
   
   
4. 振り分けキーと永続ユニットのマッピングを定義します。

   otxadmin> set server.portal.portal-storage.keyUnitMap={{<;振り分けキー>,<永続ユニット名>}[,{<振り分けキー>,<永続ユニット名>}]}
   

   例) 振り分けキーとして、key1、key2、key3を使い、それぞれに、unit_001、unit_002、unit_003の永続ユニットを割り当てる場合

   otxadmin> set server.portal.portal-storage.keyUnitMap={{key1,unit_001},{key2,unit_002},{key3,unit_003}}
   

5. (分散キャッシュ利用時のみ) 永続ユニットと、更新通知で利用するキャッシュのマッピングを定義します。分散キャッシュを利用していない場合は、この手順は不要です。

   otxadmin> set server.portal.portal-storage.unitCacheMap={{<永続ユニット名>,<キャッシュ名>}[,{<永続ユニット名>,<キャッシュ名>}]}
   

   例) 永続ユニットunit_001、unit_002、unit_003に、更新通知用キャッシュ cache1 を割り当てる場合

   otxadmin> set server.portal.portal-storage.unitCacheMap={{unit_001,cache1},{unit_002,cache1},{unit_003,cache1}}
   

6. ドメインを再起動します。

6.7. UIカスタマイズ

6.7.1. はじめに

ここでは、UIカスタマイズについて説明します。 UIカスタマイズとは、ポータル製品が提供するポータルスキン、ポートレットスキン、テーマ、レイアウトパターンを新たに定義し、ポータルサイトに適用できるようにする機能です。

ポータルスキンとは、ポータル画面全体の構成を決めるテンプレートです。エリアの構成やエリア内のボタン、メニューの構成を決定できます。ベースとなるスタイルの定義もできます。

ポートレットスキンとは、ポータルのウィンドウの構成、およびデザインを決めるテンプレートです。タイトルバー内のボタンの配置、ポートレットのコンテンツのベースとなるスタイルを定義します。

テーマとは、ポータル全体の色やフォントなどのスタイルを決めます。ポータルスキン、ポートレットスキンで決定したスタイルを上書きすることができます。

レイアウトパターンとは、ページのレイアウトを決めるためのテンプレートです。ポートレットが配置な領域を設定します。

6.7.2. リソースの作成

ここでは、ポータルスキン、ポートレットスキン、テーマ、レイアウトパターンの各種リソースの作成方法について説明します。

リソースにはCSS(カスケードスタイルシート)を含むものがあります。複数のCSSに同一のスタイル定義がある場合、CSSの読み込み順序やセレクタの記述方法によって優先順位が決定され、適用されるスタイルが決まります。

各リソースのCSSはポータルのベースのスタイルを上書きする形で定義します。そのため、ポータルのベースのスタイルより優先順位が高くなるように、body要素のid属性を用いてセレクタを定義してください。

例) #otx .archPortalServiceArea {}

ポータルのベースのスタイルについては、以下のファイルを参照ください。
${INSTANCE_ROOT}/portal/webapps/webotx-portal/javascript/resources/portal.css

また、ポータルではポータルスキン、ポートレットスキン、テーマのCSSの優先順位を優先度が低い順に以下のように定義しています。

1. ポータルスキン
2. ポートレットスキン
3. テーマ

各CSSはこの優先順位にそった順序で読み込む仕組みになっていますが、セレクタが各CSSで異なる場合は優先順位を保つことができません。

優先順位を保つため、ポータルスキン、ポートレットスキン、テーマ間で同じ対象に対するセレクタを同一にすることを推奨します。

CSSが正しく適用されない場合は、他に優先されているスタイルがないかを確認してください。

6.7.2.1. ポータルスキン

ここでは、ポータルスキンの作成方法について説明します。

ポータルスキンを構成するファイル

ポータルスキンは、テンプレートファイル(*.ftl)とテンプレートファイルから参照する各種ファイル(*.js、*.css、*.jpgなど)で構成されています。

テンプレートファイルはポータル画面のHTMLの一部です。ポータル画面を表示する際に、ポータル画面に統合されます。各テンプレートファイルは、ポータル画面に統合される位置が決まっています。

上記のテンプレートファイルのファイル名は変更できません。

ポータルスキンによっては上記テンプレートファイルから参照するテンプレートファイルが登録されています。ポータルが用意しているポータルスキンには、以下のテンプレートファイルがあります。

これらのテンプレートファイルでは、以下の文字列を記載することで該当ポータルスキンを使って画面を表示する際に動的に表示内容を変更することができます。

記述例

テンプレートファイルから参照する各種ファイルは、以下のフォルダに配置することになっています。詳細は、5.7.3.1. ポータルスキンを参照ください。
<INSTANCE_ROOT>/portal/design/portaldesign/portalSkins/<ID>/<targetID>/

このフォルダは以下のURLに対応しています。テンプレートファイルからはこのURLを用いて参照してください。${contextPath}は上記の表にあるように実行時にポータルのコンテキストパスに変換されます。
${contextPath}/portaldesign/portalSkins/<ID>/<targetID>/

作成手順

ポータルスキンを作成する場合、作成したいポータルスキンにもっとも近いポータルスキンの各種ファイルをコピーして編集します。

1. 作成したいポータルスキンにもっとも近いポータルスキンをコピーします。
2. 編集したい場所に対応したテンプレートファイルの内容を書き換えます。

テンプレートファイルにはid属性を持つ要素がいくつかあります。各要素のid属性は、ポータルの画面処理スクリプトで使用しています。id属性の値を変更するとその要素に対して処理が行われませんので、変更しないでください。

書き方によってはポータル画面が正しく動かなくなる場合がありますので、ポータルスキンを作成したあとには必ず動作確認を行ってください。

編集内容別の説明と注意事項

どの要素も削除することができます。id属性を持つ要素を削除することも可能です。

BodyContent.ftlか、そこから参照するテンプレートファイル内であれば移動することができます。

移動した場所によってボタンやアイコンの見た目が変わることがあります。

BodyContent.ftlか、そこから参照するテンプレートファイル内であれば追加することができます。

preInitialize.ftlかpostInitialize.ftlに、script要素を追加することで実行できます。実行したいタイミングに応じて記述する場所や方法を判断します。

dojoのready関数を使用したスクリプトの例は以下のようになります。

require(["dojo/ready"], function(ready) {
    ready(function() { /*実行したい処理*/ });
});

preInitialize.ftlかpostInitialize.ftlに、link要素かstyle要素を追加することで適用できます。どちらのテンプレートに記述しても問題ありません。

ポータルの画面はポータルの画面処理スクリプトによってテンプレートファイルの内容を元に作られます。CSSはスクリプト実行後のHTMLの構成にしたがって記述してください。スクリプト実行後のHTMLのサンプルはこちらを参照ください。

※class属性にarchPortletWindowWidgetが設定されている要素の配下はポータルスキンではなくポートレットスキンの範囲になります。
※クラス名が<任意の文字列>+PortalEditModeとなっているものは、ポータル編集モード特有のクラス名です。ポータル通常モードでは設定されていません。

CSS作成時の注意点については5.7.2. リソースの作成を参照ください。

6.7.2.2. ポートレットスキン

ここでは、ポートレットスキンの作成方法について説明します。

ポートレットスキンを構成するファイル

ポートレットスキンは、ポートレットウィンドウの構造を定義するHTMLファイルとポートレットウィンドウに適用するスクリプトやCSS、そこから参照する各種ファイル(画像ファイルなど)、スクリプトとCSSのリストを定義するプロパティファイルで構成されています。

ポートレットスキンのHTMLファイルは、ポータルの画面処理スクリプトにより実際のポートレットウィンドウのHTMLに変換されます。そのため、内部にscript要素やlink要素、style要素を記述することができません。ポートレットスキンにスクリプトやCSSを適用するための別の仕組みとして、プロパティファイルを用意しています。

プロパティファイルでは、適用したいスクリプトファイルやCSSを複数指定することができます。実行順や読み込み順も指定できます。

HTMLファイルとプロパティファイルのファイル名は変更できません。それぞれPortletWindowWidget.htmlとskin.propertiesになります。

作成手順

ポートレットスキンを作成する場合、作成したいポートレットスキンにもっとも近いポートレットスキンをコピーして編集します。

1. 作成したいポートレットスキンにもっとも近いポートレットスキンの各種ファイルをコピーします。
2. 編集したい内容に応じて各ファイルを書き換えます。

HTMLファイルにはdata-dojo-attach-point属性、data-dojo-attach-event属性を持つ要素がいくつかあります。各要素のdata-dojo-attach-point属性、data-dojo-attach-event属性は、ポータルの画面処理スクリプトで使用しています。これらの属性の値を変更するとその要素に対する処理が失敗する場合がありますので、変更しないでください。

書き方によってはポータル画面が正しく動かなくなる場合がありますので、ポートレットスキンを作成したあとには必ず動作確認を行ってください。

編集内容別の説明と注意事項

特定の要素以外は削除することができます。特定の要素以外のdata-dojo-attach-point属性を持つ要素を削除することも可能です。

削除できない要素は以下になります。

特定の要素以外は移動することができます。

移動できない要素は以下になります。

移動した場所によってボタンやアイコンの見た目が変わることがあります。

特定の場所以外には追加することができます。

ボタンやアイコンを追加できない要素は以下になります。

プロパティファイルのskin.propertiesで実行したいスクリプトを指定します。

スクリプトは、ポータルの画面処理スクリプトの先頭で実行されますが、このときポートレットウィンドウはまだ画面上に配置されていません。そのため、ポートレットウィンドウが画面上に配置されたタイミングで処理を実行できる仕組みを用意しています。

ポートレットウィンドウが画面に配置されたタイミングで処理を行いたい場合は、スクリプト内でポータルの提供するJavaScriptAPIを利用して処理を登録します。

以下に、使用例を記載します。

require(["webotx/portal/design/portletSkin"], function(portletSkin) {
    // ポートレットウィンドウが画面上に配置されたときに呼び出す初期化関数を登録します。
    // 引数は、配置されたポートレットウィンドウのDOM要素です。
    portletSkin.addSkinInitializer(function(node) { /* 画面に配置されたタイミングで実行したい処理 */ });
});

ここで登録した関数の具体的な実行タイミングは以下になります。ポートレットウィンドウ一つ一つに対して実行されます。

1. ポートレットウィンドウを画面に配置
2. ポートレットスキンのスクリプトを実行
3. ポートレットコンテンツを画面に反映

プロパティファイルのskin.propertiesで適用させたいスクリプトを指定します。

ポータルの画面はポータルの画面処理スクリプトによってテンプレートファイルの内容を元に作られます。CSSはスクリプト実行後のHTMLの構成にしたがって記述してください。スクリプト実行後のHTMLのサンプルはこちらを参照ください。

※ポータルスキンの範囲はclass属性にarchPortletWindowWidgetが設定されている要素の配下のみになります。
※クラス名が<任意の文字列>+PortalEditModeとなっているものは、ポータル編集モード特有のクラス名です。ポータル通常モードでは設定されていません。

CSS作成時の注意点については5.7.2. リソースの作成を参照ください。

6.7.2.3. テーマ

ここでは、テーマの作成方法について説明します。

テーマを構成するファイル

テーマは、テーマのスタイルを定義するCSSとそこから参照する各種ファイル(画像ファイルなど)で構成されています。

CSSのファイル名は変更できません。theme.cssになります。

作成手順

テーマを作成する場合、作成したいテーマにもっとも近いテーマをコピーして編集します。

1. 作成したいテーマにもっとも近いテーマの各種ファイルをコピーします。
2. 編集したい内容に応じて各ファイルを書き換えます。

CSS作成時の注意点については5.7.2. リソースの作成を参照ください。

6.7.2.4. レイアウトパターン

新規にレイアウトパターンを作成したい場合には、レイアウトパターンを定義したレイアウトパターン定義ファイルとページプロパティに表示する画像ファイルを作成します。画像ファイルは省略することも可能です。

画像ファイルの縦横サイズは横270x縦45で固定です。使用可能状態、ホバー状態、選択状態、使用不可状態の四種類の状態を表す絵を横に並べた画像ファイルを作成してください。その際、画像ファイルにおける各状態を表す絵の位置が、ポータルの使用しているレイアウトパターンの画像ファイルと同じになるようにしてください。

レイアウトパターン定義ファイルのファイル名は pattern.html 固定です。レイアウトパターンをtable/tr/tdタグを使って定義します。規則は以下の通りです。規則は以下の通りです。

• 以下のタグのみ有効で、それ以外のタグは無視する
  <table>、<tr>、<td>、</td>、</tr>、</table>
• １つのtdタグが、１つのレイアウトボックスに対応
• タグの属性としてはtdタグのwidth属性のみ有効で、それ以外の属性は全て無視
• tdタグ内にtableタグを記載可能
• tdタグのwidth属性は%で指定し、１つの行の中のwidth属性値の合計は100%になるように設定

定義例

このレイアウトを定義するには、以下のように定義してください。定義したレイアウトイメージを確認しやすいようにborder属性やarea1, area2, area3のデータを記入しているが、実際には不要です。

6.7.3. リソースの登録・削除手順

定義したそれぞれのリソースの登録方法、削除方法について説明します。

6.7.3.1. ポータルスキン

作成したポータルスキンは、以下の手順で登録します。

1. ポータルスキンを識別するためのポータルスキンIDを決めてください。
   以下IDが「portalSkin1」の場合を例に説明します。
2. 有効にするポータルスキンを識別するためのターゲットIDを決めてください。
   ターゲットIDはポータルスキン更新時に更新毎のポータルスキンを管理するためのIDです。
   例えば、A面/B面のように「a」や「b」というIDを利用したり、世代管理をする場合に数字を使用したりすることを想定しています。
   以下ターゲットIDが「a」の場合を例に説明します。
3. 以下のディレクトリを作成し、作成したポータルスキンのファイルを一式格納してください。
   

   ${INSTANCE_ROOT}/portal/design/info/portalSkins/<ポータルスキンID>/<ターゲットID>

   WebOTXのドメインのパスが「c:\WebOTX\domains\domain1」で、ポータルスキンIDが「portalSkin1」でターゲットIDが「a」の場合は以下のディレクトリになります。
   

   c:\WebOTX\domains\domain1\portal\design\info\portalSkins\portalSkin1\a

4. コマンドを実行して登録操作を行ってください。マルチサーバ構成で利用する場合にはすべてのサーバにポータルスキンのファイルを格納した後で、サーバのうちの１台でコマンドを実行してください。

   例) ポータルサイトのプロパティに表示するポータルスキンの名前が「skin1」の場合
   

   otxadmin> enable-portal-skin --id portalSkin1 --defaultName skin1 --targetId a

登録したポータルスキンは、以下の手順で削除します。

1. コマンドを実行して削除操作を行ってください。

   例) ポータルスキンIDが「portalSkin1」のポータルスキンを削除する場合
   

   otxadmin> disable-portal-skin --id portalSkin1

2. 不要になったポータルスキンのファイルは各サーバから削除してください。

登録したポータルスキンを変更したい場合は、削除後登録してください。登録する際にターゲットIDを変更することによって、登録したファイルに問題があった場合に容易に変更前の状態に戻すことができます。

6.7.3.2. ポートレットスキン

作成したポートレットスキンは、以下の手順で登録します。

1. ポートレットスキンを識別するためのポートレットスキンIDを決めてください。
   以下IDが「portletSkin1」の場合を例に説明します。
2. 有効にするポートレットスキンを識別するためのターゲットIDを決めてください。ターゲットIDはポートレットスキン更新時に更新毎のポートレットスキンを管理するためのIDです。
   例えば、A面/B面のように「a」や「b」というIDを利用したり、世代管理をする場合に数字を使用したりすることを想定しています。
   以下ターゲットIDが「a」の場合を例に説明します。
3. 以下のディレクトリを作成し、作成したポートレットスキンのファイルを一式(skin.properties以外)格納してください。

   ${INSTANCE_ROOT}/portal/design/portaldesign/portletSkins/<ポートレットスキンID>/<ターゲットID>

   WebOTXのドメインのパスが「c:\WebOTX\domains\domain1」で、ポートレットスキンIDが「portletSkin1」でターゲットIDが「a」の場合は以下のディレクトリになります。

   c:\WebOTX\domains\domain1\portal\design\portaldesign\portletSkins\portletSkin1\a

4. skin.propertiesを作成している場合には以下のディレクトリを作成し、作成したskin.propertiesを格納してください。

   ${INSTANCE_ROOT}/portal/design/info/portletSkins/<ポートレットスキンID>/<ターゲットID>

   WebOTXのドメインのパスが「c:\WebOTX\domains\domain1」で、ポートレットスキンIDが「portletSkin1」でターゲットIDが「a」の場合は以下のディレクトリになります。

   c:\WebOTX\domains\domain1\portal\design\info\portletSkins\portletSkin1\a

5. コマンドを実行して登録操作を行ってください。マルチサーバ構成で利用する場合にはすべてのサーバにポートレットスキンのファイルを格納した後で、サーバのうちの１台でコマンドを実行してください。

   例) ポータルサイトのプロパティに表示するポートレットスキンの名前が「skin1」の場合

   otxadmin> enable-portlet-skin --id portletSkin1 --defaultName skin1 --targetId a

登録したポートレットスキンは、以下の手順で削除します。

1. コマンドを実行して削除操作を行ってください。

   例) ポートレットスキンIDが「portletSkin1」のポートレットスキンを削除する場合

   otxadmin> disable-portlet-skin --id portletSkin1

2. 不要になったポートレットスキンのファイルは各サーバから削除してください。

登録したポートレットスキンを変更したい場合は、削除後登録してください。登録する際にターゲットIDを変更することによって、登録したファイルに問題があった場合に容易に変更前の状態に戻すことができます。

6.7.3.3. テーマ

作成したテーマは、以下の手順で登録します。

1. テーマを識別するためのテーマIDを決めてください。
   以下IDが「theme1」の場合を例に説明します。
2. 有効にするテーマを識別するためのターゲットIDを決めてください。ターゲットIDはテーマ更新時に更新毎のテーマを管理するためのIDです。
   例えば、A面/B面のように「a」や「b」というIDを利用したり、世代管理をする場合に数字を使用したりすることを想定しています。
   以下ターゲットIDが「a」の場合を例に説明します。
3. 以下のディレクトリを作成し、作成したテーマのファイルを一式格納してください。
   

   ${INSTANCE_ROOT}/portal/design/portaldesign/themes/<テーマID>/<ターゲットID>

   WebOTXのドメインのパスが「c:\WebOTX\domains\domain1」で、テーマIDが「theme1」でターゲットIDが「a」の場合は以下のディレクトリになります。

   c:\WebOTX\domains\domain1\portal\design\portaldesign\themes\theme1\a

4. コマンドを実行して登録操作を行ってください。マルチサーバ構成で利用する場合にはすべてのサーバにテーマのファイルを格納した後で、サーバのうちの１台でコマンドを実行してください。

   例) ポータルサイトのプロパティに表示するテーマの名前が「theme1」の場合

   otxadmin> enable-theme --id theme1 --defaultName theme1 --targetId a

登録したテーマは、以下の手順で削除します。

1. コマンドを実行して削除操作を行ってください。

   例) テーマIDが「theme1」のテーマを削除する場合

   otxadmin> disable-theme --id theme1

2. 不要になったテーマのファイルは各サーバから削除してください。

登録したテーマを変更したい場合は、削除後登録してください。登録する際にターゲットIDを変更することによって、登録したファイルに問題があった場合に容易に変更前の状態に戻すことができます。

6.7.3.4. レイアウトパターン

作成したレイアウトパターンは、以下の手順で登録します。

1. レイアウトパターンを識別するためのレイアウトパターンIDを決めてください。
   以下IDが「layout1」の場合を例に説明します。
2. 以下のディレクトリを作成し、作成したレイアウトパターンのファイルを格納してください。

   ${INSTANCE_ROOT}/portal/design/info/patterns/<レイアウトパターンID>

   WebOTXのドメインのパスが「c:\WebOTX\domains\domain1」で、レイアウトパターンIDが「layout1」の場合は以下のディレクトリになります。

   c:\WebOTX\domains\domain1\portal\design\info\patterns\layout1

3. レイアウトパターンを表す画像ファイルを作成した場合は以下のディレクトリを作成し、作成した画像ファイルを格納してください。

   ${INSTANCE_ROOT}/portal/design/portaldesign/patterns/<レイアウトパターンID>/images

   WebOTXのドメインのパスが「c:\WebOTX\domains\domain1」で、レイアウトパターンIDが「layout1」の場合は以下のディレクトリになります。

   c:\WebOTX\domains\domain1\portal\design\portaldesign\patterns\layout1\images

4. コマンドを実行して登録操作を行ってください。マルチサーバ構成で利用する場合にはすべてのサーバにレイアウトパターンのファイルを格納した後で、サーバのうちの１台でコマンドを実行してください。

   例) ポータルページのプロパティに表示するレイアウトパターンの名前が「layout1」の場合

   otxadmin> add-page-layout --id layout1 --defaultName layout1

登録したレイアウトパターンは、以下の手順で削除します。

1. コマンドを実行して削除操作を行ってください。

   例) レイアウトパターンIDが「layout1」のレイアウトパターンを削除する場合

   otxadmin> delete-page-layout --id layout1

2. 不要になったレイアウトパターンのファイルは各サーバから削除してください。

6.7.4. 画面項目の非表示設定

ポータルスキン、ポートレットスキン単位で画面上の画面項目を非表示にすることができます。
マルチテナント構成の場合には、会社毎に設定を行うことができます。

6.7.4.1. 非表示設定手順

非表示項目の設定はWebAPIを使って行います。
WebAPIは会社管理者ユーザでログインしている状態で実行してください。

WebAPIの一覧は以下の通りです。

6.7.4.2. 設定可能な項目と設定値