Importing apps from cloud to on-prem

Ajay Bhat - Feb 03, 2017 - Engineering

In this post, Sumit Sorde follows up on an earlier post explaining how to import an app from the Kony Cloud ( running the latest version of MobileFabric) to an On-Prem environment which may be an older version. This post updates and supersedes the information in the earlier post.

Introduction

MobileFabric (MF) allows applications to be exported and then imported back, possibly into a different instance or account. This mechanism allows movement of applications across MF instances and accounts.

With different releases of MF, as new features get added, the exported application package structure does get updated. This presents some challenges when moving MF applications across different versions of MF.

An application exported from an older release of MF can be imported seamlessly to a newer release of MF. So an app created on MF 6.5.2 can be exported and will import just fine on newer MF on-premise instances and MF cloud (which always has latest version).

The same though doesn’t hold true if the application is exported from a newer release of MF and is being imported to an older release of MF. So an app created on MF 7.0 cannot be imported to MF 6.5.2 without some manual tweaks.

Now why would you want to move from the latest version of Kony Cloud to an older version? Consider the case where your development/UAT environment is on the Kony Cloud at https://manage.kony.com (i.e. latest) while your production environment is on-premise, say 6.5.2. In such a setup you will need to import a MF 7.x app to a MF 6.5.2 instance.

This post will describe the MF app zip package structure for each major release of Kony MF since 6.5 and the updates made to it compared to previous release. We will focus primarily on services as their folder structure has been updated to support versioning and few other enhancements mentioned below.

6.5.2

Consider an app which has two integration services with name IntgService0 and IntgService1 and two orchestration services with names OrchService0 and OrchService1 linked to it. Following are some of the elements of the exported MF app zip for this app:

App meta file (stored as Apps\<app>\Meta.json)
{

            "description": "App1 Description",

            "integration": ["IntgService0", "IntgService1"],

            "orchestration": ["OrchService0", "OrchService1"]

}

This will suffice as there was no versioning support for services.

_Integration folder

This folder includes data about all integration services linked to app. It will have one subfolder per integration service as below:

Apps\_Integration\ IntgService0

Apps\_Integration\ IntgService1

Each subfolder includes data about the integration service e.g. endpoints, operations, Meta.json

_Orchestration folder

This folder includes data about all orchestration services linked to app. It will have one subfolder per orchestration service as below:

Apps\__Orchestration\ OrchService0

Apps\_Integration\ OrchService1

Also an orchestration service could only have one operation. Hence each folder will have one <operation.xml> and a Meta.json file

7.0.x

Key differences in MF app package 7.0.x vs 6.5.2

  1. Versioning – 7.0 supports service versioning while 6.5.2 doesn’t. In a 7.0 app package the individual integration and orchestration services would be organized under a version folder, which is not the case in a 6.5.2 package. Additionally the service references of a 7.0 app will contain the version information.
  2. JAR (for custom code) association – In 6.5.2, JARs are associated with individual operations of a service. In 7.0 though, the JARs are associated with a service.
  3. A 6.5.2 Orchestration service can have only one operation while a 7.0 one can have multiple operations.
  4. NOTE that if the app is using a new capability introduced in MF 7.0, we clearly cannot import that into MF 6.5.2.

Modifications required

Identity

No changes required

Integration

1. Remove versioning related changes

  • Remove the <version> folder from under the Apps\_Integration\<service> folder and move the ‘Endpoints’, ‘Operations’ and ‘Meta.json’ directly under the Apps\_Integration\<service> folder.
  • Modify the Apps\<app>\Meta.json and replace the ‘intSvcs’ key with ‘integration’ which will just be an array of service names.

7.0 v 6.5.2 Meta.json differences

2. Move the JARs from service level to operation level – Go through the JAR association in Meta.json of service and for each operation that’s referencing that JAR, add a ‘config-param’ with name ‘jarName’ and set the value to that JAR.

NOTE that there’s no clean way to capture JAR dependencies in 6.5.2.

7.0 v 6.5.2 Meta.json jar details differences

3. Rename the <operation>.xml to <service>.xml, where <service> is the name of the service – for e.g. TestOrchestration.xml. One additional change is required in the <service>.xml – change the value of ‘id’ attribute to <service>, i.e. name it the same as the name of the service.

Orchestration

1. Remove versioning related changes

  • Remove the <version> folder from under the Apps\_Orchestration\<service> folder and move the <operation>.xml and ‘Meta.json’ directly under the Apps\_Orchestration\<service> folder.
  • Modify the Apps\<app>\Meta.json and replace the ‘orchSvcs’ key with ‘orchestration’ which will just be an array of service names.

7.0 v 6.5.2 Orchestration Service Meta.json differences

2. Move the JARs from service level to operation level – Go through the JAR association in Meta.json of service and for each operation that’s referencing that JAR, add a ‘config-param’ with name ‘jarName’ and set the value to that JAR.

NOTE that there’s no clean way to capture JAR dependencies in 6.5.2.

7.0 v 6.5.2 Orchestration Service jar details differences

3. Rename the <operation>.xml to <service>.xml, where <service> is the name of the service – e.g. TestOrchestration.xml. One additional change is required in the <service>.xml – change the value of ‘id’ attribute to <service>, i.e. name it the same as the name of the service.

Synchronization

  • Remove the attribute ‘syncAppId’ from Apps\<app>\_Sync\Meta.json
  • Remove the attributes ‘dataSourceType’ & ‘AutoAttributeMapping’ from Apps\<app>\_Sync\<scope>\Meta.json

Engagement/Messaging

  • Remove the attributes ipadProdCertNameModified, ipadDevCertNameModified, iphoneDevCertNameModified, iphoneProdCertNameModified from Apps\<app>\_Messaging\Meta.json.
  • The cert files need to be renamed back after stripping off the platform and env info – they should match the name in the Meta.json. For e.g. rename Iphone_Prod_appleCertificateProd.p12 to appleCertificateProd.p12

Object services

 This feature was introduced in 7.0. So any object services part of 7.x.x app should be removed from the app zip before importing the app into MF 6.5.x. Also the corresponding service references need to be removed from app meta.

  • Delete Apps\_ObjectServices folder from app zip.
  • Modify the Apps\<app>\Meta.json and delete the ‘objectSvcs’ key.

Native clients/web app

No changes required.

7.1.x

No updates were made to the package structure in this release.

7.2.0.x

No updates were made to the package structure in this release.

7.2.1 and above

Key differences in MF app package 7.2.1 vs previous 7.x.x. releases

  1. Versioning of object services – 7.2.1 release introduced support for versioning of object services. In a 7.2.1 app package the individual object services would be organized under a version folder, which is not the case in a 7.0 package. Additionally the object service references of a 7.2.1 app will contain the version information. 
  2. An orchestration service operation can be dependent on object services which have version values other than 1.0. The version info will be captured as api-version value of config param which captures the dependency of orchestration service operation on an object service.
     

Modifications required

Object services


1. Remove versioning related changes

  • Move all existing entries in the <version> folder (e.g. 1.0) from under the Apps\_ObjectServices\<service_name> folder directly under the Apps\_ObjectServices\<service_name> folder and then remove the <version> folder.
  • Modify the Apps\<app>\Meta.json and replace the ‘objectSvcs’ key with ‘objectServices which will just be an array of service names. Sample Meta.json is shown below: 

7.2.5 v 7.2 and below: Object Services versioning changes

Orchestration

  1. Update api-version value for linked object services

For object services being imported in lower on-prem releases, the version value will always be 1.0. As a result, api-version value for any config-param which captures dependency of orchestration service operation on object services needs to be updated to 1.0.
e.g. Consider an orchestration service operation dependent on an object service named “Storage1” with version 2.0. The corresponding operation xml will have the config-param as below:

<config-param api-version="2.0" appid="Storage1" name="service" value="NewObjectV2/create"/>

This needs to be be updated as below:

<config-param api-version="1.0" appid="Storage1" name="service" value="NewObjectV2/create"/>