Best Practices of Packaging

The following list provides some of the best practices or guidelines which you can adhere to while packaging.

• Before adding artifacts to the package, ensure all the artifacts that need to be added to a package are in the Published state.

• Identify the artifact which has the complete relationship for the project to be packaged.

  • If a navigation list item points to the main form (a form which is associated with all the other artifacts), go to the Navigation page and then add the navigation to the package.

  • If there are multiple main forms that do not have a relation among each other, add each of these forms individually to the package template. Ensure that the package template settings are same while adding each form to the package.

  • If the main form is not used in navigation, go to the Forms List page and then add the main form to the package.

  • If there is only a main workflow, then go to the Workflow List page and then add the workflow to the package.

• If you have created a project folder for forms, workflow, or any other lists, which are meant to be packaged together, then add the folder to the package for easier tracking.

• If a package is already shipped and installed, and if you add or modify some artifacts of the package, then you must create another version of the same package template and then add or modify the artifacts in the newly created version of the package template.

  Note: Custom files and scripts will not be identified as modified items.

• You can configure the common parameters for different artifacts in the Runtime Initialization Settings form before installing the package. For more information about runtime initialization settings, see Runtime Initialization Settings section in the Developer Guide.

• Ensure that the Runtime Initialization Settings form is a single form which does not have any association with other forms. It is recommended that you configure the artifacts (such as Forms, Workflow, Database Connection, and so on) as different tabs in the Runtime Initialization Settings form for easy configuration.

• Ensure that you install a package only during off-production.

• If you use a case-sensitive database to create a repository, you can create items with the same name in different cases. For example, a case-sensitive database considers DATABASE1 and database1 as two different items. In this case, the package will be imported as two different items. If the database is not case-sensitive, you cannot create an item with the same name.

  We recommend you not to create two different items with the same name in a case-sensitive database. If you package and import such items to a not case-sensitive database, the package gets imported as the next major version.

Recommendations

• The appropriate target platform is used while installing packages.

  For example: If the package is created in 64-Bit, it is recommended that you install the package in 64-Bit.

• The prerequisite packages are installed before installing the required package.

• The different versions of a specific package template should use the same Runtime Initialization form.

• If you face any issues or errors while adding artifacts to the package, it is recommended that you open the WTLogger Console so that you can view the error messages or warnings.

• Scenario 1: A package that has many artifacts is already shipped and installed. Of the many artifacts, you modify only few artifacts. However, you do not want to modify the existing package template. In this scenario, it is recommended that you package and ship only the modified artifacts in a new package.

• Scenario 2: A package that has many artifacts is already shipped and installed. If there are changes in physical files and/or script files in the package, then you must package and ship these artifacts in a new package template.

• Scenario 3: A package has a workflow with many activities. If there is any modification in the workflow definition, then it is recommended to use the “Complete Rebuild” feature to obtain the latest definition of all activities. For more information about complete rebuild, refer the Complete Rebuild section.

• While adding artifacts to a package template, if some of the artifacts are not added due to some exceptions, perform one of the following:

  • Verify the exception, correct it, and then add the artifacts to the package template.

  • Verify the exception, save the package, correct the exception, and then re-add the artifacts (which have exceptions) to the same package template.

    Note: You can validate the artifacts which have exceptions. You can also proceed with the installation of the existing artifacts by saving the package template.

Test Statistics

The following table represents the test statistics for the number of artifacts, which were packaged in a single package.

If there are many artifacts in a package, it is recommended to split this package into multiple small packages.