Delivering modules

If you use USoft modular development, you can have an application in a Development environment consume any number of modules developed elsewhere. A consumed module may, in turn, have other consumed modules of its own, so that in theory you can create a hierarchical tree of consumed modules that is any level deep.

Delivery Manager only registers a simple structure with a single top-level consumer application and a list of consumed modules that is at most 1 level deep. However, it allows you to create sequences of calls to actions such as Synchronise and Create flatfiles in such a way that you can, in fact, deliver module structures that are any level deep.

Each module is defined in its own Development environment and, prior to release, is made available to the Development environment of the top-level application in the form of a conventional USoft flat file named "module.con".

DL_clip0012

Each time a module flatfile is delivered, a routine must run that "synchronises" the top-level application with the module. Synchronisation operates at the level of metadata only.

Delivering module appdata and authdata

In addition to metadata, each of the modules will have its own application data ('appdata') and authorisation data ('authdata'). These data are not affected by the synchronisation operation. In your project, you need to make decisions on how you want to organise the delivery of appdata and authdata if you have modules in addition to your top-level application.

A typical scenario is to assemble everything in the consumer module, and deliver appdata and authdata from there. This scenario you could call "central appdata and central authdata". In this scenario, the Development environments for the modules are used only to produce flatfiles which are the input for synchronisation. After synchronisation, appdata and authdata are delivered centrally, that is, from the top-level application. The picture below is an informal depiction of the "central appdata and central authdata" scenario:

DL_clip0013

This "central appdata, central authdata" scenario has the following steps if you are releasing for Production environments that run from flat files:

1.	Generate a .CON file for each module, and place it in in \APP subfolder of the USoft installation directory in preparation for Step 2.

2.	Synchronise the top-level application with all its modules.

3.	In Authorizer of the top-level application, (re-)run Fill Authorizer Tables. Create or change deliverable authorisation data as appropriate.

4.	In the top-level application, create or change deliverable application data as appropriate.

5.	Release a full set of flat files for each of the modules and also for the top-level application.

6.	Release the top-level application's deliverable application data in the form of a file named "<top-level application>.XML".

7.	Release the top-level application's deliverable authorisation data in the form of a file named "USAUTH.XML".

Decentralised (modularised) appdata

The "central appdata, central authdata" scenario is the easiest scenario to manage, but there are times when you must consider delivering application data ('appdata') from a module instead of from the top-level application.

You must deliver appdata from a module if that module has 1 or more deliverable application tables that are not interface tables. Such tables are not "visible" in the top-level application. Running Delivery Manager's "Populate tables list" routine will not list these tables as Application Tables in Delivery Manager for the top-level application.

For clarity and traceability, you should generally avoid marking one and the same table as "deliverable" for both the top-level application and the module, unless you have special reasons to do otherwise. One such reason might be that you also deliver the module as a stand-alone application.

Decentralised (modularised) authdata

Best practice is to deliver authorisation data ('authdata') from the top-level application at all times. It is very unlikely that you have a good reason to deliver authdata from a specific module. Running the Fill Authorizer Tables routine, either in the Authorizer of the top-level application or by calling Delivery Manager's "Fill Authorizer tables" action, will cause all (interface and non-interface) tables from modules to be listed as Authorization Tables. This makes it easy to consider the Authorizer of the top-level application as your central repository for authorisation rules.