Delivering modules

You can deliver any such structure of application modules with Delivery Manager. However, Delivery Manager does not register each individual relationship between a consumer and a module. It is able to register only a single top-level application and (optionally) a non-hierarchical list of any number of modules.

Because of this, there are 2 limitations:

•You can deliver only a single top-level application. You cannot deliver 2 different, unrelated applications from one and the same instance of Delivery Manager.

•You cannot deliver subparts of a module tree hierarchy. You can deliver individual modules. You can deliver the entire structure (ie., the top-level application and all the modules), But you cannot deliver a module M1 together with only those modules that M1 consumes directly or indirectly, except if you are ready to register M1 itself as the top-level application, in which case Delivery Manager will ignore the fact that M1 has consumers of its own.

USoft modular development is all about combining (merging) metadata developed in different instances of USoft Definer, a process known in the USoft Definer tool as synchronisation.

However, when it comes to delivering modules, you must also consider the possibility of deliverable application data ('appdata') and authorisation data ('authdata') stored in those metadata structures. In your project, you need to make decisions about how you want to organise the delivery of appdata and authdata if you have modules in addition to your top-level application.

A typical approach is first to assemble everything in the consumer module, and then 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 metadata that 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:

Functionally, the "central appdata, central authdata" scenario requires that you perform the following typical steps when releasing for Production environments that run from flat files:

Synchronisation

Central authdata

Central appdata

Release

For this section, bear in mind that successful generation of a top-level create-tables script requires:

•In Delivery Manager itself, an up-to-date populated tables list for each of the modules.

•In the release folders, an up-to-date metadata XML file for each of the modules.

Here is a typical Delivery Manager task design for delivering modules. It implements all functional steps of the previous section that can be automated.

TIP: As a jump start, you can get this default task design generated by Delivery Manager. Use the Tools, Quick Start feature .

This example has just 1 module. It is called M1. If you have more modules, they follow the same patterns. The top-level application is called TA.

In this task design, the assumption is that you have already declared the applications in Delivery Manager (menu, Define, Applications) as follows:

This task design hinges on the idea that you require at least a 3-phase approach:

•In the first phase, there are some Delivery Manager steps you want to automate. They are steps of a task you could call the Prepare task.

•In the second phase, there are manual edits you want to do in Definer and Delivery Manager. They are the reason why you typically have a separation between Prepare task and Release task.

•In the last phase, you want to automate the release of all the deliverables. This is executed by the steps of a task you could call the Release task.

The example task design, then, is for 2 tasks: Prepare and Release. The tables below do not spell out all the implementation details. They show only a brief description. For each step, they show only the Delivery Manager action and the application that this action is applied to. Steps applied to the USAUTH application are understood to refer to the database account where the top-level application is developed.

Prepare task

Release task

* With the option "Include physical tables upgrade script" = Yes.

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 having deliverable appdata in a module table that is not an interface table. And if this is really necessary, then you should avoid marking one and the same table as "deliverable" at both the top-level application and the module level, unless you have special reasons to do otherwise.

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 authorisation Tables. This makes it easy to consider the authorizer of the top-level application as your central repository for authorisation rules.