How it Works (abstract)

  • Updated on Jul 21, 2020
  • Published on Jul 21, 2020
  • 1 minute(s) read
Prev Next

  1. Query the FC with /s to get metadata. Keep it in state, or potentially use it before invoking a protocol if you’re worried about FC server update churn.

  2. Query the FC with /p and {“request”:”get_protocols”} to get objects representing every protocol.

  3. Parse the protocol objects and use the “callback_protocol” or “callback_script” within argument objects to call back to the FC with /q (or /t) to get values that the client can then use to specify argument values for running the protocol.

  4. Provide a mechanism for code or a user to specify argument values. Pay attention to the “argument_set_type” of the “argument_sets” containing the arguments. The FC will enforce “mandatory”, “minimum-one”, “maximum-one”, and “optional” argument_sets, i.e. a protocol can’t be run if invoked without a mandatory argument set.

  5. When a protocol is configured and ready to be run, use the /q or /t request method to invoke the protocol, with argument names as keys and values selected by the client/user.

  6. Parse the results to enlighten users or use in other software systems.

  7. Store the results of the query/analysis as Useful Data ArtifacTs (UDATs), along with the FC metadata from /s for reproducibility. Alternatively, you could just store the “protocol_instance” used in the /q or /t request, which with the same FC server, project and data version available, will reproduce the same analysis result.

  8. Many advanced protocols will return with callbacks to protocols within that FC or potentially in other FCs. These callbacks represent a path forward to follow-up and perform new relevant queries/analyses.