> モデル定義要素のインポート 現在開いているコンテンツファイルをインポート先として、他のコンテンツ（インポート元）ファイル上の定義要素を取り込むための機能です。チームで設計作業を進めたり、既存の設計データの一部を流用して新規の設計データをまとめる場合などに便利です。なお、個々のテーブル定義を他のコンテンツファイルの「最新のテーブル定義」で更新したい場合には、テーブル定義毎にそのコンテンツファイルを「参照先ファイル」として指定しておく「外部参照」の方式が便利です。 ■実行確認用フォームの使い方 ファイルメニューの「インポート」から「モデル情報ファイル(*.xead)より」を選ぶと、まず「インポート元ファイル」を指定するためのファイル選択ダイアログが開きます。そこで既存のモデルファイルを指定すると、以下のような実行確認用フォームが現れます。 「サブシステム」、「職務」、「業務フロー」のいずれかのまとまりに対してインポートを実行します。次図のように、フォーム上の「対象定義要素」のラジオボタンを用いていずれかを選択してください。すなわち、「機能定義」、「テーブル定義」、「テーブル定義と機能定義」のいずれかを選択すれば「サブシステム」がリストボックスに一覧され、「業務定義」を選択すれば「職務」が一覧され、「業務フロー」を選択すれば「業務フロー」が一覧されます。それらのリストボックスで「インポート元／先」を選択すれば、「インポート」のボタンが有効になります。 インポート処理の完了後には、更新を受け入れるか、取り消すか、あるいはファイル名を変更したうえで更新を受け入れるか、を選択するための確認メッセージが、処理結果の概要とともに示されます。メッセージが示された時点でインポート結果の詳細がログファイルとして出力されている(*1)ので、必要に応じて確認してください。 ■インポート処理の制約について インポート処理は、「サブシステム」または「職務」の特定のまとまりを「インポート元」および「インポート先」として指定した形で実行されます。インポートは想像以上に複雑な過程で、いくつかの制約事項があります。次項で「テーブル定義と機能定義」、「業務定義」、「業務フロー」を選択した場合に分けて説明します。 ■サブシステム（テーブル定義群と機能定義群）のインポート 実行確認用フォーム上の「対象定義要素」のラジオボタンで「機能定義」、または「テーブル定義と機能定義」を選択して実行すると、指定した「サブシステム」がインポートされます。　「サブシステム」とは、Modelerで言う「サーバーモジュール」の１ブロックのことで、ひとつのサブシステムはいくつかのテーブル定義と機能定義とを含みます。ラジオボタンで「機能定義」を選択すれば機能定義のみが、「テーブル定義と機能定義」を選択すればテーブル定義と機能とがインポートされます。インポート先に存在しないサブシステムをインポートしたい場合には、ダミーのサブシステムをインポート先にあらかじめ作成して、それをインポート先としてください。 インポート元としてサブシステムＰ、インポート先としてサブシステムＡを指定した場合の例を次図で示します。このように、インポート元の各定義がインポート先に存在するならば更新され（テーブルＴ２と機能Ｆ２）、存在しないならば新規追加されます（テーブルＴ１と機能Ｆ１）。なお、インポート元に存在しないからといってインポート先から削除することまではしません（インポート元にはテーブルＴ３と機能Ｆ３が存在しないが、これらが削除されるわけではない）。したがって、処理後にインポート元サブシステムとインポート先サブシステムとが完全に一致するとは限らない点にご注意ください。 インポート元の定義要素とインポート先の定義要素とをマッピングするためには、各要素の「名前」ではなく「ＩＤ(*2)」が利用される点をしっかり理解しておいてください。たとえば、インポート元とインポート先に以下のような要素が既存であるとします。 ＜インポート元サブシステム＞　　　 　＜インポート先サブシステム＞ ＩＤ（一覧順）名前　　　　　　　　 　ＩＤ（一覧順）名前 ① AF1010　　　　受注エントリー　　　④ AF1010　　　　出荷データの一覧 ② AF1020　　　　出荷データの一覧　　⑤ AF1030　　　　出荷実績エントリー ③ (空白)　　　　出荷指図書発行 この状態でインポート処理を実行すれば、結果は次のとおりになります。 ＜インポート元サブシステム＞　　　　 ＜インポート先サブシステム＞ ＩＤ（一覧順）名前　　　　　　　　　 ＩＤ（一覧順）名前 ① AF1010　　　　受注エントリー　　　④'AF1010受注エントリー ② AF1020　　　　出荷データの一覧　　②'AF1020　　　　出荷データの一覧 ③ (空白)　　　　出荷指図書発行⑤ AF1030　　　　出荷実績エントリー ①はＩＤの一致する④にマッピングされ、④については名前を含めさまざまな情報が更新され、結果的に④'となります。②はＩＤの一致する要素がインポート先に存在しないため、新規追加されて②'となります。また、③はＩＤが空白なので、インポート処理の対象から除外されます。 ＩＤで更新対象を特定できたとしても、その定義要素がインポート先以外のサブシステムに含まれる場合には適切な対象とみなされずに、インポートされません。たとえば、④がインポート先以外のサブシステムに含まれている場合、①から④へのインポートは起こりません。同様に、"AF1020"のＩＤを持つ機能定義がインポート先以外のサブシステムに含まれている場合にも、インポート先で②'は新規作成されません（つまり、②に関しては何も起こりません）。 したがって、ＩＤと、各サブシステムにどの定義要素が含まれているかに関しては、インポート前にしっかり把握しておく必要があります。そうでないと、予期しない更新が起こり得るので注意してください。 なお、各テーブル定義はたいてい他のテーブルとの関連定義をともなっています。ところが、インポート先システムに、関連するはずの相手テーブルが定義されていないケースがあり得ます。もともと相手テーブルがインポート対象になっているのでない限り、Modelerは必要なテーブル定義をわざわざインポート元から引き出して送り込むことはしません。代わりに、「インポート先で、テーブル関連定義に必要なテーブルキー定義が見つからなかった」という旨の警告メッセージをログファイルに出力したうえで、そのような関連定義をインポートから除外します。 同様に、機能定義はしばしば「この機能から呼び出される機能」をともなっていますが、それらがインポート先に定義されていないケースがあり得ます。その場合にModelerは「インポート先で、起動されるはずの機能が定義されていません」という旨の警告メッセージをログファイルに出力したうえで、そのような呼び出し機能に関する情報をインポートから除外します。 インポート処理においては、上記以外にさまざまな定義要素がインポート先に送り込まれます。それらを処理の順序にしたがってまとめると以下のようになります（<　>内はファイル上でのタグ名、(　)内は更新対象の識別基準）。このように、部分的にＩＤ（一覧順）とは異なる基準で更新対象を識別するようになっています。 １　<TableType>テーブルタイプ一覧（テーブルタイプＩＤ） ２　<DataType>データタイプ一覧（データタイプＩＤ） ３　テーブル定義 ３．１　<Table>テーブル属性（テーブルＩＤ） ３．２　<TableField>テーブル別フィールド定義（フィールドＩＤ＋フィールド名） ３．３　<TableKey>テーブル別キー定義（キーのフィールド構成とキータイプ） ４　<Relationship>テーブル関連（キーのフィールド構成とキータイプ）*3 ５　サブシステム定義 ５．１　<Subsystem>サブシステム属性（サブシステムＩＤ） ５．２　<SubsystemTable>サブシステム別テーブル属性（テーブルＩＤ） ５．３　<SubsystemRelationship>サブシステム別テーブル関連（キーのフィールド構成とキータイプ） ６　<FunctionType>機能タイプ一覧（機能タイプＩＤ） ７　機能定義 ７．１　<Function>機能属性（機能ＩＤ） ７．２　<IOPanel>パネル入出力定義（入出力ＩＤ＋パネル名） ７．３　<IOWebPage>ＷＥＢページ入出力定義（入出力ＩＤ＋ページ名） ７．４　<IOSpool>スプール出力定義（入出力ＩＤ＋スプール名） ７．５　<IOTable>テーブル入出力定義（入出力ＩＤ＋テーブルＩＤ） ８　<FunctionUsedByThis>機能別呼出機能（機能ＩＤ） 対象定義要素のラジオボタンで「機能定義」を選択すれば上記の５．１および６～８がインポートされ、「テーブル定義と機能定義」を選択すれば１～８のすべてがインポートされます。ＩＤ別のテーブル定義管理が厳密になされていない態勢では、テーブル定義のインポートにともなって予期しない更新が起こりがちです。したがって、特別な場合を除き、対象定義要素として「テーブル定義と機能定義」を選択しないことをおすすめします。 ■職務（機能定義群）のインポート 実行確認用フォーム上の「対象定義要素」のラジオボタンで「業務定義」を選択して実行すると、指定した「職務」がインポートされます。　「職務」とは、Modelerにおいては「いくつかの業務を担当する業務上の権限」のことで、ひとつの職務はいくつかの業務定義を含み、これらがインポートの対象となります。インポート先に存在しない職務をインポートしたい場合には、ダミーの職務をインポート先にあらかじめ作成して、それをインポート先としてください。 インポート元として職務Ｐ、インポート先として職務Ａを指定した場合の例を次図で示します。このように、インポート元の各定義がインポート先に存在するならば更新され（業務２）、存在しないならば新規追加されます（業務１）。なお、インポート元に存在しないからといってインポート先から削除することまではしません（インポート元には業務３が存在しないが、これが削除されるわけではない）。したがって、処理後にインポート元職務とインポート先職務とが完全に一致するとは限らない点にご注意ください。 インポート元の定義要素とインポート先の定義要素とをマッピングするためには、各要素の「名前」ではなく「ＩＤ（一覧順）(*2)」が利用される点をしっかり理解しておいてください。たとえば、インポート元とインポート先に以下のような要素が既存であるとします。 ＜インポート元職務＞　　　 　　　　＜インポート先職務＞ ＩＤ（一覧順）名前　　　　　　　 　ＩＤ（一覧順）名前 ① 1010　　　　　受注登録業務　　　④ 1010　　　　　出荷指図業務 ② 1020　　　　　出荷指図業務　　　⑤ 1030　　　　　売上返品報告 ③ (空白)　　　　出荷実績報告 この状態でインポート処理を実行すれば、結果は次のとおりになります。 ＜インポート元職務＞　　　 　　　　＜インポート先職務＞ ＩＤ（一覧順）名前　　　　　　　　 ＩＤ（一覧順）名前 ① 1010　　　　　受注登録業務④'1010 受注登録業務 ② 1020　　　　　出荷指図業務②'1020出荷指図業務 ③ (空白)　　　　出荷実績報告 ⑤ 1030　　　　　売上返品報告 ①はＩＤの一致する④にマッピングされ、④については名前を含めさまざまな情報が更新され、結果的に④'となります。②はＩＤの一致する要素がインポート先に存在しないため、新規追加されて②'となります。また、③はＩＤが空白なので、インポート処理の対象から除外されます。 ＩＤで更新対象を特定できたとしても、その業務定義がインポート先以外の職務に含まれる場合には適切な対象とみなされずに、インポートされません。たとえば、④がインポート先以外の職務に含まれている場合、①から④へのインポートは起こりません。同様に、"1020"のＩＤを持つ業務定義がインポート先以外の職務に含まれている場合にも、インポート先で②'は新規作成されません（つまり、②に関しては何も起こりません）。 したがって、ＩＤと、各職務にどの定義要素が含まれているかに関しては、インポート前にしっかり把握しておく必要があります。そうでないと、予期しない更新が起こり得るので注意してください。 なお、それぞれの業務定義は、パネルやスプール定義を用いてどのように仕事を進めるかを記述したものであるため、それらをインポートする際には、インポート先システムにおいて関連パネル／スプール定義が存在することが前提となります。もし、関連パネル／スプール定義が見つからない場合には、Modelerはそれをわざわざインポート元システムからインポートするようなことはしません。代わりに、「インポート先で、関連するパネル／スプール定義が見つからなかった」という旨の警告メッセージをログファイルに出力したうえで、インポートから除外します。 したがって、業務定義をインポートする際には、業務が利用するはずの機能定義およびパネル／スプール定義が、想定されたＩＤでインポート先に既存であることを事前に確認しておいてください。 ■業務フロー（サブジェクトエリア）のインポート 実行確認用フォーム上の「対象定義要素」のラジオボタンで「業務フロー」を選択して実行すると、指定した「業務フロー」がインポートされます。　インポート先に存在しない業務フローをインポートしたい場合には、ダミーの業務フローをインポート先にあらかじめ作成して、それをインポート先として選択してください。 なお、業務フロー上の「プロセス」は「業務定義」にリンクされた定義要素です。それゆえに、インポート先において未知であるような業務定義がプロセスとして載っていた場合、業務フローのインポート処理はキャンセルされます。したがって、関連する業務定義をあらかじめインポートしたうえで、業務フローをインポートするようにしてください。 *1.XeadImportLog9999999999.txt（数字部分には現在日付と時刻が入る）の名前で、インポート先ファイルと同じフォルダに出力されます。 *2.本ページで言う「ＩＤ」とは、Modeler上で編集可能な「ＩＤ（一覧順）」のことです。コンテンツファイル内では、それぞれの定義要素はユーザーの目に触れない内部的なＩＤによって識別されています。つまり、インポートはそれらの内部的なＩＤではなく、ユーザーに可視的なＩＤにもとづいてなされるということです。コンテンツファイルの様式上では前者は"ID"の属性名で、後者は"SortKey"の属性名で保持されています。 *3.対象サブシステムに含まれるテーブル定義が関係するテーブル関連定義のみがインポートされます。ただし、テーブル関連は２つのテーブル定義が関わるものです。したがって、インポート先において、必要なテーブル定義が既存であるようなテーブル関連定義が対象となります。

> 「概要と目次」へ