Metadata, application data and authorisation data

USoft Delivery Manager distinguishes between metadata, application data and authorization data.

Type of data	Description
Metadata	Data that describes your USoft application. You create this data by using USoft development tools such as Definer, Web Designer, and Service Definer.
Application data	Data that your USoft application allows users to enter or view or manipulate.
Authorization data	Data that describes allowed access of users to application data.

Metadata is deliverable by definition. It must be released to target machines if the application is to run successfully on those machines. Delivery Manager releases metadata either as an XML export named "USD.xml" or as conventional USoft flatfiles (named "MYAPP.con" etc. if your application is called MYAPP). You can also choose to have the same metadata released in both formats in parallel.

Application data and authorization data are deliverable if that data is determined by the development team in the Development environment as part of the software being delivered. This contrasts with non-deliverable application data and authorization data, which are created and manipulated by end users in Production.

In practice, only a small set of 'technical tables' in your application will be deliverable ( ie., they are tables that contain deliverable application data). In addition, an important part but not all of your authorization data will also be deliverable. USoft Delivery Manager releases deliverable application data as an XML export file named "<application>.xml" and deliverable authorization data as an XML export file named "USAUTH.xml".

A Development environment normally also contains non-deliverable application data and authorization data, because this enables developers to quickly test their work before they deliver it to a test environment.

Delivery Manager releases XML exports named "USD.xml" in the metadata section and conventional USoft flatfiles (named "MYAPP.con" etc. if your application is called MYAPP) in the flatfiles section. Deliverable application data and authorization data are released to the appdata section.

If you instruct Delivery Manager to release .xml data files, and comparable data from a previous release are found, then Delivery Manager will automatically produce a diff file with name "...diff.xml" (with the "diff" infix at the end of the filename and before the file extension). Each diff file is the outcome of a comparison between the metadata of the current release and the metadata of the previous release. Both the regular XML exports and the diff files are re-importable. The regular .XML files contain static datasets. The diff files list differences detected as INSERT and UPDATE operations (ie, new and changed records) as static data, and differences detected as DELETE operations (ie., dropped records) as data with the transition instruction <Delete/>.

If the release is initial, ie., the first release in the release tree that is known to Delivery Manager for the application, then Delivery Manager will release a dummy XML file named "... initial.xml" that denotes an empty repository. This causes the diff file to report the comparison with the next state as an INSERT (introduction) of all the records present in that state.

Type of data	Section	Filename
Metadata	metadata	USD.xml USD.diff.xml (USD.initial.xml)
Metadata	flatfiles	MYAPP.con MYAPP.job MYAPP.smg MYAPP.umg MYAPP.esi
Application data	appdata	MYAPP.xml MYAPP.diff.xml (MYAPP.initial.xml)
Authorization data	appdata	USAUTH.xml USAUTH.diff.xml (USAUTH.initial.xml)

Metadata

Metadata released as conventional USoft flat files (MYAPP.con, etc.) is intended for target environments that are to run from flat file. These flatfiles can be deployed on a target machine by replacing the old flatfiles (if they exist) by the delivered flatfiles.

Metadata released as an XML export file (called "USD.xml") is intended for target environments that are to run from repository. This data must be deployed by being re-imported into the target repository. While "USD.xml" files produced by Delivery Manager are re-importable in principle, this may raise problems if the target repository already has metadata from a previous release, unless it is possible and acceptable to clear the target repository as a preparatory step. Alternatively, the target repository may be upgraded by importing the "USD.diff.xml" file into it, rather than the "USD.xml" file.

Deliverable application data

Deliverable application data is often referred to informally as "technical tables". An example is technical configuration options that end users must choose from when configuring some artefact. There are many different practical reasons why a development team chooses to introduce deliverable application data.

The difference with non-deliverable application data is that end users in Production do not create this data, although they may be given the possibility to view it and select from it in application screens.

In practice, all production applications built with USoft have a small number of tables that contain deliverable application data. Deliverable application data tends to reside in a clearly delineated subset of application tables, in the sense that each given application table is likely to contain in all its columns EITHER deliverable application data that is created in the Development environment and delivered from there, OR regular application data populated by end users in Production (both not both at the same time). For this reason, Delivery Manager presents a list of application tables in which you can indicate which tables are deliverable by checking or unchecking a check box for each table. By default, a table is not deliverable. To deliver the contents of an application table, you have to check the box.

If it is really necessary to deliver application data that is stored only in specific columns or specific records (or both) in an otherwise non-deliverable table, you can deliver this using Delivery Manager but this will require more manual scripting.

Deliverable authorisation data

USoft Authorizer takes the form of a configurable layer that runs from repository in each environment. The implication is that, in theory, administrators on a given Production machine can decide, independently of the development team and of the moment when the application is released to that target machine, not just who (which individuals) is allowed to access the application and in what role and for how long, but also which roles (usergroups) there exist in the first place, and what data and other functionality each role has or not does have access to.

However, in practice, this kind of authorization is so closely linked to application logic determined by the development team, that in production applications most USoft Authorizer data are actually deliverable data: they are determined by the development team in Development, delivered by Delivery Manager, and not supposed to be manipulated by end users or by administrators on Production machines. The only exception in practice is that administrators determine WHO (which individuals) is allowed to access the application on a given Production machine, IN WHAT CAPACITY (of which usergroup each of these individuals is a member), and DURING WHICH TIMEFRAME.

In summary, while deliverable application data is usually a very small part of application data, by contrast the greater part of authorization data created in USoft Authorizer is usually delivered. Delivery Manager presents a list of authorization tables in which you can indicate which tables are deliverable by checking or unchecking a check box for each table. By default, Delivery Manager presents as checked all the boxes for the authorization tables that are usually delivered from Development.