App Considerations

App Form Data

This section is applicable to you if you intend to migrate the form data stored in the server, otherwise, you can move on to the next section.

...

For example, in the screenshot below. The "Expenses Claim" app is making use of "j_expense" as the prefix in its forms' table naming.

Image RemovedImage Added

Figure 1: Form tables

Migrating app form data out would be quite straightforward since it resides in its own set of tables. Depending on the database systems that you are using, you can make use the appropriate tools/clients to export the data out. 
Image Removed
Image Added

Figure 2: Export App

...

1. How are we making use of the shared tables? As a lookup or we write into them too?
2. Can we continue to provide access from the original server?
3. At which layer should the access be created? Joget app server or DB server level?
4. If DB level, we can consider making use of JDBC related plugins(i.e. JDBC Database SQL Query Options Binder / JDBC Form Binder / JDBC Datalist Binder/ Database SQL Query/ Database SQL Query List Data Store).
5. If Joget app level, we can consider making use of JSON API or provision new ones using API Builder where we can exert more controls in API management.

...

Make a list of all external touch points that your app is using.

Image RemovedImage Added

Figure 3: Service Calls in App's Performance

...

Bear in mind that if you intend to upgrade your Joget platform, do it first at the environment where the staging server is, or upgrade the staging server where the said apps have been confirmed working before by following the Upgrade Guide For DX 8. This way, the only change made is to upgrade the Joget platform version. It would be easier to find out cause of any problems as there are not many variables changed.

...

1. Based on the list compiled in step 1, start new process instance in the new server using the same user with reference to the form record ID. Here's a sample of a process instance that is still running.
   Image RemovedImage Added
   Figure 4: Process Instance View
   
   In Figure 4 above, there are 3 vital information we need, and use them to call JSON API in the target server by using JSON API#web/json/workflow/process/start/(*:processDefId). We will also need to copy any workflow variable data over to the new instance too. We can pass on var_* parameters to set the workflow variables' values accordingly.
   
   At this point of time, the new process instance would be waiting at its very first activity.
   
   IMPORTANT NOTE: If you have tools that run right at the start of the process flow, this may cause manipulation of form data state. Take note of potential changes that may occur and devise a way to preserve original data/state.
2. Once a new process instance is started, note down the process instance ID generated, and we will then need to make use of JSON API#web/json/monitoring/activity/start/(*:processId)/(*:activityDefId) to resume the activity where it supposed to be, in the original server.
   Image Removed
   Image Added
   Figure 5: Process Instance View Highligting Open Activity Instances
   
   NOTE: Depending on how many pending activities that we may have in the specific process instance, we may need to make multiple calls to this JSON API. Take note that in the first of such call, we will need to set the "abortCurrent" parameter value to "true" so that it aborts the first default pending activity instance. Subsequently, set "abortCurrent" parameter to "false".
   
   IMPORTANT NOTE: The assignee of the resumed activity instance may not be correct if its participant mapping relies on performer of past activities. This is because past activities' data is NOT available in the target server.
3. In the target server, attempt to continue with the process assignment, as usual, through List Inbox Menu or Inbox Menu in your app, ideally, to the very end, to validate that it is working as expected.

...

1. Install this app in the current server. Publish the app.
2. Go to setup menu to key in parameters required of the target server.
   
   Figure 7: Utility App Setup Screen
   
   
3. At the target server, login as admin, navigate to System Settings > General Settings > API Domain / IP Whitelist and key in the domain / IP of the current / old server. This is so that the target server can accept JSON API calls from current server. We have set up the app.
4. Go to List of Running Process to see the list of running process instances. Select and click Migrate to start migration.
   IMPORTANT NOTE: If your app has User Notification Plugin or similar notification plugin enabled, or other process tool that will immediately run after process starts, it may be a good idea not to have them enabled while migration is taking place.
5. Observe current server log files and target server's Running Processes to verify its execution status / result.
   An entry will be added to Logs menu if it is successful.
   
   Figure 8: Utility App Logs
   
   In the List of Running Process menu, the status will change to "Migrated" with process instance ID furnished based on the data from logs.
   
   Figure 9: Utility App List of Running Process with New Process Instance Information
   

Download

App Version 1

Note: This migration utility app is tested on Joget v6 Enterprise 6.0.31 and Joget DX Enterprise 7.0.16 and with process migrated into a Joget server runing running on Joget DX 7.0.16.

App Version 2

Note: Added button to abort process instances. Tested on Joget DX 8.0.9.