mqsimigratemsgflows コマンドを使用して、メッセージ・フローをバージョン 2.1 からバージョン 6.0 にマイグレーションします。バージョン 5.0 からバージョン 6.0にマイグレーションするときには、このコマンドを使用する必要はありません。
このトピックには、以下のセクションが含まれています。
mqsimigratemsgflows コマンドを使用するための条件
- メッセージ・フローをバージョン 2.1 からエクスポート・ファイルにエクスポートします。SupportPac ユーティリティーを使ってファイルを作成することができ、
これらのエクスポート・ファイルはマイグレーション・プロセスへの入力になります。
- 複数のエクスポート・ファイルにあるメッセージ・フローは、発生するたびにマイグレーションされます。メッセージ・フローのマイグレーション時、同じ名前を持つ以前のフローは警告なしで上書きされます。
- メッセージ・フローおよび関連するサブフローは、同じファイルにエクスポートする必要があります。これが、バージョン 2.1のデフォルトのエクスポート動作です。これにより、他のメッセージ・フローおよびサブフローへの参照を識別および解決し、一貫性を保ったままオブジェクトを名前変更できます。マイグレーションでは、フローとサブフローをリンクし、メッセージ・フロー・ファイルに名前を付けるために、UUID ではなくメッセージ・フローの名前を使用します。
- メッセージ・フローが、見つからないがプロジェクト中に存在すると考えられるサブフローを参照する場合、
そのサブフローが個別にマイグレーションされ、名前が変更されたために矛盾した方法で内部参照された可能性があります。この状態を訂正するには、メッセージ・フローを再度同じエクスポート・ファイルにエクスポートします。
- ユーザー定義ノードは、それらのノードを使用するメッセージ・フローと同じエクスポート・ファイルにエクスポートする必要があります。そうしないと、ユーザー定義ノードへ参照を行うメッセージ・フローが、
.msgnode ファイルではなく .msgflow ファイルとしてこれらのノードを参照してしまいます。
マイグレーション・レポートは、これが発生したかどうかを指定します。
- 入力ノードでもあるユーザー定義ノード (メッセージを受け入れるノードなど) では、
マイグレーション後にメッセージ・ノード・エディターを使用して、新しい「input node」システム・プロパティーを設定する必要があります。これにより、Rational Application Developer は、同じレベル、例えば MQInput でこれらのノードを認識できます。
- マイグレーションが完了したら、ワークベンチを開きます。
プロジェクトが閉じている場合はそれを開き、プロジェクトが開いている場合はリフレッシュし、「プロジェクト」->「クリーンアップ」をクリックすることによりすべてのプロジェクトをクリーンアップします。
- ESQL コードは、バージョン 2.1 メッセージ・フローからコピーされ、MODULE 内に配置されます。コードの変更はありません。
- ESQL フィルター式は、次の方法でマイグレーションされます。
- RETURN ステートメントがコードにある場合、他の計算式、フィールド・マッピング、
またはデータベース・ステートメントと同じように、モジュールが作成されます。
- RETURN ステートメントが見つからない場合、ESQL コードは RETURN ステートメントにラップされています。
RETURN ステートメントの検出が予想通りにならなかった場合に備えて、
このマイグレーションの結果を見直してください。
カスタム・プロパティー・エディター
ユーザー定義ノードまたはプロモート・プロパティーにプロパティー・エディターがある場合、XML 属性は type="MyType"で、クラス <package>MyTypePropertyEditor.class が存在します。
プロパティー・エディター自体 (Java コードで作成) はマイグレーションされません。しかし、同じクラス名で新しいものが作成される場合 (Eclipse SWT ツールキットを使用)、
マイグレーション済みフローを変更しなくても新しいエディターが見つかり、ロードされます。
プロモートされるプロパティー名
バージョン 2.1 では、プロモート・プロパティーがドラッグ・アンド・ドロップ処理によって
作成されると、プロパティー名 (xmi.label) は属性名を変換したものに設定されます。元の属性名にはスペースが入っていてはなりません。
スペースがあると、ブローカーによって拒否されます。
ただし、プロモート属性はブローカーには送信されないため、バージョン 2.1 ではプロモート属性にはスペースが含まれることもあります。
メッセージ・フローのマイグレーション時、元の名前は失われ、変換されたもののみが保持されます。プロモート属性は複数の属性をオーバーライドできるため、元の名前と変換された名前が対応している必要があります。
解決策は、スペースまたは他の問題になる文字を、
Unicode 表記で置換することによって適切な属性名を生成することです。
propertyDescriptor の propertyName 属性は、key=Property.<変換された属性名> に設定されます。
UI は、 <変換された属性名> を戻します。
しかし、マイグレーションされるメッセージ・フローは、属性システム名を保管せず、変換された名前のみを保管しています。したがって、オリジナルの属性を見つけるのは困難か、または不可能です。
例えば、DataSource プロモート・プロパティーは、メッセージ・
フローがプラグイン・フローとして配送され、別のユーザー・フローがプラグイン・フローから
プロパティーをプロモートする場合、変換されたものとしては表示されません。
無効なバージョン 2.1 の名前の変換
メッセージ・フローおよびプロパティーには、バージョン 6.0 で無効な名前が含まれていることがあります。この状態が発生する場合、次のような変換が行われます。
問題となる各文字が、その Unicode コード・ポイントを表す一連の文字で置換されます。
例えば、感嘆符 ("!") は X0026 で置換されます。
これは、生成されるレポート・ファイルで説明されます。
変換は決定論的に行われます。
メッセージ・フローが別の機会にマイグレーションされ、無効な文字を持つフローを参照する場合、両方の名前が同じ方法で変換されます。
これらの変換では、非常にまれな状況を除けば、名前の対立が起きることはありません。
名前のなかで、別の名前の対応する文字が位置するちょうどその場所に、Unicode コード・ポイント・シーケンスが発生するために矛盾が発生します。この場合、これらのメッセージ・フローまたはプロパティーの 1 つの名前を変更し、
フローを再エクスポートします。Unicode コード・ポイント・シーケンス ('Xnnnn') を含まない新しい名前を選択し、マイグレーション前に コントロール・センター のメッセージ・フロー名を変更してください。
ファイル・システム内の .msgflow ファイルは名前変更しないでください。
名前変更タスクの実行には、常に コントロール・センター または ワークベンチ を使用してください。
ノード・タイプのマッピング
バージョン 2.1 ノードは、以下のように
バージョン 6.0 ノードに変換されます。
バージョン 2.1 ノード |
バージョン 6.0 |
Compute |
Compute |
Database |
Database |
DataDelete |
Database |
DataInsert |
Database |
DataUpdate |
Database |
Extract |
Compute |
Filter |
Filter |
Warehouse |
Database |