Nodejs OpenShift Do

improve this page | report issue

Composant Node.js odo de Mobile Foundation

OpenShift Do (odo) est l’outil d’interface de ligne de commande pour développeurs élaboré par Red Hat pour créer et déployer rapidement des micoservices. Vous trouverez plus d’informations sur les composants odo ici.

Le composant Node.js odo de Mobile Foundation fournit aux développeurs un environnement Node.js afin de générer des microservices de back-end ou BFF (Backend-For-Frontend) pour des applications mobiles. Ce composant offre aux développeurs de microservice des API faciles à utiliser pour exploiter des services Mobile Foundation tels que Push Notifications, Mobile Foundation Analytics et Live Update. Par exemple, une notification push peut être déclenchée à partir du système de back-end Nodejs en fonction de la valeur d’achat du client pour une commande passée depuis le client mobile.

Prérequis à l’utilisation du composant odo

  • Téléchargement et installation de l’interface de ligne de commande oc.
  • [Installation]((https://odo.dev/docs/installing-odo/) de l’interface de ligne de commande odo.
  • [Installation]((https://docs.docker.com/get-started/) de Docker.

Création d’un projet odo avec l’image Docker d’odo Nodejs de Mobile Foundation

  1. Importez l’image Docker du composant à l’aide de la commande suivante :

     oc import-image mobile --from=docker.io/ibmcom/nodejs-mobile-foundation:odo-latest --confirm
    

    A la place de “mobile”, vous pouvez choisir ici le nom qui vous convient.

  2. Créez un dossier dans votre système de fichiers et initialisez-le à l’aide de l’interface de ligne de commande odo. Par exemple,

     mkdir mf-mobile-backend
     cd mf-mobile-backend
     odo create mobile --git https://github.com/{userName}/{repositoryName}
    

    Cette opération initialise un projet Node.js Mobile Foundation avec le fichier de configuration odo. Ici, l’URL GitHub doit contenir votre application Node qui utilise des services Mobile Foundation. Vous trouverez un exemple ici.

  3. Une fois votre projet initialisé, accédez au dossier de projet créé et ajoutez les variables d’environnement requises à la fin du fichier .odo/config.yaml comme illustré ci-dessous.

     Envs:
       - Name: MF_ENVVARS
         Value: '{"push":{"mf_url":"<MFSERVER>","mf_app_id":"<APPID>","username":"<UNAME>","password":"<PWD>"},"liveupdate":{"mf_url":"<MFSERVER>","mf_app_id":"<APPID>","username":"<UNAME>","password":"<PWD>"},"analytics":{"mf_url":"<MFSERVER>","mf_app_name":"<APPNAME>","username":"<UNAME>","password":"<PWD>"},"passport_filter":{"mf_url":"<MFSERVER>","username":"<UNAME>","password":"<PWD>"}}'
    

    Chaque paramètre de la variable d’environnement est expliqué ci-dessous.

    • MFSERVER

      Noeud final complet du service Mobile Foundation. Par exemple, https://mf-xxxxx-mfpserver.mf.cluster.svc.local:9080 (Notez que l’adresse complète du serveur y compris le port est nécessaire). Si votre service Mobile Foundation s’exécute dans un cluster externe, fournissez le chemin d’entrée qualifié complet.

    • APPID

      Pour les applications Android, il s’agit du nom de package de l’application et pour les applications iOS, de l’ID de bundle. Par exemple, com.acme.myapp.

    • UNAME

      Nom d’utilisateur du client confidentiel. Par exemple, bffclient.

    • PASSWORD

      Mot de passe du client confidentiel. Par exemple, bffclientpassword.

    • APPNAME

      Nom d’affichage de l’application. Par exemple, Acme’s Awesome App.

    Vous pouvez également fournir des variables d’environnement individuelles lorsque tous vos services pointent vers un serveur unique serveur Mobile Foundation et une seule application, comme ci-dessous.

     -Name:mf_url
     Value:<MFSERVER>
     -Name:mf_app_id
     Value:<APPID>
     -Name:push_mf_username
     Value:<PUSH_UNAME>
     -Name:push_mf_password
     Value:<PUSH_PWD>
     -Name:liveupdate_mf_username
     Value:<LIVEUPDATE_UNAME>
     -Name:liveupdate_mf_password
     Value:<LIVEUPDATE_PWD>
     -Name:analytics_mf_username
     Value:<ANALYICS_UNAME>
     -Name:analytics_mf_password
     Value:<ANALYTICS_PWD>
     -Name:pf_mf_username
     Value:<PASSPORT_FILTER_UNAME>
     -Name:pf_mf_password
     Value:<PASSPORT_FILTER_PWD>"
    

    Dans le cas ci-dessus, la variable d’environnement doit être le chemin d’entrée de votre pod. Si vous préférez utiliser les URL internes, des variables d’environnement supplémentaires sont nécessaires pour spécifier l’URL Mobile Foundation interne de chaque service (push, liveupdate et analytics) avec l’URL mf_url de l’environnement d’exécution du serveur Mobile Foundation.

     -Name:mf_push_url
     Value:<MFPUSHSERVER>
     -Name:mf_liveupdate_url
     Value:<MFLIVEUPDATESERVER>
     -Name:mf_analytics_rl
     Value:<MFANALYTICSSERVER>
    

    Remarque : Si vous utilisez des URL de service Mobile Foundation internes, vous devez spécifier uniquement des variables individuelles. Vous ne pouvez pas utiliser le format de variable d’environnement unique MF_ENVVARS de transmission des variables d’environnement.

  4. Utilisez cette commande pour créer une route publique pour l’application initialisée.

     odo url create --port 8080
    
  5. Maintenant, l’application peut être déployée à l’aide de la commande suivante :

    odo push
    

    Cette commande déploie l’application qui est désormais accessible via la route créée ci-dessus.

    Remarque : vous pouvez afficher la route de l’application à l’aide de la commande odo url list.

L’image Docker à utiliser pour ce composant odo fournit directement les API ci-dessous.

API Push fournies

  • sendNotification
  • sendNotificationByTags
  • sendNotificationByPlatform
  • sendNotificationByDeviceId
  • sendNotificationByUserId

API Live Update fournies

  • isFeatureEnabled
  • toggleFeature
  • enableFeature
  • disableFeature
  • getProperty
  • setProperty

API Analytics fournies

  • sendCustomLogs
  • sendNetworkTransactions

En outre, le contexte de l’utilisateur (données propres à l’utilisateur telles que le nom d’utilisateur, les détails de l’appareil, etc.) est mis à la disposition du développeur final avec l’aide de la stratégie Passport. Pour plus d’informations sur la stratégie Passport, voir ici.

Vous pouvez l’utiliser en ajoutant un filtre mf.securityUtils.mfpAuth(scope) dans le noeud final créé. Ici, la portée de paramètre détermine les données de contexte utilisateur extraites. Un exemple est fourni dans le modèle d’application.

L’entrée pour le filtre Passeport est disponible via les variables d’environnement en utilisant la clé passport_filter lors de la spécification des variables d’environnement.

Remarque : pour plus d’informations sur les API disponibles, voir ici.

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on July 09, 2020