Log out?

Exercise 9.1 – The Working Directory

Purpose:

To review the location of items within the Working Directory.


Steps:

  1. EIP-ROOT
    1. The “working directory” is frequently also 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. However, 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 certain PilotFish modules, etc.
    5. The “eip-root” is also considered to be the root Interface package.


  2. Interface Hierarchy
    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 was its own “eip-root”. The PilotFish application can be run with a starting working directory of any valid interface package.


  3. Interface Directory Structure
    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. In order 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 in 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.


  4. Deploying a Working Directory
    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.
    2. Compression is frequently recommended in order 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.


This is a unique website which will require a more modern browser to work! Please upgrade today!

Thanks!

Our editors are notified.

Close