MobileFirst Foundation 8.0 マイグレーションの手引き

improve this page | report issue

概説

この手引きは、IBM Worklight Foundation 6.2 または IBM MobileFirst Platform Foundation 6.3 から 7.1 までのアプリケーションとアダプターを IBM Mobile Foundation 8.0 にマイグレーションするための手順の概略を、簡潔明瞭に示すことを目的としています。

このマイグレーション・プロセスには、クラシック・ハイブリッド・アプリケーションを標準の Cordova アプリケーションに変換するための手順と、ネイティブ・アプリケーションの MobileFirst SDK を更新するための手順が示されています。モバイル Web アプリケーションについても扱います。アダプターは Maven プロジェクトにマイグレーションします。さらに MobileFirst のセキュリティー・フレームワーク、プッシュ通知、ダイレクト・アップデートなど、実装の概念についても説明します。

マイグレーション・プロセスのいくつかの側面を容易にするため、マイグレーション・アシスト・ツールが用意されています。
このツールは、非推奨となった API、非サポート対象となった API、または変更された API など、コードベース内の検査および変更が必要な領域を特定することによって、ユーザーを支援します。

注: この手引きは、あり得るすべてのマイグレーション・シナリオをカバーすることは意図していません。 包括的な資料としては、マイグレーションに関するユーザー向けの文書を参照してください。

ヘルプの利用

Mobile Foundation チームでは、お客様のどのような疑問に対してもお力添えしたいと考えております。
公式サポートを得る場合は、 PMR を開いてくださいStackOverflow当チームの気軽なコミュニティーで質問することもできます。

クイック・スタート

アプリケーションおよびアダプターのマイグレーションを開始する前に、まだクイック・スタート・チュートリアルに目をとおしていない場合は、ひととおり目を通して、Mobile Foundation 8.0 についてよく理解し、実際に体験することをお勧めします。

アプリケーションの登録、アダプターのビルドとデプロイ、セキュリティーおよび認証の実装と構成といったトピックに関するチュートリアルに、詳しい情報が記載されています。




セットアップとツール

マイグレーションを開始するためには、稼働している MobileFirst Server インスタンスと、マイグレーション・アシスト・ツールが必要です。

MobileFirst Server

Mobile Foundation Bluemix サービスを使用すると、IBM Bluemix 上に MobileFirst Server をセットアップできます。または、 MobileFirst Developer Kit を使用して、ローカルに稼働するサーバーをセットアップできます。

マイグレーション・アシスト・ツール

MobileFirst Server が稼働したら、まず最初に、後で使用することになるマイグレーション・アシスト・ツールをインストールします。

  1. このツールが稼働するための前提条件である NodeJS をインストールします。
  2. MobileFirst Operations Console で、サイドバー・ナビゲーションの下部にある「ダウンロード・センター」リンクをクリックします。指示に従い、NPM から、または .zip ファイルをダウンロードすることにより、マイグレーション・アシスト・ツールをインストールします。
MobileFirst Operations Consoleからマイグレーション・ツールをダウンロードします。


アプリケーションのマイグレーション

クラシック・ハイブリッドまたは MobileFirst の Cordova アプリケーション、Web アプリケーション、ネイティブ ・アプリケーションをマイグレーションする場合は、マイグレーション・アシスト・ツールを実行して API の変更を判定する、プロジェクト構造をセットアップする、アプリケーション・ソースを管理する、パッケージ・マネージャーを使用する、API の変更を処理する、といった手順を踏みます。

クラシック・ハイブリッド・アプリケーション

以前のリリースでは、Eclipse 用の MobileFirst Studio プラグイン、または MobileFirst CLI を使用して、クラシック・ハイブリッド・アプリケーションの作成、開発、ビルド、および管理を行っていました。 Mobile Foundation 8.0 からは、以前のアプリケーション・モデルに代わるものとして、標準 Cordova アプリケーション用のサポートが導入されています。

Cordova CLI など、コミュニティーの標準ツールを使用して Cordova アプリケーションを作成します。 Cordova プラグインのセットとして Cordova CLI の使用環境に MobileFirst Cordova SDK が加わったものを npm から入手できます。

標準の Cordova アプリケーションへと推移することで、開発者にとっては、好みのツールを使用し、独自のアプローチでアプリケーション開発を行える道が開けています。開発者として、Cordova エコシステムの力を活用できる環境が実現しています。

ヒント: Cordova アプリケーション開発用に Eclipse をセットアップすることもできます。

Cordova アプリケーション開発についてもっとよく知る。

ステップ 1

コマンド・ライン・ウィンドウを開き、次のような方法でマイグレーション・アシスト・ツールを使用します。

  • クラシック・ハイブリッド・プロジェクトのスキャンと API レポート生成だけを行うには、次のコマンドを使用します。
    mfpmigrate scan --in path_to_source_directory --out path_to_destination_directory
  • クラシック・ハイブリッド・プロジェクトをスキャンし、定義済み Cordova プロジェクトを作成するには、次のコマンドを使用します。
    mfpmigrate client --in path_to_source_directory --out path_to_destination_directory [--projectName location_of_project]
    注: このアクションは、インターネットの接続状況によっては、完了までに時間がかかることがあります。プロセスの一部として、MobileFirst Cordova SDK プラグインのダウンロードが行われるためです。
  • source_directory は、Studio プロジェクトのアプリケーション・フォルダーに配置されている application フォルダーのパスに置き換えてください。例: ../Desktop/InvokingAdapterProcedures/apps/InvokingAdapterProcedures
  • destination_directory は、変換後のアプリケーションと生成された API レポートの格納先となるフォルダーのパスに置き換えてください。
  • location_of_project は、destination_directory 内での、作成後のプロジェクトの配置場所となるディレクトリー名に置き換えてください。このフラグはオプションです。
クラシック・ハイブリッド・アプリケーションの標準 Cordova アプリケーションへのマイグレーション

マイグレーション・アシスト・ツールが正常に実行されると、次のような作用を確認できます。

  • MigratedProject フォルダーには、クラシック・ハイブリッド・アプリケーションと同じメタデータ (クラシック・ハイブリッド・アプリケーションの設定に依存する、アプリケーション ID およびその他の設定) を持つ新しい Cordova アプリケーションが含まれ、MobileFirst Cordova SDK がインストールされ、必要なプラットフォームが追加されています。
  • client コマンドが使用された場合は、API レポート {app-name}-api-report.html が生成されていて、デフォルト・ブラウザーで開いています。このレポートには、Mobile Foundation 8.0 用にアプリケーションの実装を調整するために従うことが必要になる場合があるアクションが含まれています。
API レポート

ステップ 2

生成された API レポートに従ってアクションを行う前に、アプリケーションのソース・コードを、クラシック・ハイブリッド・アプリケーションから Cordova アプリケーションにコピーする必要があります。

クラシック・ハイブリッド・アプリケーション

common フォルダーの内容をコピーして、Cordova アプリケーションの www フォルダーに貼り付けます (置き換えるようプロンプトが出された場合は、置き換えます)。

MFPF 7.1 Cordova アプリケーション

www フォルダーをコピーして、Cordova アプリケーションの既存の www フォルダーと置き換えます。

注: クラシック・ハイブリッド・アプリケーションに環境固有の実装が含まれている場合は、それを Cordova の merge を使用することによってコピーできます。

マイグレーション・アシスト・ツールによって作成された Cordova アプリケーションを必ずしも使用する必要はありません。Cordova CLI を使用することで、新しい Cordova アプリケーションを自分で作成し、MobileFirst Cordova SDK を追加し、必要であれば任意のサード・パーティーの Cordova プラグインを追加できます。詳しく学ぶには、Cordova のチュートリアルに従ってください

ステップ 3

Cordova アプリケーションにアプリケーションのソース・コードが含まれています。次に、いくつかのコード・ブロックを追加または編集する必要があります。

  1. www/index.html ファイルを更新します。
    • 以下の CSS コードを、index.html ファイルの先頭、既にある CSS コードの前に追加します。
      <link rel="stylesheet" href="worklight/worklight.css">
      <link rel="stylesheet" href="css/main.css">
      注: worklight.css ファイルは、body 属性を relative に設定します。これがアプリケーションのスタイルに影響する場合は、ユーザー自身の CSS コードで position に別の値を宣言してください。 例えば、以下のようにします。
      body {
        position: absolute;
      }
    • Cordova JavaScript ファイルへの参照を、ファイルの先頭、CSS 定義の後に追加します。
      <script type="text/javascript" src="cordova.js"></script>
    • 以下のコード行がある場合は削除します。
      <script>window.$ = window.jQuery = WLJQ;</script>
      ユーザー独自のバージョンの JQuery をダウンロードし、これを、以下のコード行で示すようにロードすることができます。
      <script src="lib/jquery.min.js"></script>
      このオプションの jQuery 追加を lib フォルダーへ移動する必要はありません。この追加はどこでも必要な場所に移動できますが、その追加を index.html ファイル内で正しく参照している必要があります。
  2. WL.Client.init を自動的に呼び出すように、www/js/InitOptions.js ファイルを更新します。
    • InitOptions.js から以下のコードを削除します。 関数 WL.Client.init は自動的にグローバル変数 wlInitOptions を指定して呼び出されます。
      if (window.addEventListener) {
        window.addEventListener('load', function() { WL.Client.init(wlInitOptions); }, false);
      } else if (window.attachEvent) {
        window.attachEvent('onload',  function() { WL.Client.init(wlInitOptions); });
      }
  3. オプション: MobileFirst のフレームワークが初期化される前にロジックを実行する必要がある場合は、WL.Client.init を手動で呼び出すように www/InitOptions.js ファイルを更新します。
    • config.xml ファイルを編集し、mfp:clientCustomInit エレメントの enabled 属性を true に設定します。
    • ハイブリッド・デフォルト・テンプレートを使用している場合、以下のコードを置き換えます。
      if (window.addEventListener) {
        window.addEventListener('load', function() { WL.Client.init(wlInitOptions); }, false);
      } else if (window.attachEvent) {
        window.attachEvent('onload',  function() { WL.Client.init(wlInitOptions); });
      }
      上記を、以下のコードにします。
      if (document.addEventListener) {
        document.addEventListener('mfpready', function() { WL.Client.init(wlInitOptions); }, false);
      } else if (window.attachEvent) {
        document.attachEvent('mfpready',  function() { WL.Client.init(wlInitOptions); });
      }

ステップ 4

これで Cordova アプリケーションのマイグレーションはほぼ完了です。この時点で、生成された API レポートへの対処を行います。ブラウザー・ウィンドウで API レポートを開き、提示された項目を検討します。レポート内の各項目について、別の方法で実装するか、または完全に置き換える必要があります。新しい Cordova アプリケーションを指すようにして、マイグレーション・アシスト・ツールを再実行すれば、対処が済んでいない API がないか再確認できます。


ステップ 5

Cordova アプリケーションをテストするには、アプリケーションの Web リソースのみをプレビューするか、シミュレーター/エミュレーターで実行するか、または物理デバイスで実行することができます。
注: クライアント・サイド・コードにセキュリティーと認証、プッシュ通知、アダプター、および類似の機能に関連したロジックが含まれている場合、そのロジックのテストも行えるようにするためには、引き続きコードの調整が必要になることがあります (以下を参照)。ただし、アプリケーション・インターフェースを確認することで、機能が損なわれていないことを確認できます。

Web リソースのプレビュー:

  • コマンド・ライン・ウィンドウで、アプリケーションのルート・フォルダーに移動します。
  • 次のコマンドを実行します。mfpdev app preview
注: Mobile Foundation 8.0 の欠陥により、セキュリティーの側面を含んでいるアプリケーションのプレビューは失敗します。回避策として、エミュレーターまたは物理デバイスでアプリケーションをプレビューしてください。
アプリケーションの Web リソースのプレビューについてもっとよく知る。

エミュレーター/シミュレーターまたは物理デバイスでのテスト:

  • コマンド・ライン・ウィンドウで、アプリケーションのルート・フォルダーに移動します。
  • UI だけをテストする場合は、単純に次のコマンドでアプリケーションをビルドして実行できます。cordova run replace-with-platform-name
  • Mobile Foundation に関連したアプリケーション・ロジックもテストする場合は、プレビューの前にmfpdev app register を使用することで、まず最初にアプリケーションを登録してください。

次のステップ

Web アプリケーション

クラシック・ハイブリッド・アプリケーションと同様、モバイル Web およびデスクトップ・ブラウザー用の Web アプリケーションも、Eclipse 用の MobileFirst Studio プラグイン、または MobileFirst CLI から管理していました。 Mobile Foundation 8.0 では、Web アプリケーションの開発は従来の方式で行いますが、npm から入手できる MobileFirst Web SDK も使用できます。

注: 以前のリリースでは、MobileFirst Server が Web アプリケーションに関するサービスを提供し、公開 URL を提供していました。Mobile Foundation 8.0 では、セキュリティー機能やアダプターの各種機能などがアプリケーションに提供されるようにするため、アプリケーションは MobileFirst Server のみに登録され、専用 Web サーバーから Web アプリケーションを提供するなど、標準メソッドによって Web アプリケーションの提供が行われます。

Web アプリケーション開発についてもっとよく知る。

ステップ 1

マイグレーション・アシスト・ツールを使用して API レポートを生成します。
コマンド・ライン・ウィンドウを開き、次のような方法でマイグレーション・アシスト・ツールを使用します。
これは、インターネットの接続状況によって、完了までに時間がかかることがあります。

mfpmigrate scan --in path_to_source_directory --out path_to_destination_directory
  • source_directory は、Studio プロジェクトのアプリケーション・フォルダーに配置されている common フォルダーのパスに置き換えてください。例: ../Desktop/InvokingAdapterProcedures/apps/InvokingAdapterProcedures
  • destination_directory は、生成された API レポートの保存場所とするフォルダーのパスに置き換えてください。

マイグレーション・アシスト・ツールが正常に稼働すると、次のような作用を確認できます。

  • API レポート {app-name}-api-report.html が生成されます。このレポートには、Mobile Foundation 8.0 用にアプリケーションの実装を調整するために従うことが必要になる場合があるアクションが含まれています。

ステップ 2

API レポートを評価したら、この時点でアプリケーションの構造とソースをマイグレーションします。

  1. アプリケーションのソースとリソースを含める新規フォルダーを作成します。
  2. index.html ファイルと、jscss、および images の各フォルダーを、既存のプロジェクトから、作成したフォルダーにコピーします。
  3. コマンド・ライン・ウィンドウで、マイグレーションしたプロジェクトのルート・フォルダーに移動し、次のコマンドで MobileFirst Web SDK を追加します。npm install ibm-mfp-web-sdk
ステップ 3 に進む前に、Web アプリケーションへの Mobile Foundation SDK の追加チュートリアルの手順に従って、この SDK を構成します。

ステップ 3

これで Web アプリケーションのマイグレーションはほぼ完了です。生成された API レポートへの対処を行うのは、この時点です。ブラウザー・ウィンドウで API レポートを開き、提示された項目を検討します。レポート内の各項目について、別の方法で実装するか、または完全に置き換える必要があります。


ステップ 4

マイグレーションしたアプリケーションをテストするには、次のようにします。

  1. アプリケーションが MobileFirst Server に登録されていることを確認します。
  2. To avoid encountering 同一生成元エラーの発生を避けるため、リバース・プロキシーをセットアップします。この目的のためには、Node.js を使用できます。 Node.js を使用したリバース・プロキシーの実装例については、Web 開発環境のセットアップチュートリアルを参照してください。

ネイティブ・アプリケーション

ネイティブ・アプリケーションの場合、製品の以前のバージョンでは、プラットフォーム固有の成果物 (WorklightAPI フォルダー、構成ファイルなど) の初回作成時に Eclipse 用の MobileFirst Studio プラグイン、または MobileFirst CLI のいずれかが必要であり、その後、それらの成果物をそれぞれの IDE で手動でコピーし、ネイティブ・プロジェクトに貼り付けていました。

Mobile Foundation 8.0 からは、コミュニティーに支持されているパッケージ・マネージャー CocoaPods for iOSGradle for Android、およびNuGet for Windows のサポートが導入されています。これらのツールを開発者が利用できるようになったことで、MobileFirst ネイティブ SDK の追加が各プラットフォームで合理化されています。

ネイティブ・アプリケーション開発についてもっとよく知る。

ステップ 1

マイグレーション・アシスト・ツールを使用して API レポートを生成します。

注: 現在のところ、マイグレーション・アシスト・ツールでスキャンできるのは、MobileFirst Platform Foundation 7.1 ベースのネイティブ・アプリケーションのみです。

コマンド・ライン・ウィンドウを開き、次のような方法でマイグレーション・アシスト・ツールを使用します。

mfpmigrate scan --in path_to_source_directory --out path_to_destination_directory --type platform
  • source_directory は、ネイティブ・プロジェクトのパスに置き換えてください。例: ../Desktop/FormBasedAuthObjCiOS-release71
  • destination_directory は、レポートの生成場所となるパスに置き換えてください。
  • platform は、サポートされているプラットフォーム (iosandroid、または windows) に置き換えてください。
ネイティブ・アプリケーションの API レポートの生成

マイグレーション・アシスト・ツールが正常に実行されると、次のような作用を確認できます。

  • API レポート {app-name}-api-report.html が生成されていて、デフォルト・ブラウザーで開いています。このレポートには、Mobile Foundation 8.0 用にアプリケーションの実装を調整するために従うことが必要になる場合があるアクションが含まれています。
API レポート

ステップ 2

API レポート内にある問題を解決したら、古いネイティブ SDK を新しい ネイティブ SDK に置き換えることができます。

iOS
前提条件: 次のようにして、CocoaPods が Mac コンピューターにインストールされていることを確認します。
  • コマンド・ライン・ウィンドウを開き、Xcode プロジェクトのルートに移動します。
  • コマンド sudo gem install cocoapods に続けて pod setup を実行します。注: これらのコマンドは、完了するまで数分かかることがあります。

  1. Xcode でプロジェクトを開きます。
  2. Xcode プロジェクトから WorklightAPI フォルダーを削除します (ごみ箱へ移動します)。
  3. 以下の方法で、既存のコードを変更します。
    「Build Settings」 タブで、
    • ヘッダー検索パスから $(SRCROOT)/WorklightAPI/include を削除します。
    • $(PROJECTDIR)/WorklightAPI/frameworks をフレームワーク検索パスから削除します。
    • 静的ライブラリー libWorklightStaticLibProjectNative.a の参照をすべて削除します。
  4. 「Build Phases」 タブで、次のフレームワークおよびライブラリーへのリンクを削除します。CocoaPods がこれらのリンクを自動的に追加しなおします。
    • libWorklightStaticLibProjectNative.a
    • SystemConfiguration.framework
    • MobileCoreServices.framework
    • CoreData.framework
    • CoreLocation.framework
    • Security.framework
    • sqlcipher.framework
    • libstdc++.6.dylib
    • libz.dylib
  1. Xcode が閉じていることを確認します。
  2. 「端末」を開き、Xcode プロジェクトのルートに移動します。
    • pod init コマンドを実行して Podfile ファイルを作成します。
    • Podfile ファイルは、Xcode プロジェクトのルートに作成されます。このファイルを見つけて、好みのエディターで開きます。
    • 既存の内容をコメント化するか削除します。
    • 以下の行を追加し、変更を保存します。忘れずに target 値を更新してください。
      use_frameworks!
      platform :ios, 8.0
      target "replace-with-the-name-of-the-target-in-xcode-project" do
          pod 'IBMMobileFirstPlatformFoundation'
      end
      追加の pod:
      IBMMobileFirstPlatformFoundationPush
      IBMMobileFirstPlatformFoundationJSONStore

      アプリケーションで追加の機能を使用する必要がある場合は、ファイルに追加の pod を指定できます。例えば、アプリケーションで OpenSSL を使用する場合、Podfile は以下のようになります。
      use_frameworks!
      platform :ios, 8.0
      target "replace-with-the-name-of-the-target-in-xcode-project" do
          pod 'IBMMobileFirstPlatformFoundation'
          pod 'IBMMobileFirstPlatformFoundationOpenSSLUtils'
      end
    • pod install コマンドを実行します。このコマンドは、MobileFirst ネイティブ SDK、IBMMobileFirstPlatformFoundation.framework、および Podfile に指定されている他のすべてのフレームワークと、それぞれの依存関係をインストールします。その後、pod プロジェクトを生成し、クライアント・プロジェクトを MobileFirst SDK と統合します。
  3. コマンド・ラインから open ProjectName.xcworkspace と入力することによって、Xcode で ProjectName.xcworkspace ファイルを開きます。このファイルは、ProjectName.xcodeproj ファイルと同じディレクトリーにあります。Finder でダブルクリックすることもできます。
  4. ヘッダーの既存の MobileFirst import をすべて、次の新しいアンブレラ・ヘッダーの単一エントリーに置き換えます。
    Objective C:
    #import <IBMMobileFirstPlatformFoundation/IBMMobileFirstPlatformFoundation.h>

    Swift:
    import IBMMobileFirstPlatformFoundation
  5. 「Build Settings」タブの「Other Linker Flags」で、-ObjC フラグの始めに $(inherited) を追加します。
  6. プッシュ通知または JSONStore を使用している場合は、独立した import を組み込む必要があります。

    プッシュ通知
    Objective C の場合:
    #import <IBMMobileFirstPlatformFoundationPush/IBMMobileFirstPlatformFoundationPush.h>

    Swift の場合:
    import IBMMobileFirstPlatformFoundationPush

    JSONStore
    Objective C の場合:
    #import <IBMMobileFirstPlatformFoundationJSONStore/IBMMobileFirstPlatformFoundationJSONStore.h>

    Swift の場合:
    import IBMMobileFirstPlatformFoundationJSONStore

Android
プロジェクトの lib フォルダーを見つけ、次のファイルを削除します。
  • worklight-android.jar
  • uicandroid.jar
  • bcprov.jar
  • android-async-http.jar
  1. Android Studio で、「Android」→「Gradle Scripts」 に移動し、build.gradle (モジュール: app) ファイルを選択します。
  2. 以下の行を apply plugin: 'com.android.application' の下に追加します。
    repositories{
        jcenter()
    }
  3. 以下を android 内に追加します。
    packagingOptions {
        pickFirst 'META-INF/ASL2.0'
        pickFirst 'META-INF/LICENSE'
        pickFirst 'META-INF/NOTICE'
    }
  4. 以下の行を dependencies 内に追加します。
    compile group: 'com.ibm.mobile.foundation',
    name: 'ibmmobilefirstplatformfoundation',
    version: '8.0.+',
    ext: 'aar',
    transitive: true
    アプリケーションで追加の機能を使用する必要がある場合は、複数の成果物を指定できます。例えば、アプリケーションでプッシュ通知を使用する場合は、次の行を追加します。
    compile group: 'com.ibm.mobile.foundation',
    name: 'ibmmobilefirstplatformfoundationpush',
    version: '8.0.+',
    ext: 'aar',
    transitive: true
    または、JSONStore を使用する場合は、次の行を追加します。
    compile group: 'com.ibm.mobile.foundation',
    name: 'ibmmobilefirstplatformfoundationjsonstore',
    version: '8.0.+',
    ext: 'aar',
    transitive: true

Windows
Visual Studio プロジェクトから、次のファイルを削除します。
  • wlclient.properties
  • Newtonsoft.Json
  • SharpCompress
  • worklight-windows8
  1. プロジェクト・ソリューションを右クリックし、「NuGet パッケージの管理」を選択します。
  2. 検索オプションで、「IBM MobileFirst Platform」を検索し、「IBM.MobileFirstPlatform.8.0.0.0」を選択して、「インストール」をクリックします。
  3. Package.appxmanifest で、「インターネット (クライアント)」機能を追加します。

ステップ 3

これで Native アプリケーションのマイグレーションはほぼ完了です。この時点で、API レポートに生成された問題への対処を行います。ブラウザーで API レポートを開き、内容を検討します。レポート内の各項目について、別の方法で実装するか、または完全に置き換える必要があります。


ステップ 4

アプリケーションをテストするには、その特定のプラットフォームの IDE でアプリケーションを実行します。

次のステップ

補足資料:

これで、MobileFoundation 8.0 で要求される構造に準拠したアプリケーションになりました。アダプターの検討をはじめることができます。



アダプターのマイグレーション

以前のリリースでは、Eclipse 用の MobileFirst Studio プラグイン、または MobileFirst CLI を使用して、アダプターの作成、開発、およびビルドを行っていました。 Mobile Foundation 8.0 から、アダプターは、Java アダプターおよび JavaScript アダプターを生成するための IBM 提供のアーキタイプを使用して作成される、標準 Apache Maven プロジェクトと見なされるようになりました。

Maven プロジェクトを使用することで、サーバー・サイドの開発者にとっては、必要な依存関係を管理および統合するためのシンプルかつ標準の方法が提供されるとともに、開発時に好みのツールを使用できる自由が生まれます。Maven プロジェクトは、Maven コマンドを使用するか、または Maven コマンドを裏で呼び出して簡易コマンドを提供する MobileFirst CLI を使用することによって、コマンド・ラインから作成できます。

ヒント: Eclipse または IntelliJ をセットアップして、IDE 環境でアダプターを作成および開発することもできます

ご存じでしたか? Mobile Foundation 8.0 には DevOps スタイルの動作モードが導入されています。つまり、一度アダプターが MobileFirst Server にデプロイされると、アダプターを再デプロイしなくても、各種プロパティー (例えば、データベース接続用のユーザー名とパスワードの値) を、MobileFirst Operations Console を通じてライブで構成できるようになります。

Java アダプターおよび JavaScript アダプターの開発についてもっとよく知る。

アダプターを Maven プロジェクトにマイグレーションする場合は、適合する新規 Maven プロジェクトを作成する、作成した Maven プロジェクトに既存のアダプターのソース・コードをコピーする (一部変更を加える)、といった手順を踏みます。その後、Maven プロジェクトをビルドして、エラーがないか探します。

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」) 。
アダプター・テンプレートの作成
HTTP JavaScript アダプター
  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) に置き換えます。

SQL JavaScript アダプター
  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 の依存関係についてもっとよく知る:

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

古い JavaScript アダプターの構造
MyProject
├── adapters
│   ├── RSSAdapter
│   │   ├── RSSAdapter-impl.js
│   │   ├── RSSAdapter.xml
│   │   └── filtered.xsl
新しい JavaScript アダプターの構造
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 の依存関係についてもっとよく知る:

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

古い Java アダプターの構造
├── adapters
│   └── RSSAdapter
│       ├── RSSAdapter.xml
│       ├── lib
│       └── src
│           └── com
│               └── sample
│                   ├── RSSAdapterApplication.java
│                   └── RSSAdapterResource.java
新しい 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 とアダプターの使用についてもっとよく知る

IntelliJ の使用

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

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

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

アダプターが、Maven の形式とコードに準拠したプロジェクトにマイグレーションされましたので、ここで、開発概念について考察します。



開発トピック

アプリケーションとアダプターが Mobile Foundation 8.0 の新しい構造にマイグレーションされましたので、ここで、最新リリースで変更になった実装概念について考察します。

アダプター

JavaScript アダプター

グローバル変数とセッション

JavaScript アダプターでグローバル変数を使用してセッションに関するデータを保存することは避けてください。これは、「セッション」が存在しないためです。この動作変更が最初に導入されたのは MobileFirst Platform Foundation 7.1 においてです。ただし、グローバル変数を使用して、1 つの要求で使用するデータを保存することはできます。しかしながら、これはもう推奨される方法ではないことに、留意してください。

アダプター・チュートリアルで、アダプターの作成、ビルド、デプロイ、およびテストについてもっとよく知る。

セキュリティー・フレームワーク

Mobile Foundation 8.0 のセキュリティー・フレームワークは、以前のリリースのセキュリティー・フレームワークとは異なります。アプリケーションのバックエンドおよびクライアントのロジックの一部を再実装する必要があるのは、このためです。

OAuth モデルのみに基づいた、この新しいセキュリティー・フレームワークとその許可フローについて、時間を割いて理解を深めておくことは、非常に望ましいことです。また、アクセス・トークン、セキュリティー検査、セキュリティー・スコープといった新しい許可エンティティーについても学んでください。これらは、これまで知られていたセキュリティー・テスト、セキュリティー・レルム、セキュリティー・ログイン・モジュールなどのエンティティーに置き換わるものです。

認証およびセキュリティーのマイグレーションに関するチュートリアルで、セキュリティーのマイグレーション方法を学ぶ。セキュリティー・フレームワークおよび許可の概念について詳しくは、認証およびセキュリティーのチュートリアルを参照してください。

レルム対セキュリティー検査

Mobile Foundation 8.0 のセキュリティー検査は、次のように、以前のリリースに存在する 3 つの概念の組み合わせと考えることができます。
セキュリティー検査 = レルム + オーセンティケーター + ログイン・モジュール

セキュリティー検査の実装とは、ログイン・モジュールとオーセンティケーターの両方の実装です。
セキュリティー検査の定義は、レルムの定義と類似しています。

次の表に、以前のリリースのセキュリティー・フレームワークと、Mobile Foundation 8.0 のセキュリティー・フレームワークとの違いを示します。

以前のリリース Mobile Foundation 8.0
定義 authenticationConfig.xml 内で、名前、ログイン・モジュール、およびオーセンティケーターによって定義される。例:
<realm loginModule="AuthLoginModule" name="AuthRealm">
        <className>com.worklight.integration.auth.AdapterAuthenticator</className>
    </realm>
関連のある adapter.xml ファイル内で、名前および実装クラスを使用して、次のようにセキュリティー検査を定義する。
<securityCheckDefinition
        name="securityCheckX"
        class="com.sample.SecurityCheckW">
    </securityCheckDefinition>
メソッドの開始/終了 アダプター・ベースの認証: ログイン/ログアウト関数を定義し、これが許可要求時にフレームワークによって呼び出される。
<parameter name="login-function" value="AuthAdapter.onAuthRequired"/>
<parameter name="logout-function" value="AuthAdapter.onLogout"/>
カスタム・オーセンティケーター + ログイン・モジュール: 開始は init() メソッド、processRequest() で要求を許可。 オーセンティケーターは、ログイン・モジュールの資格情報を login()/logout() メソッドに送信する。
セキュリティー検査インターフェースを実装する場合は、ユーザーが authorize() メソッドと introspect() メソッドも実装する必要がある。これらのメソッドは、許可要求時にフレームワークによって呼び出される。セキュリティー検査は単独で認証とログイン/ログアウトを処理する。
使用方法 次のように、customSecurityTest にカプセル化。これには、1 個以上のレルムを含めることができる。
<customSecurityTest name="AuthSecurityTest">
    <test isInternalUserID="true" realm="AuthRealm"/>
</customSecurityTest>
Scope エレメントにカプセル化。これには、0 個以上のセキュリティー検査を含めることができる。

セキュリティー・テスト対スコープ

Mobile Foundation 8.0 では、スコープを使用して 0 個以上のセキュリティー検査を集約し、これを使用して、ローカルおよび外部のリソース、またはアプリケーションを保護することができます。これは、 以前のリリースの CustomSecurityTest の概念と類似しています。

以前のリリース Mobile Foundation 8.0
定義 名前、1 個以上のセキュリティー・テスト、UserID を定義するための少なくとも 1 つの専用のセキュリティー・テストを使用して、authenticationConfig.xml ファイル内で定義される。
<customSecurityTest name="AuthSecurityTest">
    <test isInternalUserID="true" realm="AuthRealm"/>
</customSecurityTest>
MobileFirst Operations Console で、または REST API を通じて、定義される。スコープには 0 個以上のセキュリティー検査が含まれる。
"scopeElementMapping": {
    "ScopeElementA": "secCheck1 secCheck2"
}, 
使用方法 SecurityTest を使用して、リソース (Java アダプター)、プロシージャー (JavaScript アダプター)、またはアプリケーション (アプリケーション記述子)を保護できる。

Java アダプター:
@OAuthSecurity(scope="AuthRealm")
JavaScript アダプター:
<procedure name="getSecretData" securityTest="AuthSecurityTest"/>
: securityTest に属していないレルムを使用してリソースを保護することはできません。
スコープ (1 個以上のスコープ・エレメント) を使用して、リソース (Java アダプター)、プロシージャー (JavaScript アダプター)、またはアプリケーション (アプリケーション記述子)を保護できる。

Java アダプター:
@OAuthSecurity(scope="ScopeElementA ScopeElementB")
JavaScript アダプター:
<procedure name="deleteUser" scope="deletePrivilege"/>
: scopeElement マッピングに属していない securityCheck を使用してリソース/アプリケーションを保護することはできます。
ユーザー ID セキュリティー・テスト内の特定のレルムが DeviceID と UserID を定義する。
<test isInternalUserID="true" realm="AuthRealm"/>
スコープは、そのスコープを構成するセキュリティー検査を認識しない。
デプロイメント authenticationConfig.xml ファイル内で構成される。securityTest を構成するレルムを変更するには、.war ファイルの再デプロイが必要。 MobileFirst Operations Console を使用することで、MobileFirst Server を中断することなく変更される。

通知

Mobile Foundation 8.0 には、新しいプッシュ・サービスが導入され、通知のセットアップ、構成、および送信の操作性も一新されています。加えて、イベント・ソース・ベースのプッシュ通知の概念は廃止されています。シナリオ・ベースのマイグレーションのための詳しい道程については、次のユーザー向け資料を参照してください。
通知チュートリアルで、通知サポートのセットアップと、認証済み通知およびタグ・ベース通知の送信について、もっとよく知る。

ダイレクト・アップデート

ダイレクト・アップデート・フィーチャーを使用した更新配信手順が変更になり、いくつかの制限が課されています。

Cordova アプリケーションでのダイレクト・アップデートの使用チュートリアルで、ダイレクト・アップデートの使用方法についてもっとよく知る。

その他

Mobile Foundation 8.0 では、ほかにもいくつかのコンポーネントおよびフィーチャーが削除されています。完全なリストについては、ユーザー向け資料トピック削除されたコンポーネントを参照してください。

説明の最後に、MobileFirst Platform Foundation 6.3 のハイブリッド・アプリケーションおよびアダプターの、標準 Cordova アプリケーションおよび Maven プロジェクトへのマイグレーションを示したビデオを以下に掲載します。

Last modified on May 31, 2017