Nodejs OpenShift Do
improve this page | report issueNodejs-ODo-Komponente der Mobile Foundation
OpenShift Do (ODo) ist das CLI-Tool von Red Hat, mit dem Entwickler rasch Mikroservices erstellen und implementieren können. Mehr Informationen über ODo finden Sie hier.
Die Nodejs-ODo-Komponente der Mobile Foundation stellt eine Node.js-Umgebung bereit, mit der Entwickler Back-End- oder BFF-Mikroservices (Backend for Frontend) für mobile Apps erstellen können. Diese Komponente stellt benutzerfreundliche APIs bereit, mit deren Hilfe Entwickler von Mikroservices Mobile-Foundation-Services wie Push-Benachrichtigungen, Mobile Foundation Analytics und Liveaktualisierungen nutzen können. Vom Nodejs-Back-End kann beispielsweise eine Push-Benachrichtigung über den Kaufbetrag zu einer vom mobilen Client gesendeten Bestellung ausgelöst werden.
Voraussetzungen für die Verwendung der Komponente ODo
- Sie müssen die cc-CLI herunterladen und installieren.
- Sie müssen die odo-CLI [installieren]((https://odo.dev/docs/installing-odo/).
- Sie müssen Docker [installieren]((https://docs.docker.com/get-started/).
ODo-Projekt mit dem Docker-Image für Mobile Foundation Nodejs ODo erstellen
-
Verwenden Sie den folgenden Befehl, um das Docker-Image für die Komponente zu importieren.
oc import-image mobile --from=docker.io/ibmcom/nodejs-mobile-foundation:odo-latest --confirm
Hier können Sie anstelle von “mobile” einen Namen Ihrer Wahl verwenden.
-
Erstellen Sie einen neuen Ordner in Ihrem Dateisystem und initialisieren Sie ihn mit der odo-CLI. Beispiel:
mkdir mf-mobile-backend cd mf-mobile-backend odo create mobile --git https://github.com/{userName}/{repositoryName}
Dieser Befehl initialisiert ein Mobile-Foundation-Node.js-Projekt mit einer ODo-Konfigurationsdatei. Die GitHub-URL muss Ihre Node-App enthalten, die Mobile-Foundation-Services verwendet. Ein entsprechendes Beispiel finden Sie hier.
-
Navigieren Sie nach der Initialisierung Ihres Projekts zum erstellten Projektordner und fügen Sie am Ende der Datei
.odo/config.yaml
die erforderlichen Umgebungsvariablen wie unten angegeben hinzu.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>"}}'
Die einzelnen Parameter der Umgebungsvariablen sind nachfolgend erläutert.
-
MFSERVER
Der vollständig qualifizierte Mobile-Foundation-Serviceendpunkt. Beispiel: https://mf-xxxxx-mfpserver.mf.cluster.svc.local:9080 (Beachten Sie, dass die vollständige Serveradresse mit Port notwendig ist.) Wenn Ihr Mobile-Foundation-Service in einem externen Cluster ausgeführt wird, geben Sie die vollständig qualifizierte Ingress-Route an.
-
APPID
Bei Android-Anwendungen ist dies der Paketname der App und bei iOS-Anwendungen die Bundle-ID, z. B. com.acme.myapp.
-
UNAME
Der Benutzername des vertraulichen Clients, z. B. bffclient
-
PASSWORD
Das Kennwort des vertraulichen Clients, z. B. bffclientpassword
-
APPNAME
Der Anzeigename der Anwendung, z. B. Acme’s Awesome App
Alternativ können Sie wie folgt einzelne Umgebungsvariablen angeben, wenn alle Ihre Services auf einen Mobile Foundation Server und eine einzelne Anwendung zeigen:
-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>"
In dem obigen Fall muss die Umgebungsvariable die Ingress-Route Ihres Pods sein. Wenn Sie stattdessen die internen URLs verwenden möchten, sind zusätzliche Umgebungsvariablen erforderlich, die die interne Mobile-Foundation-URL der einzelnen Services (Push, Liveaktualisierung, Analytics) zusammen mit der obigen URL der Mobile-Foundation-Server-Laufzeit (mf_url) angeben.
-Name:mf_push_url Value:<MFPUSHSERVER> -Name:mf_liveupdate_url Value:<MFLIVEUPDATESERVER> -Name:mf_analytics_rl Value:<MFANALYTICSSERVER>
Hinweis: Wenn Sie die internen Mobile-Foundation-Service-URLs verwenden, müssen Sie nur einzelne Variablen angeben. Es ist dann nicht möglich, Umgebungsvariablen im Format einer Einzelvariable (
MF_ENVVARS
) zu übergeben. -
-
Verwenden Sie den folgenden Befehl, um eine öffentliche Route für die initialisierte App zu erstellen.
odo url create --port 8080
-
Die App kann jetzt mit dem folgenden Befehl implementiert werden:
odo push
Mit diesem Befehl wird die App implementiert, auf die nun über die oben erstellte Route zugegriffen werden kann.
Hinweis: Die Route für die App kann mit dem Befehl
odo url list
angezeigt werden.
Das für diese ODo-Komponente zu verwendende Docker-Image stellt direkt die folgenden APIs bereit:
Bereitgestellte Push-APIs
- sendNotification
- sendNotificationByTags
- sendNotificationByPlatform
- sendNotificationByDeviceId
- sendNotificationByUserId
Bereitgestellte APIs für Liveaktualisierung
- isFeatureEnabled
- toggleFeature
- enableFeature
- disableFeature
- getProperty
- setProperty
Bereitgestellte Analytics-APIs
- sendCustomLogs
- sendNetworkTransactions
Zusätzlich wird mithilfe der Passport-Strategie Benutzerkontext (benutzerspezifische Daten wie Benutzername, Gerätedetails etc.) für den Entwickler bereitgestellt. Mehr Informationen über die Passport-Strategie finden Sie hier.
Zu diesem Zweck kann ein Filter mf.securityUtils.mfpAuth(scope) zum erstellten Endpunkt hinzugefügt werden. Hier bestimmt der Parameterbereich, welche Benutzerkontextdaten abgerufen werden. Sehen Sie sich hierzu die Beispiel-App an.
Die Eingabe für den Passport-Filter wird über die Umgebungsvariablen mit dem Schlüssel passport_filter verfügbar gemacht.
▲Hinweis: Informationen zu den verfügbaren APIs finden Sie hier.
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.