Maven アダプターの操作には、開発者のワークステーションにインストールされた Apache Maven が必要です。

1. Apache Maven をインストールします。
   • Apache Maven の .zip をダウンロードします。
   • MVN_PATH 変数を追加し、Maven フォルダーを指すようにします。
   • Mac および Linux:
     ~/.bash_profile を次のように編集します。

     #### Apache Maven example location
     
     export MVN_PATH="/usr/local/bin"

   • Windows: このガイドに従ってください。
   • 次のコマンドを実行してインストールを検証します。mvn -v
2. この手引きでは、MobileFirst CLI を使用して、アダプターを作成しビルドするための Maven コマンドを呼び出します。
   • このツールが稼働するための前提条件である NodeJS をまだインストールしていない場合は、 NodeJS をインストールします。
   • コマンド・ライン・ウィンドウで、コマンド npm install -g mfpdev-cli を実行します (または、MobileFirst Operations Console でダウンロード・センターから NodeJS をダウンロードしてインストールします)。
   • 次のコマンドを実行してインストールを検証します。mfpdev -v

ユーザー独自のアダプター・タイプおよびアダプター名ならびにパッケージ名と一致する、新しいアダプター・テンプレートを作成します。
こうすることで、アダプターのメタデータが類似したものとなり、余計な編集が不要になるため、マイグレーションが容易になります。

• コマンド・ライン・ウィンドウで次のコマンドを実行します。mfpdev adapter create
• アダプター・タイプとして、HTTP または SQL の JavaScript アダプター、または Java アダプターを選択します。
• GroupID を指定します。
• Java アダプターを作成する場合は、必ず、それまで使用していたのと同じパッケージ名を指定します (例えば、「com.sample」) 。

実際のマイグレーションに向けてマイグレーション・ツールを実行する前に、マイグレーションのモードを設定します。サポートされている 2 つのモードがあります。

• migrate
  migrate モードでは、クライアント・アプリケーションのマイグレーションをサーバー・マイグレーションとともに活用して、アプリケーションとアダプターを Mobile Foundation v8.0 にマイグレーションできます。
• compatibility
  compatibility モードを設定すると、サーバー・マイグレーションのみが許可されます。クライアント・マイグレーションは、Mobile Foundation Migration Studio を使用して行います。

マイグレーション・モードを設定するには、以下のコマンドを実行します。

注: scan コマンドと client コマンドは、モードが compatibility に設定されていると実行できません。マイグレーション・アシスト・ツールを server オプション用いて実行し、より古い worklight プロジェクトの root ディレクトリーを指定します。

1. 7.1 worklight プロジェクトを Mobile Foundation v8.0 にマイグレーションするには、マイグレーション・アシスト・ツールを以下のように実行します。
   mfpmigrate server --In /Users/WorklightProject**/ --Out /Users/Migrate80Project
   
   

   構文

   mfpmigrate server [--in|-i <sourceDirectory>] [--out|-o <destinationDirectory>] [--projectName|-p <newProjectDirectory>]

   
   

   説明

   既存の MobileFirst プロジェクトからセキュリティー・レルムとアダプターのマイグレーションを実行します。

   
   

   オプション

   <sourceDirectory>: <sourceDirectory> は、マイグレーションする MobileFirst プロジェクトの root フォルダーでなければなりません。このパラメーターは必須です。

   <destinationDirectory>: <destinationDirectory> は、アダプターのマイグレーション先となるディレクトリーです。

   マイグレーション・ツールは、アダプターとレルムをスキャンします。次に、以下を実行します。

   1. アダプターおよびサポートされているセキュリティー検査用のテンプレートを作成します。
   2. アダプター・ソースを、新しく作成した Maven 成果物に移動します。
   3. 依存関係を使用して、プロジェクト pom を更新します。
   4. このツールを使用して実行された内容と、マイグレーションを完了するために手動で実行されるその他の変更内容を記したサマリー・レポートを作成します。

2. 既存のアダプターおよび worklight.properties ファイルの場合、このツールは非推奨および非サポートの API を 7.1 アダプターからすべて識別し、以下を実行します。

   1. 非推奨/非サポートの API を適切な v8.0 API で置換します。
   2. 指定された出力ロケーションで、v7.1 アダプターに対応する v8.0 アダプターを生成します。
   3. 開発者はマイグレーションされたアダプターのディレクトリーに移動し、単一の maven コマンド (mvn clean install  adapter:deploy) を発行することで、アダプターをビルドして Mobile Foundation v8.0 サーバーにデプロイできます。

      注: マイグレーションされたアダプターの pom.xml によって、アダプターはローカルで実行されている Mobile Foundation サーバーにデプロイされます。アダプターを別の Mobile Foundation サーバー・インスタンスにデプロイする場合は、pom.xml にあるサーバーの詳細と資格情報を更新し、maven コマンドを発行します。

   4. worklight.properties ファイルをスキャンして、いずれかのプロパティーが Mobile Foundation v8.0 サーバーへの明示的な JNDI 値の組み込みを必要としているかを把握し、これらのエントリーをレポートに出力します。

3. レルムの場合、このツールはサポート対象のレルムと非推奨のレルムを AuthenticationConfig.xml からすべて識別し、以下を実行します。

   1. サマリー・レポートでは、ユーザーの認証構成で使用されているレルム (事前に構成済みで、事前定義されたセキュリティー検査によって v8.0 で使用可能なもの) のリストが要約されます (ユーザーは、さらなるアクションを行う必要はありません)。
   2. 非サポートのレルムが要約されます (Mobile Foundation v8.0 では、これらのレルムはサポートされません)。
   3. マイグレーションが必要なサポート対象のレルムに対して、以下のステップを実行します。
      1. 特定のレルムのマイグレーションに最適な SecurityCheck を識別します。
      2. 識別した SecurityCheck 基本クラスを使用し、レルムと同じ名前で SecurityCheck というサフィックスを付けて、SecurityCheck テンプレートを生成します。
      3. レルムでチャレンジと検証のメソッドを識別し、これらを対応する SecurityCheck メソッドにインライン・コメントとしてコピーすることで、ユーザーがそれを参照して、生成された新しい SecurityCheck テンプレートで同じ検証を実装できるようにします。

         レルムのメソッドに実装されているどの認証ロジックが、生成された SecurityCheck テンプレートに適しているかを明確にするために、このマッピングを参照してください。

         アダプター認証レルム

         アダプター・オーセンティケーター・レルムは、AuthenticationConfig.xml で定義します。以下にサンプルの定義を示します。

         
         <realm loginModule="SampleLoginModule" name="SampleRealm">
           <className>com.worklight.integration.auth.AdapterAuthenticator</className>
           <parameter name="login-function" value="SampleAdapter.onAuthTrigger"/>
           <parameter name="logout-function" value="SampleAdapter.onLogout"/>
         </realm>
         

         v7.1 における上記の構成の場合、以下のようにこれを ValidationCredentialsSecurityCheck にマップすることができます。

         ValidationCredentialsSecurityCheck.createChallenge	SampleAdapter.onAuthTrigger で使われたアプローチと同じアプローチを使用して、チャレンジを実装できます。ただし、マイグレーションの実行時に気を付けるべきインターフェースの変更があることに注意してください。
         ValidationCredentialsSecurityCheck.validateCredentials	上記のレルム定義では、これと類似するマッピングがないことに注意してください。このため、このメソッドではマッピングはできません。実際に、あるお客様は、v7.1 でリソース・アダプター・メソッドの 1 つにこれを実装し、チャレンジ・メソッドが成功したあとアプリケーションの ChallengeHandler からこれを呼び出していました。

         v7.1 でサポートされているすべてのレルム (Form Based Authenticator レルム、Basic Authenticator レルム、Custom Authenticators レルムなど) に対し、その v7.1 定義に基づいて、同様のマッピングが行われます。

         v7.1 でのレルム・タイプ	レルムでのメソッド定義	SecurityCheck メソッド (Mobile Foundation v8.0)
         CustomAuthentication	createIdentity	<UserAuthenticationSecurityCheck> createUser
         	processRequest	createChallenge
         	CustomAuhenticator. processAuthenticationFailure CustomAuhenticator.changeResponse on success CustomLoginModule.login	validateCredentials
         	CustomLoginmodule.logout	Logout
         フォーム・ベースのオーセンティケーター	CustomLoginModule.login	<UserAuthenticationSecurityCheck> validateCredentials
         	CustomLoginmodule.logout	Logout

4. サマリー・レポートは、次のように使用します。

   1. マイグレーション・アシスト・ツールを使用して実行された内容を理解します。
   2. 単純なマイグレーションが可能な個所で、サポートされていない API をサポートされている API にマップします。
   3. レガシー worklight プロジェクトで使用している、サポートされていないアダプターとレルムを識別します。
   4. 既存の設計に存在するその他の技術的課題やボトルネックについて理解し、以下に記した新しい開発概念を参照して、そのような課題にどのように対処できるかを確認します。

1. ファイル・システム内をナビゲートして、JavaScript アダプター・フォルダーに移動します。例: ../Desktop/JavaScriptAdapters/adapters/RSSReader
2. 別のウィンドウを開いて、新規 Maven プロジェクト (例: ../Desktop/MigratedAdapter) に移動し、src/main/adapter-resources フォルダーに移動します。
3. 既存のアダプター・ファイルをこのフォルダーにコピー・アンド・ペーストします。
4. adapter.xml の編集: そのコンテンツを、既存のアダプターの XML コンテンツ (この例では RSSReader.xml) に置き換えます。
5. js/{adapter-name}-impl.js の編集: そのコンテンツを既存のアダプターのコンテンツ (この例では RSSReader-impl.js) に置き換えます。

1. ファイル・システム内をナビゲートして、JavaScript アダプター・フォルダーに移動します。例: ../Desktop/JavaScriptAdapters/adapters/SQLAdapter
2. 別のウィンドウを開いて、新規 Maven プロジェクト (例: ../Desktop/MigratedAdapter) に移動し、さらに src/main/adapter-resources フォルダーに移動します。
3. adapter.xml の編集: そのコンテンツを、既存のアダプターの XML コンテンツ (この例では SQLAdapter.xml) に置き換えます。
4. js/{adapter-name}-impl.js の編集: そのコンテンツを既存のアダプターのコンテンツ (この例では SQLAdapter-impl.js) に置き換えます。

ここから Maven の依存関係が関係してきます。以前にデータベース・コネクターが配置されていた server/lib フォルダー内の場所では Worklight/MobileFirst Studio は使用されないため、これを Maven の依存関係に置き換えます。

1. 新たに作成した Maven プロジェクトに戻り、ディレクトリーのルートに配置されている pom.xml ファイルを開きます。
2. データベース・タイプに適した依存関係を追加します。使用すべき適切な依存関係は、Maven Central Web サイトで検索できます。
3. この例では、MySQL データベースを使用します。dependencies セクションに、次のコード・ブロックを追加します。

   <dependency>
       <groupId>mysql</groupId>
       <artifactId>mysql-connector-java</artifactId>
       <version>5.1.6</version>
   </dependency>

追加の依存関係がある場合は、pom.xml ファイルに追加して、それらの依存関係を指すようにします。ローカル・ファイルでも、リモート依存関係でもかまいません。

Maven の依存関係についてもっとよく知る:

• 依存関係のメカニズムの概要 (Maven.org)
• 依存関係の処理 (チュートリアル)

これまでに行ったことを別の見方で確認するための「図」を、以下に示します。

MyProject
├── adapters
│   ├── RSSAdapter
│   │   ├── RSSAdapter-impl.js
│   │   ├── RSSAdapter.xml
│   │   └── filtered.xsl

RSSAdapter
├── pom.xml
├── src
│   └── main
│       ├── adapter-resources
│       │   ├── adapter.xml
│       │   └── js
│       │        ├── RSSAdapter-impl.js
│       │        └── filtered.xml

1. ファイル・システム内をナビゲートして、Java アダプター・フォルダーに移動します。例: ../Desktop/JavaAdapters/RSSAdapter
2. もう 1 つのウィンドウを開いて、新規 Maven プロジェクト (例: ../Desktop/MigratedAdapter) に移動し、src/main/adapter-resources フォルダーに移動します。
3. {adapter-name}.xml の編集: そのコンテンツを既存のアダプターの XML コンテンツ (この例では RSSAdapter.xml) に置き換えます。
4. 新規アダプター内で、src/main/java/com/sample/ (この例の場合) に移動します。
5. 既存の .java ファイルを、既存のアダプターの .java ファイルに置き換えます。

既存のアダプターで追加のライブラリーを使用している場合は、ここで Maven の依存関係が関係してきます。以前にライブラリーが配置されていた server/lib フォルダー内または Java アダプターの lib フォルダー内の場所では Worklight/MobileFirst Studio は使用されないため、これらを Maven の依存関係に置き換えます。

1. 新たに作成した Maven プロジェクトに戻り、ディレクトリーのルートに配置されている pom.xml ファイルを開きます。
2. データベース・タイプに適した依存関係を追加します。使用すべき適切な依存関係は、Maven Central Web サイトで検索できます。
3. この例では、Cloudant 依存関係を使用します。dependencies セクションに、次のコード・ブロックを追加します。

   <dependency>
   	<groupId>com.cloudant</groupId>
   	<artifactId>cloudant-client</artifactId>
   	<version>1.2.3</version>
   </dependency>

Maven の依存関係についてもっとよく知る:

• 依存関係のメカニズムの概要 (Maven.org)
• 依存関係の処理 (チュートリアル)

これまでに行ったことを別の見方で確認するための「図」を、以下に示します。

├── adapters
│   └── RSSAdapter
│       ├── RSSAdapter.xml
│       ├── lib
│       └── src
│           └── com
│               └── sample
│                   ├── RSSAdapterApplication.java
│                   └── RSSAdapterResource.java

├── pom.xml
├── src
│   └── main
│       ├── adapter-resources
│       │   └── adapter.xml
│       └── java
│           └── com
│               └── sample
│                   ├── RSSAdapterApplication.java
│                   └── RSSAdapterResource.java
└

マイグレーション済みアダプターのビルド

コマンド・ライン・ウィンドウで、アダプターのフォルダーに移動し、次のコマンドを実行します。mfpdev adapter build

このようなエラーを解決するには、Maven プロジェクトを IntelliJ などの IDE にインポートし、IDE でプロジェクトをビルドすることを推奨します。 自由に使える IDE なら、ビルド・エラーを繰り返しながら 1 つずつエラーを解決することも容易に行えます。IntelliJ とアダプターの使用についてもっとよく知る。

ビルド済みアダプターのテスト

マイグレーション済みのアダプターをテストする場合、MobileFirst CLI を使用してエンドポイントを呼び出すことも、MobileFirst Operations Console から Swagger を使用することもできます。

アダプターのテストおよびデバッグチュートリアルで、アダプターのテストについてもっとよく知る。