Page History

...

Updating Application Version

These are the instances when process version will change. 

• Creation of new version from existing app version.
  
  The current app version selected will be cloned (process, form, datalist, userview and properties including default plugin properties, message bundles, and environment variables ) over to the next available version number.

• Import of App
  

Important Notes

• There can only be one published version at any point of time.
• End users will only be able to access the published version and consume what is available (accessing process, form, datalist, userview etc) in that version with the exception of process instance's form access. (Read more under process version below).
• When switching published version, please take note of possible impacts to the end users by assessing the differences between the current published version and the soon to be published one. For example, if you are using an environment variable as incremental counter, you may want to make sure that the new counter will start from where the old one left at.

Process Version

Inside an app version, it contains process design but process design has its own set of versioning called process version.

...

In this case, app version 1 will now hold process version 3 and not 2.

Finding App Version of the Process Version

In the Monitor Apps section, one can navigate to the process instance view and click on the Process Name link to lead to the designer console of the app version. From the screenshot below, this particular instance is of process version 6 and it belongs to app version 3.

Image Added

Important Notes

1. One will always start a new process instance using the latest process version of the current published version.

2. By updating the process design in the same app version:, all existing running process instances in the same app version will automatically be updated to the new process flow in the background.
   Do not perform this unless it is absolutely necessary in a production server.

   Warning
   title Do not repetitively update process design in a short time
   Process migration will takes place once process design is changed. Repetitive process change deployment will disrupt existing process instances migration in the background.

   By updating the process design in the same app version: all existing running process instances in the same app version will automatically be updated to the new process flow in the background. Do not perform this unless it is absolutely necessary in a production server

   You will be seeing the following sample log messages when migration takes place. Code Block title Log INFO 28 Apr 2017 10:41:52 org.joget.apps.app.service.AppServiceImpl$1 - Updating running processes for hr_expense from 4 to 5 INFO 28 Apr 2017 10:41:54 org.joget.apps.app.service.AppServiceImpl$1 - Completed updating running processes for hr_expense from 4 to 5

   Info
   title Process Migration
   The following will take place during migration of process instances:- 1. Abort pending process instances. 2. New process instances will be created. (A new process instance ID will be created in which you can find the linkage in the database table wf_process_link) 3. Resume by matching previous pending activities IDs with the new Process version’s design.

   
   After you update the process design, do remember to check all the activity/plugin mappings to make sure that they are current and in sync with your process design. 

...

Process instance that contains activity mapping(s) make use of the forms created under the same app version. Regardless of the current published app version, the process instance's assignment will show form mapped to it, of the same app version the process instance falls under.

For example, in the table and screenshot below, 123_hr_expense_process1 will show forms mapped according to its activity mapping mappings under app version 1 regardless of whether app version 1 or 2 is published or not.

...

By accessing the form record created by a process instance of different app version, you may not be seeing the exact form used during the process instance flow process. As such, you can clone the form from the originating app version into the current app version that you are working on so that you can then gain access to the very form used during the process flow.

For example, in the screenshot below, we are seeing a form with 3 fields in a process instance assignment. Remember that the form that is being used for this process instance originates from the app version the process instance started in.

Image Added

For the same record row, when viewed in a CRUD userview menu, there's an extra field given that in the current published version, a field has been added to the form.

Image Added

In order to resolve the possible confusion and displaying the correct form intended for the record row, the following actions can be taken:-

1. Copy the form from earlier app version into current published app version.
2. Identify the app/process version each record originates from by adding a hidden field in the form by using the appropriate hash variable (e.g. #assignment.processVersion#).
3. Create a CRUD userview menu for each specific app/process version with version filter in place for each app/process version.

import org.joget.apps.app.model.AppDefinition;
String appVersion = appDef.getVersion().toString();