Introduction
This document describes how we import a new Dynamic Version into an exiting application. This may be from a Sandbox into a Live Org or from one Sandbox to another (e.g. dev Sandbox to UAT Sandbox). Note that these instructions are based on Change Sets and hence are not applicable to Developer Edition Orgs.
Versions: Since package 1.0.20
In this article:
Step 1 – Deploy Change Set
Step 2 – Run in Dynamic Version
Step 3 – Resolving Failures
Context
Developers create applications on the MobileCaddy platform and these are deployed into production. When a change is made to an existing application, MobileCaddy allows different versions of the applications to run on the same Salesforce organisation at the same time with different mobile devices being targeted for each version. These instructions show how we pull in a new Dynamic Version to run alongside an existing one, and how we target different users to run (test) the new version.
Step 1 – Deploy Change Set
The Administrator / Developer of the Dynamic Version in the Source Salesforce Organisation will have created a change set containing the following. This guide assumes that this is now residing in the destination org as an Inbound Change Set. Here is an example:
Required
:The following items must be in the incoming change set.
- The Mobile Application Export Document and Digest. In this example these are the top 2 entries.
- The Mobile App Start Page, Cache Page and Recovery VisualForce pages. In this example these are pages ExtSeedApp_001, ExtSeedAppCache_001 and MCRecovery.
- The Mobile Application Bundle Version (Static Resource). In this example this is the ExtSeedApp_001 static resource.
- Cordova Resource (Static Resource). Here this is cordovaSF3v1 static resource.
- MockCordova Resource (Static Resource). Here this is MockCordova3v1.
Optional
:Whether or not these items are present depends on the details of your application. If you are unsure then double check with the Developer/Administrator who exported the application.
- Any Objects / Fields / Record Types etc that are required by your application
- Any Classes / Triggers / Tests required by your application
- Platform Class Restriction Classes & Test Classes (Apex Classes used where any of your Mobile Tables have been specified to use ‘Platform Restriction Class’)
-
Install the Change Set
- Run the change set into your org using the ‘Default’ Test Option. Ensure that it deploys successfully – you should receive Deployment Details similar to the following:
Any issues / problems will need to be reviewed in conjunction with the Administrator/Developer who exported the app from the source organisation.
- Run the change set into your org using the ‘Default’ Test Option. Ensure that it deploys successfully – you should receive Deployment Details similar to the following:
Step 2 – Run in Dynamic Version
- In the destination organisation, go to your Mobile Application record and click the ‘Import DV’ button. You will be presented with a list of Documents to import. Select the document that came over in your change set. Do not select the ‘_dig’ “digest” file. In the following example, we select the first file.
- Once you have selected the file, click ‘Start New Import”. You will be returned to the Mobile Application page because the import processing takes place in a separate process. This is because it can be time consuming. You will notice that another Dynamic Version has appeared under your Mobile Application.
- Click the ‘Import DV’ button again. You will be presented with a screen similar to the following.
It is important that the status is as shown, showing that the initial validation has passed. If the process has not completed yet, you may returned to this screen later to check again. If you have an error in the ‘Import DV Status’ field, then you will need to resolve it (See Resolving Failures). A typical error here occurs when an attempt is made to import a Dynamic Version from a different application to the one we are installing it in. Provided you have this success message, click the initial selection checkbox and click ‘Progress DV’ (as indicated in the diagram above).
- You will be returned to the Mobile Application again. Click ‘Import DV’ to check the status.
- Repeat the process of validation / returning to this page. You will eventually come to ‘5 Simulate Import Passed’.
- At this point, all validation has been successful and the DV will now be fully imported. Select the checkbox and click ‘Progress DV’ again. View the list of Dynamic Versions against your application.
- If you click ‘Import DV’ again, the DV will not be there because the import is now complete. You may navigate into your DV to view its contents. At this point you may push the DV status up to ‘Developing’ or beyond (using the Edit(Description/Status) button on the DV page layout. The DV is now available to be assigned to users an a DV upgrade or to set as your org’s preferred DV for initial app installs.
Step 3 – Resolving Failures
- If you encounter a validation failure on clicking ‘Import DV’ such as the following.
Note that the Import Message tells us that ‘a comparison report is attached to the DV’. Look at the ‘Notes & Attachments’ related list (note you may need to add this to your page layout).
- We have 2 files. The file of interest here is ‘compareResults.txt’. Click the ‘View’ link to view the contents of this file. Search for all entries marked ‘fail’. e.g.
12345678910{"sObjectAPIName" : "mobilecaddy1__Mobile_Application__c","rule" : "fail","inheritedForeignKey" : "%%IFK%Mobile_Application__c%CFK-000001%a2UR00000000q8VMAQ%00D9E000000D0nuUAC%2017-04-21 14:52:28%","fileValue" : "Demo App","fieldName" : "mobilecaddy1__Build_Package_Name__c","dbValue" : "BIZ001"},
This is telling us that the database (ie existing Salesforce) value for the field ‘Build Package Name’ is ‘BIZ001’ yet in the imported file it is ‘Demo App’. This is not permitted and therefore the user has been stopped pulling in this DV.