1. Development Workbench - Source Upgrade
  2. Refresh Functionality in Development Workbench

3 Refresh Functionality in Development Workbench

This topic provides an overview of Refresh functionality in Oracle FLEXCUBE Development Workbench.

Refresh Functionality allows us to upgrade the existing RADXML to its later version keeping the sub-version-specific changes intact. Three kinds of Refresh can be done using the Tool:
  1. Child Refresh
  2. Screen Child Refresh
  3. Source Refresh

Child Refresh

Child Refresh allows the developer to upgrade a child RADXML with its latest parent RADXML. The latest changes done in parent function id would be reflected in the child function id while retaining all the changes done in the child level.
  • This process is to be done within a release. i.e. child function id has to be refreshed it’s the parent function id from the same release.
  • It is recommended that this process is done before the development cut of the release for all child RADXMLs within a release. For instance; if development has happened parallel for a child and parent function id during a release, child refresh should be done before baselining so that child and parent record types are consistent.
  • All the system units need to be regenerated after Child Refresh. A thorough unit testing is recommended after the deployment of all generated units.

Screen Child Refresh

Screen Child Refresh allows the developer to upgrade a screen child RADXML with its latest parent RADXML. The latest changes done in parent function id would be reflected in the screen child function id while retaining all the changes done in the screen child level.
  • This process is to be done within a release. i.e. screen child function id has to be refreshed with its parent function id from the same release.
  • If the parent function id of the screen child is a child screen, then it is recommended that the child refresh of that screen be carried out before doing screen child refresh.
  • It is recommended that this process is done before the development cut of the release for all child RADXMLs within a release. For instance; if development has happened parallel for a screen child and its parent function id during a release, screen child refresh should be done before baselining so that screen child and parent record types are consistent.
  • All the system units need to be regenerated after Screen Child Refresh. A thorough unit testing is recommended after the deployment of all generated units. Note that only frontend units will be generated for a screen child function id.

Source Refresh

Source Refresh allows the customer to upgrade its existing release with the latest release of FLEXCUBE without affecting its custom changes. By using the Source Refresh option all the extensible RADXML‘s of older versions can be updated with the latest version changes.
  • Source Refresh is possible only for the extensible screens. Hence for non-extensible screens customization on the screens can’t be retained in case of an upgrade.
  • Source Refresh is done for RADXMLs in different releases.
  • All system units need to be regenerated after source refresh. A thorough unit testing is recommended after the deployment of all generated units.
  • Child Refresh and Screen Child Refresh will be done implicitly during Source Refresh if any child/screen child screens are present. Hence if source refresh of any child/screen child has to be done, include parent RADXMLs also in the source and base file lists.
  • Select proper release types for source and base while upgrading in Refresh Page.
It is meaningless to do Source Refresh between two Kernel versions (or two cluster versions etc) as we can replace the entire source with the latest version in such a scenario. Hence Source and Base Release types can never be the same for Source Refresh.
Source release type can not be Kernel, it can be either Cluster or Custom. Base Release type options will depend on the source release type selected.
  • If the user selects Custom as source release type, the user has the option to upgrade release based on either cluster pack or Kernel.
  • If the user selects Cluster as source release type, the user has only one option as base release type i.e. Kernel.