An application is a software solution built (wholly or in part) with USoft tools, or a tool delivered by USoft to help you build such a solution. An application integrates the three levels of data storage, business rules automation, and one or more interfaces for communicating with humans or other systems or both.
The concept of application in Delivery Manager is the same as in other USoft tools. For example, it matches:
•Applications listed in USoft Authorizer. •Applications as defined and used in USoft Binder, USoft Web Designer, USoft Service Definer, and USoft Windows Designer. In addition, in Delivery Manager, if you use modular development, consumed module names are also considered applications.
In the same way as in USoft Authorizer, applications in Delivery Manager include not only applications and modules that you build yourself, but also applications shipped by USoft:
Name
|
Title
|
USAUTH
|
USoft Authorizer
|
UDELIVER
|
USoft Delivery Manager
|
USD
|
USoft Definer
|
USERVICE
|
USoft Service Definer
|
USTESTER
|
USoft BenchMark
|
To define or view applications in Delivery Manager, choose Define, Applications from the menu.
An application defined in Delivery Manager has the following properties.
The name of the application as it is also known in USoft Authorizer, USoft Binder and other USoft tools.
|
"Top-level", "Module", or "USoft":
•"USoft" applications are applications shipped by USoft. •Among the applications that you build yourself, in Delivery Manager, you must designate exactly 1 as the "Top-level" application. •The remaining applications are "Modules". Each module is either consumed directly by the top-level application, or indirectly because it is consumed by one of the modules, or both. Delivery Manager only keeps a flat list of modules: it does not register which applications consume which modules.
|
The version of the application
•that is currently being developed (top-level application), or •that is planned to be consumed by this version of the top-level application (modules), or •that was last shipped by USoft (USoft applications). The version of the top-level application is set automatically by Delivery Manager to the name of the current release. The versions of modules you can optionally register yourself. Ideally, this information should coincide with the current Repository Version in the module's development repository.
Version information about the top-level application and modules is copied automatically to the packing slip when you call release actions, if the current release has "Include packing slip" = Yes.
The "Version" property of USoft applications is not registered. It is automatically set to NULL (the empty value).
|
The version of the USoft tools that the top-level application or a module is being developed with, or that consumed modules were developed with. In tasks, you can have Delivery Manager retrieve this information by calling the Extract USoft version action.
Version information about the top-level application and modules is copied automatically to the packing slip when you call release actions, if the current release has "Include packing slip" = Yes.
The "USoft version" property of USoft applications is not registered. It is automatically set to NULL (the empty value).
|
The status of a consumed module in the current release, as compared with the previous release.
•This property is automatically set to "Changed" when the Version property of the module changes. •This property is automatically set to "Unchanged" when the top-level application version changes, that is, when you create a new release. This property plays a role in the effect of the "Module delivery policy" property (next). Both properties apply only to applications of application type "Module".
|
The policy that you want to use for delivering flatfiles of a module:
•If you set this property to "Generate new flatfiles" (the default), when you call an action that creates flatfiles for the module, Delivery Manager will log on on the database account where the module is developed and generate fresh flatfiles. •If you set this property to "Copy previous flatfiles", when you call an action that creates flatfiles for the module, Delivery Manager will look for module flatfiles in the previous release directory. If such files are found, and "Module version status" = Unchanged for the module, the files are copied to the destination folder of the action. Otherwise, new flatfiles are generated as if "Generate new flatfiles" was set. This mechanism is relevant if it must be possible, or if it cannot be excluded, that changes to the module are made during preparation of your release, but you want to control manually whether or not these changes are taken on board in your current release. This could apply when the module changes very infrequently, or when it is maintained by a different team or in a remote location.
This property applies only to applications of application type "Module".
|
The development environment(s) that you consider as the source for authorisation data that must be released to target machines.
This property must be configured in exactly one of 2 modes, "central" or "distributed":
|
Source for authorisation
"Central" mode
|
Source for authorisation
"Distributed" mode
|
Top-level application
|
Yes
|
Partly
|
Module(s)
|
No
|
Yes
|
USoft applications
|
(Not applicable)
|
(Not applicable)
|
•This property is automatically set to "Yes" for the top-level application if there are no modules for which this property is set to "Yes." •This property is automatically set to "Partly" for the top-level application if there is at least 1 module for which this property is set to "Yes". •When you introduce a module, you are prompted to set "Source for authorisation". By default, set it to "No" unless you have special reasons to set it to "Yes". Use a central source for authorisation data unless you have special reasons to do otherwise. With a central source for authorisation, during release, you ignore authorisation data that are set in development repositories for modules. Instead, you first synchronise the top-level application with the module flatfiles, then run "Fill authorizer Tables" in USoft Authorizer for the top-level application, and then define all deliverable authorisation data in the development repository of the top-level application.
This property is for information only. It has no automatic effect on how Delivery Manager exports authorisation data.
|
The database account against which you want to check the correctness of SQL statements in pre-upgrade scripts.
If you have a way of working where the previous state of the application (the state of the previous release) is still available in a repository, you want to have pre-upgrade scripts checked against this state. In this case, this property should be set to the database account where this repository resides.
This is a required property. It is relevant only when you check upgrade scripts with Processing Order = Pre-upgrade. Until such time, you can set it to the same database account as "Source for post-upgrade check", namely, the location where the application is being developed.
|
The database account against which you want to check the correctness of SQL statements in pre-upgrade scripts.
This property is relevant only when you check upgrade scripts with Processing Order = Post-upgrade.
This is a required property. Set it to the database account where the application is being developed.
|
An optional field for notes about the application.
|
|