Skip to content

Latest commit

 

History

History
61 lines (43 loc) · 2.73 KB

README.md

File metadata and controls

61 lines (43 loc) · 2.73 KB

Python 3.11 Build Status Code style: black Linting

Flow Production Tracking Event Framework

This software was originaly developed by Patrick Boucher with support from Rodeo Fx and Oblique. It is now part of Flow Production Tracking Software's open source initiative.

This software is provided under the MIT License that can be found in the LICENSE file or at the Open Source Initiative website.

Overview

When you want to access the Flow Production Tracking event stream, the preferred way to do so it to monitor the events table, get any new events, process them and repeat.

A lot of stuff is required for this process to work successfully, stuff that may not have any direct bearing on the business rules that need to be applied.

The role of the framework is to keep any tedious monitoring tasks out of the hands of the business logic implementor.

The framework is a daemon process that runs on a server and monitors the Shotgun event stream. When events are found, the daemon hands the events out to a series of registered plugins. Each plugin can process the event as it wishes.

The daemon handles:

  • Registering plugins from one or more specified paths.
  • Deactivate any crashing plugins.
  • Reloading plugins when they change on disk.
  • Monitoring the Flow Production Tracking event stream.
  • Remembering the last processed event id and any backlog.
  • Starting from the last processed event id on daemon startup.
  • Catching any connection errors.
  • Logging information to stdout, file or email as required.
  • Creating a connection to Shotgun that will be used by the callback.
  • Handing off events to registered callbacks.

A plugin handles:

  • Registering any number of callbacks into the framework.
  • Processing a single event when one is provided by the framework.

Advantages of the framework

  • Only deal with a single monitoring mechanism for all scripts, not one per script.
  • Minimize network and database load (only one monitor that supplies event to many event processing plugins).

Documentation

See the GitHub Wiki.