Thursday, December 22, 2016

IBM MobileFirst Asymmetric deployment

Hi folk,

Today I'm going to post an overview of how to make a manual installation of IBM MobileFirston on WebSphere Application Server Network Deployment (WAS ND) using an asymmetric deployment.

Asymmetric deployment with runtimes and administration services in different server or cluster 

This topology is advantageous, because it enables the runtimes to be isolated from the administration components and from other runtimes.
 
It can be used to provide performance isolation, to isolate critical applications, and to enforce Service Level Agreement (SLA)







Characteristics of this topology
  • One or several administration components can be deployed in one or several servers or clusters of the cell. Each instance of MobileFirst Operations Console communicates with one administration service and one live update service
  • One or several runtimes can be deployed in other servers or clusters of the cell
  • One MobileFirst Operations Console manages several runtimes deployed in the other servers or clusters of the cell
  • One runtime is managed by only one MobileFirst Operations Console
  • Each administration service uses its own administration database schema
  • Each live update service uses its own live update database schema
  • Each runtime uses its own runtime database schema
Topology constraints
  • The deployment manager must be running while MobileFirst Server is running
  • The deployment manager is used for the JMX communication between the runtime and the administration service
  • The administration service and the live update service must be installed on the same application server
  • The runtime can be installed on different servers than the administration service, but it must be on the same cell
  • Start Order - The runtime application must start after the administration service application. You can set the order at Startup behavior section. For example, set the Startup Order to 1 for the administration service and 2 to the runtime
You can find the entire presentation in:

http://www.slideshare.net/JorgeIglesiasFernnde1/asymmetric-deployment-mfp

Cheers!!

Friday, December 16, 2016

Clone Cordova application using MobileFirst CLI

Hi folk,

Recently a customer asked me to help them creating a process of cloning configuration from mobile Cordova applications, from one version to another, using the IBM MobileFirst™ PlatformCommand Line Interface (CLI). The idea is to be able to automate the process in its continuous integration software development.

Currently the tool offers the cloning procedure from the operations console:





But MFP command-line does not have "clone" functionality today :/, who has said fear? :)

You can transfer an application configuration from a one server to another by using command-line tools or a REST API.

So, I have created a cloning functionality using nodejs-based program and mfpdev commands with the following business logic:

1) Pull the application descriptor JSON File:

Retrieves an existing app configuration from the server. The configuration includes the contents of the application descriptor, which uniquely identifies the app to the server and other information that is specific to the app. 
The configuration files are provided as compressed files (.zip format). 

2) Unzip artifacts zip file:

The .zip files are placed in the directory appName/mobilefirst and named as follows:
appID-platform-version-artifacts.zip

where:
appID is the application name,  
platform is one of android, ios, or windows
version is the version level of your app. 
For Cordova apps, a separate .zip file is created for each target platform.

3) Add version Application-Descriptor JSON File:

The application descriptor file is a JSON file that contains the description and configuration of your application. When you run an app that connects to a MobileFirst Server instance, the app must be registered with that server and configured.

4) Zip new artifacts zip file:
The .zip files are placed in the directory appName/mobilefirst and named as follows:
appID-platform-newversion-artifacts.zip

5) Modify the version in configuracion file (config.xml)

The Cordova configuration file is a mandatory XML file that contains application metadata, and is stored in the root directory of the app. The file is automatically generated when you create a Cordova application.

Information about this file in the Apache Cordova config.xml documentation.

6) Register application

Registers your app with a MobileFirst Server.

7) Push application

This command sends the .zip file to the MobileFirst Server. The client properties file myapp1/app/src/main/assets/mfpclient.properties is modified to reflect that the server that the app is registered.

Example - Clone version 1.0.1 to 2.0.0:

I have an app registered with the following versions:



In the app directory run following command:




$ node cloneApp.js local mfp jif.example.hellocordova android 1.0.1 2.0.0

When the process is finished, the new registered version must be displayed:



The source code can be downloaded from:
https://github.com/jorgeiglesiasfernandez/CloneApp
Note: Application authenticity and web resources will not be cloned. If you import an application that includes authenticity data, and if the application itself has been recompiled since the authenticity data was generated, you must refresh the authenticity data. For more information, see Configuring the application-authenticity security check.

Cheers!