You can export apps from one workspace (Kony account) and import them to different workspaces of the Kony Fabric Console. An exported or imported app has services configured into it.
A Kony Fabric app comprises a group of services. They are:
Kony Fabric Sync enables developers to add synchronization capabilities to mobile applications. Fundamental to Sync Framework is the ability to support offline and collaborative data between devices and the back-end systems.
Kony Fabric Messaging allows developers to upload push certificates for iOS, Android, BlackBerry, and Windows 8 RT platforms.
The integration service of an application represents the application interaction with the external data source.
Service orchestration coordinates or integrates several services and exposes them as a single service.
Important: Support for importing and exporting apps is available for identity services, such as Kony SAP, Kony Custom Identity, Salesforce, and Facebook.
You use exporting and importing apps based on the following scenarios:
Important: To merge configuration changes made to an existing app to a source control system (for example, Git), you must export an updated app with the same details as the earlier version of the app in the source control system.
Important: You must republish the app for the new settings to take effect.
To back up and restore (rollback) Kony Fabric apps. You can do backup of a Kony Fabric app package, and then you can restore the app to a previously defined state. You can restore a complete app or the services part of the app. For example, you can restore a complete app package to recover from an error.
When an app is exported from a workspace, the exported app is saved with the same name of the app - for example, ExportApp.zip
. An exported .zip file has an app's configured services information, such as icon files, certificates, .XML files, and meta files.
Note: You cannot import an exported app after you modify the structure in the exported app. Support for importing an edited zip (exported app) file is not available. If you try to import an edited ZIP file, the system may fail to import the app successfully.
An exported zip file should have the correct folder structure. An exported zip file should have correct references in meta files. For more details about the folder structure of an exported app, refer to the Folder Structure of an Exported App section.
Important: Before exporting an app, do not unlink identity services that are referenced in the integration services of the app.
If you unlink a referenced identity service in the Identity tab and try to export an app, the system fails to export that app.
Important: Before exporting an app, do not unlink integration services that are referenced in the orchestration services of the app. If you unlink a referenced integration service and try to export an app, the system fails to export that app.
To export an app from a workspace (Kony account), follow these steps:
The system saves the app as <AppName>.zip
in your browser's default download location.
Important: You must republish the app for the new settings to take effect.
Note: You can also export an App via API. For more details, refer to Continuous Integration - Export an app via API
With importing an app as a new app, you can create new apps quickly by reusing configurations from existing apps. You save time because this method reduces the number of steps needed to re-create an app. After you import an app as a new app, you can modify configurations in the app as required.
After an app is exported, you can import it as a new app or overwrite an existing app across various Kony Fabric Consoles. When you import an app as a new app, the system imports the app into the console. The imported app includes all data from the original app and the name of the app. The imported app is listed in the Applications page.
To import an app as a new app, follow these steps:
The Import App dialog appears.
Important: You must republish the app for the new settings to take effect.
Important:
While overwriting an app, if the app names are same, the new data will override the existing data.
Based on various services configured in an existing app, the system overwrites the existing data from a zip file. For example:
Note: You can also import an app via API. For more details, refer to Continuous Integration - Import an app via API
You can update an existing app's configurations with the latest configurations made in another app in a different workspace. You can reuse the updated configurations from other apps to save time and development cost.
After an app is exported, you can import the app to an existing app in the Kony Fabric Console.
While importing an app to an existing app, if the app names are same, the system overrides the existing data with new data in the imported zip file. The app name will not be changed.
If the app names are different and you import an app, the existing app and data will be overwritten with the new app name and information in the zip file.
To import an app to an existing app, follow these steps:
ExportApp.zip
file), and select it. Click Open.Note: You can also import an app via API. For more details, refer to Continuous Integration - Import an app via API
The folder structure of an exported an app (a zip file) has folders, files, and certificates configured for that app. Do not make any changes to the folder structure outside Kony Fabric Console. If you make changes to the folder structure of an app, the system may throw an error while importing that app. The following section explains the hierarchical directory tree of an exported app:
//Folder structure of an exported app /Apps /App1 Meta.json Icon file /_Messaging Meta.json AppleCert1.p12 AppleCert2.p12 AppleCert3.p12 AppleCert4.p12 /_Sync Meta.json /SyncScope1 Meta.json Syncobject1.xml Syncobject2.xml … /App2 … /_Identity /Identity1 Meta.json Metadata1.xml … /_Integration /Service1 /Endpoints Endpoint1.xml /Operations Operation1.xml Operation2.xml … WSDLFile /_Orchestration /Orch1 Operation1.xml Operation2.xml … /_JARs Jar1.jar Jar1.meta …
The logical flow of an exported app folder structure has four levels of folders. The primary, or root, level is the Apps folder, which contains all sublevel folders including files and metadata. The following table explains hierarchical levels of an exported app folder structure:
Root | Second Level | Third Level | Fourth Level |
---|---|---|---|
Apps | |||
/App1
|
|||
/_Messaging
|
|||
/_Sync
|
|||
/SyncScope1
|
|||
/_Identity |
|
||
/Identity1
|
|||
/_Integration | |||
/Service1 | |||
/Endpoints
|
|||
/Operations
|
|||
WSDLFile | |||
/_Orchestration | |||
/Orch1
|
|||
|
/_JARs
|
The root level (for example, App1) section has details of the apps meta file, icon file, messaging (meta file and certificates), and sync (meta file and objects). While exporting an app, an <appname>.zip file is saved with the root app name. You can rename an exported zip file, if required.
//Sample data in apps (root) section of an exported app folder structure /App1 Meta.json Icon file /_Messaging Meta.json AppleCert1.p12 AppleCert2.p12 /_Sync Meta.json /SyncScope1 Meta.json Syncobject1.xml Syncobject2.xml …
The apps meta (meta.jason) file has configuration (shared and non-shared) details of an app, such as icon file, identity services, integration services, and orchestration services, shown below:
//Sample data in the app meta file of an exported app folder structure
{
"Icon": "Iconfile",
"description": "description",
"Identity": [--> referencing identity providers
"Identity1","Identity2"
],
"Integration": [
"Service1","Service2", referencing integration services
],
"Orchestration": [
"Orch1","Orch2", referencing orchestration services
],
}
The icon file is an image file for an app.
The messaging section has referenced (non-shared) messaging services configured for an app, such as meta file and certificates configured for messaging services.
//Sample data in the messaging section of an exported app folder structure /_Messaging Meta.json AppleCert1.p12 AppleCert2.p12 AppleCert3.p12 AppleCert4.p12
The messaging meta file contains information about configurations, such as ID, password, certificates, and push URL for messaging services for different platforms (Android, iPad, iPhone, BlackBerry, Windows 7, and Windows 8).
Important: The configuration details, ID, password and push URL are not encrypted in the meta file.
//Sample data in the messaging meta file of an exported app folder structure { "appleProdmode" : true/false, "iphonecertprod" : { "certName" : "AppleCert1.p12", "passwd" : "<password>", }, "iphonecertdev" : { "certName" : "AppleCert2.p12", "passwd" : "<password>", }, "ipadcertprod" : { "certName" : "AppleCert3.p12", "passwd" : "<password>", }, "ipadcertdev" : { "certName" : "AppleCert4.p12", "passwd" : "<password>", }, "Android": { "Key": "<GCM Key>", }, "Blackberry": { "id": "", "passwd": "", "pushurl": "", }, "Windows": { "id": "", "passwd": "", "windows7": true/false, "windows8": true/false, }, }
The synchronization section has the referenced (non-shared) SyncScopes configured for an app. A syncobject.xml
file includes Sync objects of an app, such as attributes, target and source relationships, client-side filters, and life-cycle methods.
The following is the folder structure of a synchronization service:
//Sample data in the synchronization section of an exported app folder structure /_Sync Meta.json /SyncScope1 --> SyncScope1 is the name of the SyncScope Meta.json Syncobject1.xml Syncobject2.xml …
The SyncConfig meta file has information about database types.
Note: MobileFabric 6.0.2 supports only MySQL database.
//Sample data in the SyncConfig meta file of an exported app folder structure { "PersistentDBType": "MYSQL/Oracle/MYSQL Server", }
The SyncScope meta file has information about SyncScope configuration parameters specific to Sync (such as ChangeTrackingPolicy, ConflictPolicy, namespace, and strategy). The SyncScope meta file refers to an integration service and Sync interceptor jar.
The following is the meta file structure of a SyncScope service:
//Sample data in the SyncScope meta file of an exported app folder structure [ "SyncScope1": { --> Sync scope name "Strategy": "", "NameSpace": "", "ChangeTrackingPolicyType": "", "SoftDeleteFlag": "", "LastUpdateTimeStamp": "", "ConflictPolicyType": "", "DataSource": "Service1", --> Referencing integration service "SyncJar": "Jar1", --> referencing Sync interceptor jar "className": "sample", --> Class name used in case of custom Sync }, … ]
The identity section has the referenced (shared) identity services configured for an app.
The following is the folder structure of an identity service:
//Sample data in the identity section of an exported app folder structure /Identity /Identity1 --> Identity1 is the name of the identity service Meta.json Metadata1.xml --> This metadata is required for identity providers that have metadata, such as, SAML. .
The identity meta.json
file has the configuration, type and metadata file information of the identity service. The identity metadata is required only for SAML identity services.
The following is the meta file structure of an identity service:
//Sample data in the identity meta file of an exported app folder structure { "name": <name of the identity provider>, "displayName": <display name of the identity provider>, "version": <version>, "loginText": <login text of the identity provider>, "metaPreference": <meta preference >, "type": <type of identity provider>, "config": {}, --> configuration details of the identity provider }
The integration section has the referenced (shared) integration services configured for an app, such as endpoints details of a particular service type, operations details of a particular service type, and additional attributes/elements for design time data.
The following is the folder structure of an integration service:
//Sample data in the integration section of an exported app folder structure
/_Integration
/Service1 --> Service1 is the name of the integration service
/Endpoints --> only one endpoint per service is allowed Endpoint1.xml
/Operations
Operation1.xml
Operation2.xml
…
WSDLFile
This section contains the Web Services Description Language (WSDL) file used by the soap integration service.
The endpoints file has configured endpoints including the integration type, address, and credentials.
The following is the endpoint file structure of an integration service:
//Sample data in the endpoints file of an exported app folder structure <?xml version="1.0" encoding="UTF-8"?> <endpoint name="default" type="[type]" encryptSecureInfo="false"> <config> <entry> <key>config1</key> <value>value1</value> </entry> … </config> </endpoint>
This file contains XMLs of operations configured for an integration service.
This section contains the WSDL file used by the SOAP integration service.
This section contains only one operation.xml
file. The orchestration section has the referenced (shared) orchestration services configured for an app.
The following is the folder structure of an orchestration service:
//Sample data in the orchestration section of an exported app folder structure /_Orchestration /Orch1 --> Orch1 is the name of the orchestration service Operation1.xml --> looping or concurrent operation
An operation file of an orchestration service has looping or composite operation configured for an orchestration service.
This section has the referenced (shared) custom code JAR files configured for an app.
The following is the folder structure of custom code JARs:
//Sample data in the custom code JARs section of an exported app folder structure /_JARs Jar1.jar --> The JAR file Jar1.meta.json --> Meta for the JAR file contains information about dependent jars. Jar2.jar Jar2.meta.json …
This file contains metadata of the JAR file.
The following is the structure of a JAR meta file:
//Sample data in the JAR meta file of an exported app folder structure { "dependent_jars": [ --> JARs files that depend on other JAR files. "jar1.jar","jar2.jar" ] }
Copyright © 2020 Kony, Inc. All rights reserved. |