Deployment Framework Structure

The files and directories of the Caplin Platform Deployment Framework are organised in a well-defined modular hierarchy:

Picture of Deployment Framework directory hierarchy

The root directory contains the following files and directories:

Directories

Name Description
active_blades The Framework uses this directory to manage which blades are active.
doc This directory contains documents about the Framework, and the associated release note.
global_config

This directory holds files and directories concerning configuration that is global to the Framework. To customise the configuration, only change files that are in the global_config directory and its subdirectories. All other configuration files in the Framework and in Caplin supplied blades are read-only and must not be edited.

environment.conf: Defines configuration macros that are server specific, such as the port numbers of the core components and the location of the Java Runtime Environment (JRE). The default settings are defined in the included file environment-defaults.conf.

hosts-defns.conf: Defines the servers that core components and any Adapter blades run on. You must update this file to reflect the deployment - you usually do this by running the Framework command ./dfw hosts
(Note that an Integration Adapter blade consists of an executable binary file in addition to its configuration and core component configuration, so you need to define which server(s) its executable will run on.)

fields.conf: A file that defines the names of global fields used in DataSource messages.

licenses: When components are deployed, any licenses required by these components must be placed in this directory. The Liberator license must be named license-rttpd.conf, and the Transformer license must be named license-transformer.conf.

ssl directory: Any SSL keys required by the system must be placed in this directory, including the public key file for Caplin KeyMaster.

overrides directory: This directory contains files that you can update to change configuration; for example, to make the Liberator log events at DEBUG level instead of INFO level. 

inactive_overrides directory (Deployment Framework version 6.2 and later): When you deactivate a blade, any configuration overrides that apply to it are moved from the overrides directory to the inactive-overrides directory. When you subsequently activate the blade again, its configuration overrides are moved from inactive-overrides back to overrides.

dump directory: The default directory where configuration information created by the ./dfw dump command is located.

kits

This directory initially contains the  Framework’s built-in Caplin Platform blades and some scripts: 

bootstrap.sh: Used on Windows to ensure that links in the kit are created correctly.

legacy_blades/Liberator and legacy_blades/Transformer directories 

(Deployment Framework version 6.2 and later): Holds the built-in blades that come with the Deployment Framework if a Liberator or Transformer kit is deployed that also has its own built-in versions of these blades. Liberator and Transformer versions 6.2.1, and later releases, are supplied with their own built-in blades. When you deploy one of these releases of Liberator or Transformer, the Deployment Framework detects their built-in blades and uses them instead of the Framework versions. The Framework versions of the blades are moved to the legacy_blades area. If you subsequently deploy an earlier release of Liberator or Transformer that doesn't come with built-in blades, the Deployment Framework restores its own versions of the blades from legacy-blades.

servers This directory holds configuration files containing server specific configuration for the core components.
tools This directory contains some Cygwin utilities that are used by the Framework scripts, and a utility script (information.sh) used by the built-in blades..

Files

Name Description
README.txt A short “getting started” guide.  See also, Getting Started: Installing the Deployment Framework on this web site.
dfw

A utility for managing the Framework and blades. You can perform any Framework operation by running the dfw utility with the appropriate command parameter.

  • To get a list of all the possible Framework commands, type: ./dfw help 
  • To run a Framework command, type: ./dfw <command>

Also see the list of dfw commands on this web site.