Page History

...

1. App Form Data
2. Shared App Form Data
3. App Process Data
4. Plugins
5. Integration with External Systems
6. User Management

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.

As part of application building best practises, your app table name should have is own prefix.

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

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 Added

Figure 1: Form tables2: Export App

When exporting app, we can export its dependant plugins as well as form data too. By default, only the app design is exported out.

However, it is important to note that although there's ability to export form data in Export App feature, the intent of this feature is to export/import setup data, not production data. If the resultant export package size file size is too big, importing it later on will result in error / request time out issues.

Shared 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.

Referring to Figure 1 above, 

App Process Data

Plugins

, we can make use of the form builder > Advanced Tools > Table > Table Usage In Other Apps to check if tables are being shared with other apps.

If there are shared form data tables, then we will need to assess how we can separate the data or continue to access the shared data upon separation. There are few things to consider based on the assumption that the data is vital to the app that we are migrating out:-

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 Options Binder / JDBC Form Binder / JDBC Datalist Binder).
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.

App Process Data

This section is applicable to you if your app is making use of processes (Process Builder), otherwise, you can move on to the next section.

Due to the complexity and structure of the data, as of now, we do not recommend migrating process data out in parts.

This is because data of process instances are stored in set of tables shared by all other apps in the same Joget server. Process data contains not just instances from the latest version of the app that we are migrating out, it may also contain all the process instance data of the same app but from earlier versions.

We would recommend to leave the process instances' data behind. For process instances that are still in transit, here's the approach that we recommend.

1. Migrate the form data to the new server.
2. Compile a list of process instances that are still running. It should also contain the pending activity and latest set of workflow variable data.
3. Start a new process instance with reference to the form record ID and set of workflow variable data, and resumes at the last pending activity.

This way, end users should be able to seamlessly continue with their process flow.

Plugins

This section is applicable to you if your app is making use plugins, otherwise, you can move on to the next section.

Referring to Figure 1 above, plugins that are used by the app can be exported alongside with the app itself. You should check if the new / target server has the same plugins but of different versions and check for its compatibilty.

Integration with External Systems

This section is applicable to you if your app is making external calls / relying on external systems, otherwise, you can move on to the next section.

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

Image Added

Figure 3: Service Calls in App's Performance

The server calls in app's performance tab is a good place to refresh your memory as it will be able to help to list down calls being made outside of the Joget server over a period of time.

For each of them, do check for permission in the external systems to see if you need to whitelist / permit your new server in order to continue to function normally. If the new server is located in environment that is significantly different with current server (i.e geographically far away), it would be good to test its network / throughput to ensure that the app in the new server would be able to function within expected response times and not get bogged down by slow external integrations.

User Management

Typically, we will continue to server the same set of users in the new server as we scale out.

If you are making use of an identity management system (i.e. LDAP), then it should be relatively easy to simply point to the same server.

Otherwise, you may need to duplicate the existing user directory date (tables with prefix of dir_ in the database) to the new server.

...