Web Screen Painter を使用してスキーマを変更する方法

Web Screen Painter のスキーマ デザイナを使用して、CA SDM のデータベース スキーマを変更します。 スキーマ デザイナには、このスキーマを確認および変更するためのグラフィカル ユーザ インターフェースが用意されています。 以下の図は、Web Screen Painter を使用してスキーマを変更する方法を示しています。
casm173
Web Screen Painter のスキーマ デザイナを使用して、CA SDM のデータベース スキーマを変更します。 スキーマ デザイナには、このスキーマを確認および変更するためのグラフィカル ユーザ インターフェースが用意されています。 以下の図は、Web Screen Painter を使用してスキーマを変更する方法を示しています。
WSP を使用してスキーマをカスタマイズする方法を示す図
Diagram depicting how to customize schema using WSP
以下の手順に従います。
WSP でスキーマ デザイナを開く
スキーマ デザイナでの作業を開始するには、CA SDM サーバに WSP がインストールされていることを確認してください。 WSP のインストールに関する詳細については、「Web Screen Painter のインストール」を参照してください。
以下の手順に従います。
  1. CA SDM の設定に応じて、以下の CA SDM サーバにログインします。
    • 標準: プライマリ サーバ
    • 高可用性: バックグラウンド サーバ
  2. サーバにインストールされているオペレーティング システムに応じて、以下のいずれかのアクションを使用して WSP を起動します。
    • (Windows の場合)[スタート]メニューから[すべてのプログラム]-[CA]-[CA SDM]-[Web Screen Painter]を選択します。
    • (UNIX)パスに $NX_ROOT/bin を指定してコマンド pdm_wsp を入力します。
    [Web Screen Painter ログイン]ウィンドウが表示されます。
  3. ログイン ID を入力します。
  4. [ツール]-[スキーマ デザイナ]を選択します。
    [スキーマ デザイナ]ウィンドウが開きます。 [スキーマ デザイナ]ウィンドウの左側には、CA SDM のデータベースがツリー表示されます。 テーブルと列は、それぞれのオブジェクト名で表示されます。 表示名がテーブルまたは列のオブジェクト名と異なる場合は、オブジェクト名と共に表示名が括弧で囲まれて表示されます。
テーブルの追加
データベースにテーブルを追加するには、スキーマ デザイナを使用します。
以下の手順に従います。
  1. [編集]-[テーブルの追加]を選択します。
    [テーブルの新規追加]ダイアログ ボックスが開きます。
  2. [新規テーブル名]フィールドにテーブル名を入力し、[OK]をクリックします。 今後使用される標準テーブルとの競合を避けるために、サイト定義テーブルの名前を文字「z」で開始するようにしてください。
    ユーザが追加しなかった場合は、テーブル名の先頭に「z」が自動的に追加されます。
  3. 必要に応じて、以下のフィールドに入力します。
    • 名前
      (読み取り専用です)テーブルのオブジェクト名を指定します。 たとえば、cr テーブルのオブジェクト名は「cr」です。
    • 表示名
      内容がわかるようなテーブル名を指定します。 たとえば、cr テーブルの表示名は「リクエスト」です。 このフィールドに新しい名前を入力すると、テーブルの表示名を変更できます。
    • スキーマ名
      (標準テーブルでは読み取り専用) pdm_userload など、CA SDM ユーティリティでテーブルを参照するために使用する名前を指定します。 サイト定義テーブルでは、デフォルトのスキーマ名はオブジェクト名です。 このフィールドに新しい値を入力して、スキーマ名を変更することができます。
    • DBMS 名
      物理 DBMS にあるテーブルを参照するために使用する名前を指定します。 このフィールドは、すべてのテーブルで読み取り専用です。 サイト定義テーブルでは、常にスキーマ名と同じです。
    • 表示フィールドのデフォルト(共通名)
      このテーブルを参照するフィールドについて、UI に表示される列を指定します。 たとえば、リクエストの[担当者]フィールドは、連絡先テーブルの参照フィールドです。 連絡先テーブルの共通名は combo_name(姓、名、ミドルネーム)であるため、参照される連絡先のコンボ名は、担当者として表示されます。 共通名の値は変更できません。
    • 外部キー フィールド(関連付け属性)
      このテーブルを参照するフィールドについて、データベースに格納される列を指定します。 たとえば、リクエストの[担当者]フィールドは、連絡先テーブルの参照フィールドです。 連絡先テーブルの関連付け属性は ID であるため、リクエストの担当者列には、参照される連絡先の ID が格納されます。 関連付け属性の値は変更できません。
    • ファンクション グループ
      テーブル内のレコードに対して、ユーザのアクセス レベルを管理するグループ名を指定します。 連絡先の各アクセス タイプでは、各ファンクション グループのテーブル データについての読み取り権限を与えるか、変更権限を与えるか、またはアクセス権を与えないかを指定します。 ドロップダウン リストから新しい値を選択して、関連付け属性の値を変更できます。
    スキーマ デザイナには、[詳細]タブがあります。 このタブ上の情報は、CA Technologies のサポート担当者およびサイト担当者が使用するものです。 スキーマ デザイナの使用時にこのタブを操作することはほとんどないため、本書では説明しません。
    [スキーマ デザイナ]ダイアログ ボックスの[詳細]タブには、CA SDM の内部に詳しいユーザにのみ役立つ情報が表示されます。 表示される内容は、列タイプによって異なります。 CA Technologies のテクニカル サポートから指示があった場合にのみ、このタブの値を変更することをお勧めします。 テーブルを選択すると、[スキーマ デザイナ]ダイアログ ボックスに以下のフィールドが表示されます。
    • アクティブなトリガ
      列に対して、オブジェクト エンジンでアクティブになっているトリガを入力します。 トリガとは、列変更時の特定のタイミングで、オブジェクト エンジンの指示によって実行される小さなプログラムです。 [アクティブなトリガ]リストには、標準トリガとサイト定義トリガの両方が表示されます(したがって、サイト定義トリガは、アクティブなリストとサイト定義のリストの両方に一覧表示されます)。
    • サイト定義トリガ
      サイトにインストールしたトリガを入力します。 たとえば、これらのトリガには、CA SDM のオプション機能をインストールした結果としてアクティブになったトリガや、CA のテクニカル サービスがユーザ サイト用に記述したトリガも含まれます。 [アクティブなトリガ]リストには、標準トリガとサイト定義トリガの両方が表示されます(したがって、サイト定義トリガは、アクティブなリストとサイト定義のリストの両方に一覧表示されます)。
    • LRel定義
      フォームで、2つのテーブル間の多対多リレーションシップを以下のように指定します。
      table1 column1 <> table2 column2
      この場合、LRELはtable1とtable2間の多対多リレーションシップを表しており、仮想列column1はtable1と、仮想列column2はtable2と関連付けられています。
    • アクティブなxRelクエリ情報
      仮想列BRELまたはQRELを定義するクエリのアクティブな値を入力します。 この値は、オブジェクト エンジンMajicの形式で指定します。
    • サイト定義xRelクエリ情報
      BRELまたはQRELと関連付けられたクエリを変更します。 CA のテクニカル サービスから指示があった場合にのみ、このフィールドにデータを入力することをお勧めします。
    • アクティブな派生式
      DERIVED仮想列の値を生成するためにオブジェクト エンジンが使用する式を、アクティブな値として入力します。
    • サイト定義xRelクエリ情報
      DERIVED列に関連付けられた式を変更します。 CA のテクニカル サービスから指示があった場合にのみ、このフィールドにデータを入力することをお勧めします。
    [スキーマ デザイナ テーブル]ダイアログ ボックスの[Domsets]タブには、以下の情報が表示されます。
    • MLIST_DYNAMIC
      WHERE 節のない動的 domset です。
    • MLIST_STATIC
      WHERE 節のない静的 domset です。
    • RLIST_DYNAMIC
      FACTORY ステートメントの STANDARD_LISTS セクションに WHERE 節が定義された動的 domset です。
    • RLIST_STATIC
      FACTORY ステートメントの STANDARD_LISTS セクションに WHERE 節が定義された静的 domset です。
    いずれかの domset をダブルクリックすると、[プロパティ]ダイアログ ボックスが開き、以下のフィールドが表示されます。
    • domset_name
    • fetch_columns
    • max_fetch
    • sort columns
      このフィールドのみ編集できます)
    • volatility
    • where
  4. テーブルを保存するには、以下のいずれかを実行します。
    • テスト システムで作業している場合は、[ファイル]-[保存]を選択します。
    • 実稼働システムで作業している場合は、[ファイル]-[保存してテスト モードに設定]を選択します。
      これにより、変更がデータベースに保存され、オブジェクト エンジンへの変更を定義するファイル(wsptest.mods)がサーバ上に作成されます。 このファイルは、CA SDM インストール ディレクトリの site/mods/majic サブディレクトリに格納されます。 wsptest.modsファイルが作成されると、オブジェクト エンジンがリサイクルされ、新しい変更が使用されるようになります。 この処理は、スキーマの複雑さに応じて、数秒から数分かかります。
      メッセージが表示されます。 [はい]をクリックして続行します。 wsptest.modsファイルが影響するのは、wsp_domsrvrオプションで指定されたオブジェクト エンジンのみです。 同じサーバ上の他のオブジェクト エンジンはこのファイルを処理せず、このファイルが他のサーバに配布されることはありません。 また、テスト モードの新規テーブルと列は、ローカル オブジェクトとしてオブジェクト エンジンに定義されます。 つまり、これらのテーブルと列はオブジェクト エンジンで認識されており、Webフォームで使用できます。 ただしデータベース内には存在しないため、他のユーザには影響しません。 CA SDM の標準ユーザは WSP オブジェクト エンジンを使用しないため、テストしているスキーマ変更の影響を受けません。 テーブルが追加されます。
列の追加
データベースに列を追加するには、スキーマ デザイナを使用します。
以下の手順に従います。
  1. 列を追加するテーブルを選択(またはテーブルの既存の列を任意に選択)します。
  2. [編集]-[列の追加]を選択します。
    [列の新規追加]ダイアログ ボックスが開きます。
  3. [新規列名]フィールドに列名を入力して[OK]をクリックします。 今後使用される標準列との競合を避けるために、列の名前を文字「z」で開始するようにしてください。
    WSP は、「z」の有無を確認し、必要に応じて列名の先頭に「z」を追加します。
  4. 必要に応じて以下のフィールドに値を入力します。
    • 名前
      (表示専用)列のオブジェクト名を指定します。 たとえば、連絡先の alt_phone 列のオブジェクト名は「alt_phone」です。
    • 表示名
      内容がわかるような列名を指定します。 このフィールドに新しい表示名を入力すると、列の表示名を変更できます。 たとえば、連絡先 alt_phone 列の表示名は「その他の電話番号」です。
    • スキーマ名
      (標準テーブルでは読み取り専用) pdm_userload など、CA SDM ユーティリティで列を参照するために使用する名前を指定します。 サイト定義テーブルでは、デフォルトのスキーマ名はオブジェクト名です。 このフィールドに別の値を入力して、スキーマ名を変更することができます。
    • DBMS 名
      (すべてのテーブルで読み取り専用)物理 DBMS にあるテーブルを参照するために使用する名前を指定します。 サイト定義テーブルでは、DBMS名 は常にスキーマ名と同じです。
    • 説明
      列の簡単な説明を入力します。
    • フィールド タイプ
      (標準テーブルにあるすべての標準列と保存済みサイト定義列では読み取り専用)列のデータ タイプを指定します。 ドロップダウンから値を選択すると、新しいサイト定義列のフィールド タイプを、指定または変更することができます。 以下に、使用できるフィールド タイプのリストを示します。
      • INTEGER
        数値を示します。
      • STRING
        テキスト文字列を示します。 [文字列長]フィールドは、文字列の文字数を示します。
      • DATE
        日時を示します。 データベースに格納される値は、1970年1月1日の深夜 0 時以降の秒数です。
      • DURATION
        期間を示します。 データベースに格納される値は、秒数を表す整数です。
      • DOUBLE
        実数(浮動小数点数)を示します。
      • SREL
        他のテーブルに対する外部キー参照を示します。 SREL テーブル フィールドは、参照先のテーブルを指定します。 データベースに格納される値は、参照されるテーブルの関連付け属性で、整数または文字列を指定できます。 本製品に表示される値は、参照されるテーブルの行の共通名です。 外部キー値を使用して SREL 属性を設定する方法については、「CA Service Desk Manager 参照コマンド」を参照してください。
      • BREL
        このテーブルに対するSRELが指定されたすべてのオブジェクトのセットを表す仮想列を示します。 この列は、オブジェクト エンジンのみに存在し、データベースに物理的に格納されません。 CA Technologies の従業員から指示があった場合にのみ、このフィールド タイプを選択してください。
      • QREL
        [詳細]タブのWhere節で選択したオブジェクトのセットを表す仮想列を示します。 この列は、オブジェクト エンジンのみに存在し、データベースに物理的に格納されません。 CA Technologies の従業員から指示があった場合にのみ、このフィールド タイプを選択してください。
      • DERIVED
        [詳細]タブで指定されている式に従い、別の列の値を使用してオブジェクト エンジンが構築した仮想列を示します。 この列は、オブジェクト エンジンのみに存在し、データベースに物理的に格納されません。 CA Technologies の従業員から指示があった場合にのみ、このフィールド タイプを選択してください。
    • 文字列長
      文字列の長さです。 文字列以外の列である場合、このフィールドは空です。 すべての標準列と保存したサイト定義列では、読み取り専用になります。 このフィールドに 1~32767 の整数を入力して、新しいサイト定義のSTRING列の長さを指定したり、変更したりすることができます。
    • SRel テーブル
      SREL 列で参照されるテーブルです。 SREL 以外の列である場合、このフィールドは空です。 すべての標準列と保存したサイト定義列では、読み取り専用になります。 ドロップダウン リストから値を選択すると、新しいサイト定義SRELによって参照されるテーブルを指定できます。
    • 新規作成時のデフォルト値
      テーブルの新しい行を定義するときにこの列に割り当てられるデフォルト値です。 これは、フィールド タイプに適した値にする必要があります。 一部のキーワード値は、特定のフィールド タイプでのみ使用できます。
      • NOW
        DATE列に対して、現在の日時を指定します。
      • USER
        連絡先テーブルの SREL 列のアクティブ ユーザを指定します。
    • 保存時の設定値
      テーブルの行を更新するときにこの列に割り当てられる値です。 これは、フィールド タイプに適した値にする必要があります。 一部のキーワード値は、特定のフィールド タイプでのみ使用できます。
      • NOW
        DATE列に対して、現在の日時を指定します。
      • USER
        連絡先テーブルの SREL 列のアクティブ ユーザを指定します。
    • 必須
      このチェック ボックスをオンにした場合、テーブルの行を保存する前に、その行に含まれる列に必ず値を入力する必要があります。 標準列とサイト定義列の両方に、このオプションを設定できます。また、設定したオプションを無効にすることもできます。 ただし、サイトで設定した場合を除いて、標準列のオプションはオフにできません。
    • 新規レコードのみ更新可能
      このオプションをオンにした場合、テーブルの行を最初に作成したときにのみ列の値を指定でき、それ以降は値を変更できません。 標準列とサイト定義列の両方に、このオプションを設定できます。また、設定したオプションを無効にすることもできます。 ただし、サイトで設定した場合を除いて、標準列のオプションはオフにできません。
    • pdm_userload のキー
      このオプションをオンにした場合、入力値が既存の行の更新値であるかどうか判断するために、列がpdm_userloadによってテストされます。 このオプションは、STRING 列でのみ使用できます。 このオプションは、標準テーブルのすべての列で読み取り専用になります。
    • DBMS のインデックス関連のオプション
      これらのオプションでは、物理 DBMS のインデックス列の特性を指定します。 これらのオプションは、サイト定義テーブルの列でのみ使用できます。
      • 一意
        テーブル内で、列が一意であることを指定します。つまり、この列では同じ値を持つ 2 つの行は存在しません。
      • 昇順
        DBMSインデックスが、この列によって昇順に並べ替えられます。 選択できるのは、昇順と降順のいずれか一方だけです。
      • 降順
        DBMSインデックスが、この列によって降順に並べ替えられます。 選択できるのは、昇順と降順のいずれか一方だけです。
    スキーマ デザイナには、[詳細]タブがあります。 このタブ上の情報は、CA Technologies のサポート担当者およびサイト担当者が使用するものです。 スキーマ デザイナの使用時にこのタブを操作することはほとんどないため、本書では説明しません。
    [スキーマ デザイナ]ダイアログ ボックスの[詳細]タブには、CA SDM の内部に詳しいユーザにのみ役立つ情報が表示されます。 表示される内容は、列タイプによって異なります。 CA Technologies のテクニカル サポートから指示があった場合にのみ、このタブの値を変更することをお勧めします。 テーブルを選択すると、[スキーマ デザイナ]ダイアログ ボックスに以下のフィールドが表示されます。
    • アクティブなトリガ
      列に対して、オブジェクト エンジンでアクティブになっているトリガを入力します。 トリガとは、列変更時の特定のタイミングで、オブジェクト エンジンの指示によって実行される小さなプログラムです。 [アクティブなトリガ]リストには、標準トリガとサイト定義トリガの両方が表示されます(したがって、サイト定義トリガは、アクティブなリストとサイト定義のリストの両方に一覧表示されます)。
    • サイト定義トリガ
      サイトにインストールしたトリガを入力します。 たとえば、これらのトリガには、CA SDM のオプション機能をインストールした結果としてアクティブになったトリガや、CA のテクニカル サービスがユーザ サイト用に記述したトリガも含まれます。 [アクティブなトリガ]リストには、標準トリガとサイト定義トリガの両方が表示されます(したがって、サイト定義トリガは、アクティブなリストとサイト定義のリストの両方に一覧表示されます)。
    • LRel定義
      フォームで、2つのテーブル間の多対多リレーションシップを以下のように指定します。
      table1 column1 <> table2 column2
      この場合、LRELはtable1とtable2間の多対多リレーションシップを表しており、仮想列column1はtable1と、仮想列column2はtable2と関連付けられています。
    • アクティブなxRelクエリ情報
      仮想列BRELまたはQRELを定義するクエリのアクティブな値を入力します。 この値は、オブジェクト エンジンMajicの形式で指定します。
    • サイト定義xRelクエリ情報
      BRELまたはQRELと関連付けられたクエリを変更します。 CA のテクニカル サービスから指示があった場合にのみ、このフィールドにデータを入力することをお勧めします。
    • アクティブな派生式
      DERIVED仮想列の値を生成するためにオブジェクト エンジンが使用する式を、アクティブな値として入力します。
    • サイト定義xRelクエリ情報
      DERIVED列に関連付けられた式を変更します。 CA のテクニカル サービスから指示があった場合にのみ、このフィールドにデータを入力することをお勧めします。
    [スキーマ デザイナ テーブル]ダイアログ ボックスの[Domsets]タブには、以下の情報が表示されます。
    • MLIST_DYNAMIC
      WHERE 節のない動的 domset です。
    • MLIST_STATIC
      WHERE 節のない静的 domset です。
    • RLIST_DYNAMIC
      FACTORY ステートメントの STANDARD_LISTS セクションに WHERE 節が定義された動的 domset です。
    • RLIST_STATIC
      FACTORY ステートメントの STANDARD_LISTS セクションに WHERE 節が定義された静的 domset です。
    いずれかの domset をダブルクリックすると、[プロパティ]ダイアログ ボックスが開き、以下のフィールドが表示されます。
    • domset_name
    • fetch_columns
    • max_fetch
    • sort columns (このフィールドのみ編集できます)
    • volatility
    • where
  5. 列を保存するには、以下のいずれかを実行します。
    • テスト システムで作業している場合は、[ファイル]-[保存]を選択します。
    • 実稼働システムで作業している場合は、[ファイル]-[保存してテスト モードに設定]を選択します。
      これにより、変更がデータベースに保存され、オブジェクト エンジンへの変更を定義するファイル(wsptest.mods)がサーバ上に作成されます。 このファイルは、CA SDM インストール ディレクトリの site/mods/majic サブディレクトリに格納されます。 wsptest.modsファイルが作成されると、オブジェクト エンジンがリサイクルされ、新しい変更が使用されるようになります。 この処理は、スキーマの複雑さに応じて、数秒から数分かかります。
      メッセージが表示されます。 [はい]をクリックして続行します。 wsptest.modsファイルが影響するのは、wsp_domsrvrオプションで指定されたオブジェクト エンジンのみです。 同じサーバ上の他のオブジェクト エンジンはこのファイルを処理せず、このファイルが他のサーバに配布されることはありません。 また、テスト モードの新規テーブルと列は、ローカル オブジェクトとしてオブジェクト エンジンに定義されます。 つまり、これらのテーブルと列はオブジェクト エンジンで認識されており、Webフォームで使用できます。 ただしデータベース内には存在しないため、他のユーザには影響しません。 CA SDM の標準ユーザは WSP オブジェクト エンジンを使用しないため、テストしているスキーマ変更の影響を受けません。
    列がテーブルに追加されます。
  6. 追加された属性に Rest API を通じてアクセスするには、以下のコマンドを実行します。
    • pdm_rest_util -newdeploy
      または
    • pdm_rest_util -undeploy
      その後
      pdm_rest_util -deploy
  7. CA SDM サービスを再起動します。
テーブルまたは列の変更
テーブルまたは列の情報を変更するには、スキーマ デザイナで目的のテーブルまたは列をクリックしてから、該当のフィールドに新しい情報を入力します。 変更できる情報は、テーブルまたは列のステータスによって異なります。
  • 標準テーブル
    [表示名]、[説明]、[ファンクション グループ]の各フィールドを変更できます。
  • 標準列
    [表示名]フィールド、[説明]フィールド、[新規作成時のデフォルト値]、[保存時の設定値]を変更できます。 さらに、[必須]または[新規レコードのみ更新可能]のチェック ボックスがオフの場合は、これらをオンにすることもできます。 これらのチェック ボックスがデフォルトでオンになっている場合、オフにすることはできません。 ただし、ユーザが自分でオンにした場合はオフにできます。
  • サイト定義テーブル
    テーブルが発行されていない場合は、[名前]フィールド以外のすべてのフィールドを変更できます。新規のテーブルを保存した後で[名前]フィールドを変更することはできません。 発行済みのサイト定義テーブルでは、[表示名]、[説明]、および[ファンクション グループ]フィールドのみを変更できます。
  • サイト定義列
    列が発行されていない場合は、[名前]フィールド以外のすべてのフィールドを変更できます。新規の列を保存した後で[名前]フィールドを変更することはできません。 発行済みのサイト定義列では、[表示名]フィールド、[説明]フィールド、[新規作成時のデフォルト値]、[保存時の設定値]と、[必須]、[新規レコードのみ更新可能]、[pdm_userload のキー]の各チェック ボックス、および DBMS インデックスのオプションのみを変更できます。
スキーマの変更のテスト
物理的なデータベースを変更する前に、スキーマを使用することで、スキーマ変更のテスト、Webフォームの作成、更新、表示を実行できます。 テスト モードでスキーマの変更をテストすると、これらの変更はオブジェクト エンジンに定義されますが、データベースに物理的に保存されません。 これは、スキーマの変更をテスト モードでテストすると、他のユーザに影響が及ぶ可能性があるからです。したがって、このオプションを使用できるのは、WSPにオブジェクト エンジンを提供するwsp_domsrvrオプションとwsp_webengineオプションをインストールした場合だけです。
スキーマ変更をテスト モードでテストするには、[ファイル]メニューから[保存してテスト モードに設定]を選択します。 これにより、変更がデータベースに保存され、オブジェクト エンジンへの変更を定義するファイルが(ログインしている)サーバ上に作成されます。 このファイルの名前は wsptest.mods であり、CA SDM インストール ディレクトリの site/mods/majic サブディレクトリに保存されます。
wsptest.modsファイルが作成されると、オブジェクト エンジンがリサイクルされ、新しい変更が使用されるようになります。 この処理は、スキーマの複雑さに応じて、数秒から数分かかります。
オブジェクト エンジンのリサイクルが完了すると、スキーマの変更が可能となり、WSPで作成したWebフォーム上で、このスキーマを使用およびテストできます。 テスト モードのテーブルや列のデータは、WSPオブジェクト エンジンの内部ストレージにのみ保存されます。 システムの他のユーザは、このデータを参照できず、影響を受けることもありません。
スキーマの変更の発行
スキーマの変更が完了したら、変更を発行して、すべてのユーザが変更を利用できるようにします。 WSP では、新規作成または更新したテーブルと列がそれぞれ、データベースの wsptbl テーブルと wspcol テーブルに格納されます。
以下の手順に従います。
  1. オブジェクト エンジンと CA SDM ユーティリティ プログラムを対象として、スキーマの変更を定義するファイルを新規作成/更新します。 WSP では、wsp_webengine オプションで指定された Web エンジン(デフォルトでは web:local)に、以下のファイルを作成します。
    • wsp.mods
      Web Screen Painter で管理されている、オブジェクト エンジンに対するスキーマ変更がすべて記述されます。
    • wsp_schema.sch
      Web Screen Painter で管理されているテーブルおよび列がすべて記述されます。
    • wsp_index.sch
      Web Screen Painter で管理されているテーブルの DBMS インデックスが記述されます。
    • wsp.altercol
      WSP で作成され、DBMS には未定義の新規列の名前が指定されます。
    • wsp.altertbl
      WSP で作成され、DBMS には未定義の新規テーブルの名前が指定されます。 さらに、WSP は、オブジェクト エンジンを備えたすべての CA SDM サーバに wsp.mods ファイルを配布します。
  2. [ファイル]-[保存]-[発行]を選択します。
    CA SDM サーバ上に必要なファイルが作成されますが、これらがリサイクルされることはありません。 このため、この操作の直後は新規ファイルの影響はありません。 ただし、ファイルの作成後は、次回 CA SDM サービスがリサイクルされるときに、これらのファイルが使用されます。
  3. 標準設定
    を使用している場合は、以下の手順に従います。
    • プライマリ サーバ上の CA SDM サービスをシャットダウンし、以下のコマンドを実行します。
      pdm_publish
      このコマンドは、物理 DBMS を変更し、新規スキーマの情報を格納します。
      pdm_publish プロセスを実行すると、ほかのユーザに重大な影響を及ぼします。 スキーマの変更の発行は慎重に計画するようにしてください。 CA SDM の変更要求を使用してスキーマ発行のスケジュールを調整し、事前の承認を得ることをお勧めします。
  4. 高可用性設定
    を使用している場合は、以下の手順に従います。
    1. バックグラウンド サーバ上で以下のコマンドを実行して、サポート オートメーションを使用しているすべてのアクティブなユーザに作業を保存するよう通知します。
      sa_server_notifier [-h] | [-q seconds] | [-c]
      • -h
        ヘルプ ページを表示します。
      • -q seconds
        このオプションは、ローカル サーバ(バックグラウンド)に指定された時間間隔内に休止するよう通知します。 この間隔は、サーバがオフラインになるまでの秒数です。 このオプションは、スタンバイ サーバまたはアプリケーション サーバには使用できません。
      • -c
        このオプションは、以前に送信された休止リクエストをキャンセルします。
      バックグラウンド サーバ上でサポート オートメーションを使用しているすべてのアクティブなユーザにポップアップ メッセージが表示されます。 このメッセージは、ユーザにサーバのシャットダウンと、シャットダウンまでに残されたスケジュールされた時間について通知します。 ユーザは自分の作業を保存し、そのスケジュールされた時間内にログアウトする必要があります。
    2. バックグラウンド サーバ上の CA SDM サービスをシャットダウンします。
      WSP から[保存して発行]が実行された後、スタンバイまたはアプリケーション サーバ上の CA SDM サービスを再起動しないでください。 このアクションによって、高可用性設定が中断されます。 スタンバイまたはアプリケーション サーバ上の CA SDM サービスが停止しているときに、これらのサービスを開始したい場合は、CA SDM サービスを開始する前に、サーバ上で pdm_server_control -v コマンドを実行してバージョン管理を抑制します。
      アクティビティの発行中にバックグラウンド サーバに障害が発生した場合は、WSP の変更を回復するようにしてください。 詳細については、「バックグラウンド サーバの障害時の WSP 変更の回復」を参照してください。
    3. 新しいバックグラウンド サーバとして昇格させるスタンバイ サーバ上で、以下のコマンドを実行します。
      pdm_server_control -b
      • -b
        ローカルのスタンバイ サーバにバックグラウンド サーバになるよう通知します。 スタンバイ サーバがすでに実行されている必要があります。 このサーバが実行されていない場合は起動されますが、フェールオーバは実行されません。フェールオーバを開始するには、コマンドを再度実行します。
      バックグラウンド サーバは自動的にシャットダウンし、スタンバイ サーバが新しいバックグラウンド サーバとして昇格されます。 この変更は、エンド ユーザ セッションには影響を与えません。 進行中の更新(存在する場合)は保存され、新しいバックグラウンド サーバがオンラインになるまで遅延されます。
    4. スキーマの変更を使用して DBMS を更新するには、元のバックグラウンド サーバ(現在のスタンバイ サーバ)上で以下のコマンドを実行します。
      pdm_publish
      pdm_publish コマンドは、CA SDM の次の起動でスタンバイ サーバとバックグラウンド サーバの同期を抑制する制御ファイルを作成します。 このアクションは、pdm_publish によって実行されたスキーマ ファイルの変更を保持するために必要です。 このコマンドは、スキーマの変更の正常な発行の後、必要に応じて 2 番目のフェールオーバを実行します。 正常な発行の最後に、以下のメッセージがユーザに表示されます。
      Do you want pdm_publish to start CA Service Desk Manager in this standby server and perform fail-over(Y/N)?
      • 「Y」と入力すると、pdm_publish はスタンバイ サーバ上で CA SDM サービスを開始し、自動的にフェールオーバを実行します。 すべてのアプリケーション サーバ上でスキーマの変更を適用するには、手順 g に進みます。
      • 「N」と入力した場合は、手順 e に進みます。
    5. スタンバイ サーバ(元のバックグラウンド サーバ)上で CA SDM サービスを開始します。
      この起動では pdm_publish によって作成された制御ファイルが検出されますが、スタンバイ サーバとバックグラウンド サーバの同期は実行されません。 同期が実行されないため、この起動では pdm_publish によって実行された変更が保持されます。
      pdm_publish の後に元のバックグラウンド サーバにフェールオーバできないとサービスが中断されるため、これらの指示に正確に従うようにしてください。
    6. スタンバイ サーバ(元のバックグラウンド サーバ)を再度バックグラウンド サーバにするには、そのサーバ上で以下のコマンドを実行します。
      pdm_server_control -b
      このサーバが再度スタンバイ サーバになったときにバージョン管理が正常に機能するように、このコマンドでは制御ファイルも削除されます。
    7. アプリケーション サーバ上で、以下のコマンドを実行します。
      pdm_server_control -q interval -s server_name
      • -q interval -s server_name
        ローカルまたはリモート アプリケーション サーバに指定された時間間隔内に休止するよう通知します。 この間隔は、サーバがオフラインになるまでの秒数です。 server_name を指定せずにこのオプションを使用すると、ローカル サーバに休止するよう通知されます。 このオプションは、バックグラウンドまたはスタンバイ サーバには使用できません。
      指定したアプリケーション サーバ上のすべてのアクティブなユーザにポップアップ メッセージが表示されます。 このメッセージは、ユーザにサーバのシャットダウンと、シャットダウンまでに残されたスケジュールされた時間について通知します。 ユーザは自分の作業を保存し、そのスケジュールされた時間内にログアウトする必要があります。 ユーザが自分の作業を再開するには、更新されたアプリケーション サーバにログオンします。
    8. すべてのスタンバイ サーバを再起動します。
バックグラウンド サーバ障害中の WSP 変更の回復
アクティビティの発行中にバックグラウンド サーバに障害が発生した場合は、MDB スキーマの変更を回復することができます。
実稼働環境で回復手順を直接実行することは推奨されません。 まず、テストまたは開発環境で検証するようにしてください。
以下の手順に従います。
  • 発行前にバックグラウンド サーバがクラッシュした場合は、最後に保存されたスキーマの変更が MDB 内に保持されます。 新しいバックグラウンド サーバにログインし、発行タスクを再開します。
  • 発行後にバックグラウンド サーバがクラッシュした場合は、以下のアクションを実行します。
    1. クラッシュしたバックグラウンド サーバ上の CA SDM サービスを停止します。
    2. 新しいバックグラウンド サーバとして昇格させるスタンバイ サーバを選択します。
    3. クラッシュしたバックグラウンド サーバの以下のファイルを、スタンバイ サーバ上の同じ場所にコピーします。
      • "$NX_ROOT$/site/mods/majic/wsp.mods"
      • "$NX_ROOT$/site/mods/wsp.altertbl"
      • "$NX_ROOT$/site/mods/wsp.altercol"
      • "$NX_ROOT$/site/mods/wsp_index.sch"
      • "$NX_ROOT$/site/mods/wsp_schema.sch
    4. スキーマの変更を発行し、自動フェールオーバを実行するには、スタンバイ サーバ上で以下のコマンドを実行します。
      pdm_publish
    5. スキーマの変更の正常な発行の後に表示されるメッセージ プロンプトで「Y」を選択します。
      CA SDM サービスが、スタンバイ サーバ上で起動されます。
      自動フェールオーバが実行されない場合は、スタンバイ サーバから pdm_server_control -b コマンドを実行して、そのサーバを新しいバックグラウンド サーバに昇格させます。
    6. 各アプリケーション サーバを休止してリサイクルします。 すべてのスタンバイ サーバを再起動します。 詳細については、「スキーマの変更の発行」を参照してください。
スキーマの変更の復元
テスト モードでスキーマの変更を行った後で、スキーマの変更の方針が変わった場合は、発行済みバージョンのスキーマに復元できます。 スキーマの変更を元に戻すと、ほかのユーザに影響を与える可能性があります。 そのため、このオプションを使用できるのは、WSP にオブジェクト エンジンと Web エンジンを提供する wsp_domsrvr オプションと wsp_webengine オプションの両方がインストールされている場合のみです。
以下の手順に従います。
[ファイル]-[テスト モードの復元]を選択します。
WSP によって wsptest.mods ファイルが削除され、WSP オブジェクト エンジンによってスキーマが発行済みバージョンに復元されます。
wsptest.mods ファイルが削除されると、WSP オブジェクト エンジンがリサイクルされ、その内部スキーマが再構築されます。 この処理は、スキーマの複雑さに応じて、数秒から数分かかります。
オブジェクト エンジンのリサイクルが完了すると、アクティブ スキーマは発行済みバージョンに戻ります。
新しいスキーマを使用するように変更された Web フォームは自動的には元に戻されないため、発行済みのスキーマで使用されると正しく動作しない場合があります。
発行後のサイト定義列の変更
WSP では、発行後のサイト定義スキーマ変更を標準スキーマと同様に扱うため、その後の変更は制限されています。 DBMS および WSP の外部のスキーマを手動で更新することにより、サイト定義列を削除したり、サイト定義文字列の列の長さを変更したりすることができます。 次に、pdm_wspupd スクリプトを実行してデータベース wspcol テーブルを更新し、WSP と外部変更を同期させます。
以下の手順に従います。
  1. CA SDM の設定に応じて、以下のサーバにログインします。
    • 標準: プライマリ サーバ
    • 高可用性: バックグラウンド サーバ
  2. CA SDM インストール ディレクトリ内の site/mods サブディレクトリを探します。
    site/mods サブディレクトリ以外の場所に、wsp_schema.sch ファイルのバックアップを作成して、重複ファイルが処理されないようにしてください。
  3. wsp_schema.sch ファイルを編集し、不要なサイト定義列を削除するか、サイト定義の STRING 列の長さを変更します。 これらの更新は、この手順でサポートされている変更のみです。 wsp_schema.sch ファイルは、任意の標準的なテキスト エディタを使用して編集できます。
    列を削除するためにインデックス オプション(UNIQUE など)が指定された場合、wsp_index.sch ファイルを編集してその列の参照を削除します。 その列がテーブル中で唯一のインデックス作成済みの列である場合は、テーブルに対するすべての参照を wsp_index.sch から削除してください。
  4. wsp_schema.sch に加えたのと同じ変更を使用して majic/wsp.mods ファイルを編集します。
    • 不要なサイト定義の列を削除します。
    • サイト定義の STRING 列の長さを変更します。
  5. コマンド プロンプトを使用して、以下のコマンドを入力します。
    pdm_wspupd
    pdm_wspupdスクリプトはwsp_schema.schを読み取り、データベース内のwspcolテーブルと比較して、相違がある場合はそれをコンソール行に書き込みます。 たとえば、以下の出力を参照してください。
    PDM_WSPUPD - Update wspcol table from wsp_schema.sch Reading wsp_schema.sch to for current DBMS information... Reading wspcol table for WSP schema information... String column zSalesOrg.description length changed from 350 to 400 Column zSalesOrg.sym not found in wsp_schema.sch - deleting wspcol row pdm_wspupd found 1 WSP-maintained column(s) to update and 1 to delete. Please verify that your DBMS has been manually updated to correspond to wsp_schema.sch, then reply Y to update wspcol or anything else to cancel.
  6. pdm_wspupd が検出した変更が、wsp_schema.sch に加えた変更と完全に一致するかどうかを確認します。 一致する場合は「
    Y
    」と入力して変更を確認します。
    更新が確認されると、このスクリプトは標準の CA SDM ユーティリティを使用して wspcol テーブルを更新します。 その後、スキーマ デザイナはユーザの変更を表示します。
  7. CA SDM サーバを停止します。
  8. お使いの DBMS 用のユーティリティを使用して、変更した列の DBMS 定義を変更します。
    • wsp_schema.sch から削除したデータベースから任意の列を削除します。
    • wsp_schema.sch で変更した文字列列のデータベース長を変更します。
    DBMS に加える変更は、wsp_schema.sch に加えた変更と完全に一致するようにしてください。
  9. スキーマの変更を発行します。
  10. CA SDM サーバを起動します。