Skip to content
Architecture

3forge Architecture

3forge is made up of three components:

  1. The Center: This process manages communication and data processing/movement between the various Web and Relay processes. It also contains an in-memory database and event processing/scheduling modules.

  2. The Web: This process runs a web server responsible for managing dashboards and entitlements and rendering visualizations.

  3. The Relay: This process is responsible for real‑time integration with external systems. Acting as a connector to data streams, the Relay enables command execution and communication between your infrastructure and the Center. More specifically, the Relay can:

    • Receive real-time streaming data from local applications
    • Connect to databases and other datasources to issue and process on-demand queries, procedures, etc.
    • Access the local file system for investigating log files, excel files and data files
    • Interact with the local shell environment to run scripts and other executables

The 3forge architecture is designed for smooth installation with the ability to easily scale as needed. For getting started with lower capacity needs, 3forge can be installed and run as a single process. For additional capacity, the platform supports vertical scaling by breaking out the front end and backend applications into separate processes. Beyond that, even more capacity can be achieved through horizontally scaling additional processes.

Components

The Center is 3forge's real-time database.

Any number of Relays and webservers can be connected to a Center. The Center is where real-time data processing, connection management and data virtualization are done. It houses the in-memory database which can be accessed through the command line interface and JDBC interface.

See this page for more information about the Center.

The Web is 3forge's graphical user interface.

Any number of web servers can be connected to the Center. The web server interacts with web browsers and provides the end user experience.

See this page for more information about the Web.

The Relay is the bridge between data sources and the Center.

Any number of Relays can be connected to a Center. Each Relay can be connected to any number or combination of files, databases, secure shells (SSH), scripts and custom applications.

See this page for more information about the Relay.

Scaling

3forge will scale as the processing needs to scale. For use cases where all processing can be done through a single instance, only a single AMI One process is necessary. This process contains all the components and interfaces discussed above. The architecture is quite simple:

Note: AMI One simply bundles all the functionality of the Relay, Center, and Web in a single process.

See this page for information about vertical and horizontal scaling.

External Interfaces

There are 8 key categories of external interfaces supported by 3forge:

  • GUI: Fully featured dashboards provide user access to all the various components and data made available to 3forge. The platform utilizes the standard web browser (http[s]) for constructing and using dashboards as well as most of the administration and configuration.
  • Queries: Any number of datasources can be attached to the platform and queried at runtime - either by a user action or by some electronic/automated event..
  • Real-time Streaming: Applications can connect and stream messages directly into 3forge. These can include sending new records, or updating or deleting existing records. This can be used to push information onto dashboards in real-time and/or to evaluate events with 3forge's event processing system.
  • Callbacks: Applications can register call backs with 3forge. These callbacks can be executed by the user or automatically triggered by 3forge's event processing system.
  • JDBC (Java Database Connectivity): 3forge can be accessed via JDBC just like accessing other traditional databases. JDBC can be used to query and/or update the internal state of the platform. In combination with 3forge's data virtualization layer, this can also be used to query multiple datasources using a common JDBC connection.
  • Command Line: The command line interface allows users and/or applications to run commands directly from 3forge's backend.
  • Trace Level Exhaust: All mutations to 3forge's internal state are made available through the trace level exhaust. This is used for persisting data and auditing changes.
  • Enterprise I/O: Most enterprises have existing operations environments consisting of single sign on services, Entitlements/User Permissions and Naming services. 3forge has interfaces at key touch points throughout for providing adapters into the existing infrastructure.

Default File Structure

Below is the standard file structure for a new install of 3forge after it has been run once.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
    ami
    ├───README_AMIONE.txt
    ├───uninstall.exe
    │
    ├───.install4j
    │   └───...
    │
    ├───jre  - - - - - - - - - - - - - - - - - - Location of the Java JRE used by 3forge
    │   └───...
    │
    └───amione
        ├───.amionemain.prc  - - - - - - - - - - Used by stop.sh to shutdown 3forge
        ├───.console_history.txt
        ├───.f1proc.txt  - - - - - - - - - - - - A text readable audit trail of every time AMI starts and has a controlled shutdown 
        ├───AMI_One.exe
        ├───AMI_One.vmoptions  - - - - - - - - - Virtual machine options
        ├───error.log  - - - - - - - - - - - - - Major error log
        ├───output.log - - - - - - - - - - - - - Startup log
        │
        ├───config - - - - - - - - - - - - - - - Directory for storing properties, we recommend adding a local.properties file here, see the "AMI Configuration Guide" for more details
        │   ├───root.properties  - - - - - - - - References load order of other properties files
        │   ├───defaults.properties  - - - - - - Default properties
        │   ├───build.properties - - - - - - - - Build version properties
        │   └───speedlogger.properties - - - - - Logging properties
        │
        ├───data - - - - - - - - - - - - - - - - Stores developer/admin created files, such as routing tables.
        │   ├───access.txt - - - - - - - - - - - Access file (will be overwritten if new installation is on top of old)
        │   ├───managed_schema.amisql  - - - - - Schema file for AMIDB
        │   ├───relay.routes - - - - - - - - - - List of relay route names
        │   │
        │   ├───autosave - - - - - - - - - - - - Directory for autosaves by user
        │   │   ├───demo.cnt - - - - - - - - - - Current autosave number
        │   │   ├───demo.cur - - - - - - - - - - Recent autosaves
        │   │   ├───demo.old - - - - - - - - - - Older autosaves
        │   │   └───...
        │   │
        │   ├───cloud  - - - - - - - - - - - - - Directory for layouts saved in the cloud
        │   │   ├───my_layout.ami
        │   │   └───...
        │   │
        │   ├───fonts  - - - - - - - - - - - - - Directory for fonts
        │   │   ├───Arial.ttf
        │   │   └───...
        │   │
        │   ├───idfountain - - - - - - - - - - - Directory for managing autoincrementing ids
        │   │   └───...
        │   │
        │   ├───styles - - - - - - - - - - - - - Directory for readonly styles
        │   │   ├───HALLOWEEN.amistyle.json
        │   │   └───...
        │   │
        │   └───users  - - - - - - - - - - - - - Directory for user preferences
        │           demo.ami_settings
        │
        ├───history
        │   └───ami_console.history  - - - - - - 3forge command line history
        │
        ├───lib  - - - - - - - - - - - - - - - - Directory for java libraries, including libraries for the Web
        │   └───...
        │
        ├───log  - - - - - - - - - - - - - - - - Files with numbered extensions e.g. 0001 are logs from past runs of ami; files without numbered extensions are the most recent logs
        │   ├───AmiMessages.log  - - - - - - - - Log of all messages received by 3forge
        │   ├───AmiMessages.log.0001
        │   ├───AmiOne.amilog  - - - - - - - - - Log of internal messages within 3forge
        │   ├───AmiOne.amilog.0001
        │   ├───AmiOne.log - - - - - - - - - - - 3forge console log
        │   └───AmiOne.log.0001
        │
        ├───persist  - - - - - - - - - - - - - - Directory for generated files used for recovery (on restart).
        │   ├───amikey.aes - - - - - - - - - - - Encryption key that can be used to secure datasource passwords. More information in "Encryption -> Center Tables."
        │   ├───__CENTER.dat - - - - - - - - - - Info on multiple centers
        │   ├───__DATASOURCE.dat - - - - - - - - Info on datasources
        │   └───__REPLICATION.dat  - - - - - - - Info on replication centers
        │
        ├───resources  - - - - - - - - - - - - - Directory for storing resources (ex images) to be used by the webserver
        │
        └───scripts  - - - - - - - - - - - - - - UNIX/DOS scripts for starting/stopping 3forge
            ├───start.sh
            ├───stop.sh
            ├───restart.sh
            ├───tools.sh
            ├───start.bat
            ├───stop.bat
            ├───restart.bat
            └───tools.bat

Version Management

File Naming

The 3forge platform can be installed locally from your 3forge.com portal. The binary downloads are named with the following syntax where relnum is an incrementing release number and branch indicates the level of testing and maturity:

  • Windows: ami_windows-x64_[relnum]_[branch].exe

  • Mac: ami_macos_[relnum]_[branch].dmg

  • Unix: ami_unix_[relnum]_[branch].sh

  • Other (Tar gz): ami_unix_[relnum]_[branch].tar.gz

Example: ami_unix_12103_stable.sh indicates that it's a release for the unix operating system with a release number of 12103 in the stable branch.

Note

The relnum + branch is considered the version e.g. 12103.stable.

Branches

Name Stability Release Cycle When to Use
dev Minimal testing by developers prior to submitting a change Hourly To explore the latest features, testing, etc.
stable Reasonable testing by the QA and development team Weekly Early access to features, non-mission-critical use cases (ex: information dashboards)
qa Extensive internal and external testing Quarterly Highly reliable, critical use cases
prod Critically tested over several months of production use Biannual Extreme reliability, mission critical, cannot fail cases

Relnum

Release numbers are always increasing, regardless of branch.

Sample Release Management Flow

Release Notes

Release notes are delivered approximately once per quarter and cover all features graduating from dev to stable. There is no specific release date but instead they are released in sync with the delivery of note-worthy items.

Backwards Compatibility

We work to ensure that newer versions of 3forge can load dashboards from older versions. However, older versions of 3forge will very likely not be able to load dashboards built on new versions.

Bug Fixes

When a bug is detected in a certain branch, it is first fixed in that branch and then "patched" into other branches, assuming the bug exists in that branch as well. For example, if a bug is found in stable, it likely exists in dev. The bug would first be fixed in dev, then just that bug fix would be patched to stable. We would then test for the bug in qa. If fixed in qa, we would promote, and so on for production.

Fast Track Releases

Occasionally, customer requested features are fast tracked to a particular branch. In that case, the feature will be added to dev first and then patched into stable. We occasionally allow for promotion to qa, with features deemed non-destabilizing. They are never pushed to prod in order to avoid any chance of error.