Exercise 10.1 – The Working Directory

EIP-ROOT

1. 1. The working directory is frequently called eip-root, which is the default name assigned to that directory by the eiConsole.
   2. This directory is the root location where all PilotFish configuration files are stored.
   3. While the convention is to call it eip-root, it is not required to name it that. Note: PilotFish tutorials generally use eip-root and working directory interchangeably.
   4. The eip-root contains global configuration files, debugging and trace files, metadata produced by specific PilotFish modules, etc.
   5. The eip-root is also considered to be the root Interface package.

Interface Hierarchy

1. 1. PilotFish Interfaces function as a hierarchy.
   2. Every interface has a parent interface, going all the way up to the root interface, the eip-root.
   3. Every interface has the same basic internal directory structure.
   4. Interfaces act as a sort of scope around many of its contents.
   5. Because the eip-root is considered to be a root interface, any sub-interface of it can also be treated as if it were its own eip-root. The PilotFish application can be run with a starting working directory of any valid interface package.

Interface Directory Structure

1. 1. data
      1. The data directory is an optional directory in the interface.
      2. It is a default location where the user can store information related to the interface being worked on.
      3. Sample files and documentation are just some examples of what can be stored there.
   2. formats
      1. The Formats directory is where all transformation Formats are stored.
      2. Because all formats are stored at the interface level, they are all scoped to the interface they are within.
      3. The formats directory contains a series of child directories, each named for its particular Format. Each one of those directories contain the configuration files for the transformations that format performs.
   3. lib
      1. The lib directory is where any additional libraries for the interface are stored.
      2. PilotFish uses a local-first classloading system, so libraries placed in a lib directory in an interface will override any libraries in a parent interface or the PilotFish application itself.
      3. Unlike formats, the libraries added here are not scoped to the interface. Upon the PilotFish application initializing, all libraries in all Interfaces will be loaded and made globally accessible during the runtime of the application.
      4. To avoid possible library conflicts, it is generally recommended that all libraries be only placed in the lib directory of the eip-root.
   4. routes
      1. The Routes directory is where the PilotFish Routes that are a part of the interface are stored.
      2. Within this directory are a series of sub-directories, each one named after an individual Route. Within these directories are all the individual configuration files needed to make these Routes run.
      3. Routes are semi-scoped within their interface; they are assigned a URI that includes the interface path so that they can be referenced by Routes in other interfaces internally within the application.
   5. interfaces
      1. The interfaces directory contains the sub-interfaces of this interface package.
      2. Because interfaces are structured as a hierarchy, each interface has children. Those child interfaces go into this directory.
      3. Within this directory are sub-directories, each one named after a different interface. Each of those interface directories contains this same directory structure within it.

Deploying a Working Directory

1. 1. Because all the configurations are just files in this hierarchy, deploying an interface to a production server is as easy as copying the working directory over to it.
   2. Compression is frequently recommended to facilitate this.
   3. Platform specific values should always be stored in Environment Properties. Upon deployment, these values should be changed as necessary to reflect the new system.