Home

Flow Production Tracking creates an event log entry for every action that happens on your Flow Production Tracking site. You can see these events in your site, as well as through the Flow Production Tracking API. In addition to simply seeing your event history, you can write your own event listener scripts to poll the EventLog and act on certain events you care about. Your script can execute other internal scripts in your pipeline, use the Flow Production Tracking API to update data Flow Production Tracking or both.

The event trigger framework is a daemon process that runs on a server and monitors the Flow Production Tracking 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.

IMPORTANT NOTICE

This system doesn't guarantee event delivery. Please read the section on Event Backlogs. If guaranteed event delivery is required, please consider using Webhooks which weren't a thing when this framework was written over 10 years ago.

Contents

• Installation
  • System Requirements
  • Installing the API
  • Installing shotgunEvents
    • Cloning the source
    • Downloading the archive
  • Windows Specifics
• Configuration
  • Edit shotgunEventDaemon.conf
    • Flow Production Tracking Settings
    • Plugin Settings
    • Location of shotgunEventDaemon.conf
  • Testing the daemon
  • Running the daemon
    • A Note About Logging
  • Common Errors
  • List of Configuration File Settings
    • Daemon Settings
    • Flow Production Tracking Settings
    • Plugin Settings
    • Email Settings
• Plugins
  • registerCallbacks function
  • Callbacks
  • Logging
  • Building Robust Plugins
• API
  • registerCallbacks
  • Registrar
  • Callback
• Technical Details
  • Event Types
  • Plugin processing order
  • Sharing state
  • Event Backlogs
• Example Plugins
  • Plugin Template
  • Plugin Example 1: New Entities
  • Plugin Example 2: Create Notes for Retired Entities

Known Issues

• When processing a large amount of items through a batch process. The resulting events may not be processed. There is code to address this but it is rather new and might not be completely bug free.

If you would like to submit issues please go to the GitHub issues page.

Going forward

Here is some stuff that could be changed or added going forward:

• Parallelize the processing of events. A tough one considering possible event dependencies.
• Pass all data to the callbacks using a context object for better future scalability.
• Allow for late creation of the Flow Production Tracking connections on access by the callback.
• Make config reading more robust.