Module view: Activity UI and Service API
Diagrams are embedded as SVG images. If the text is too small, please use your web browser to zoom in to the images, which should be magnified without losing detail. Alternatively open image in a new tab with right click + Open in a new tab.
This view is a module view depicting the key components involved in SB activity execution; that is, requesting an activity described by a Scheduling Block to be run.
Elements and their properties
ActivityState is an enumeration defining the states that an Activity (a concept linking Scheduling Blocks
to Procedures) can be in. State machine for activities has not yet been completely defined and currently
Activity can only be in state
ActivityService provides the high-level API for the activity domain, presenting methods that
‘run a script referenced by activity X of scheduling block Y’. The ActivityService completes user requests
by translating the activity requests into Procedure domain commands which then execute the scripts.
For a the OET REST deployment, ActivityServiceWorker is the client sending requests to the ActivityService.
The major public interface in these interactions is the ActivityService API. For more information on this interface, please see the Module View: REST API.
Activity API invocation via HTTP REST
The sequence diagram below illustrates how the components above interact to invoke a call on an remote ActivityService instance in response to a request from a client. This diagram shows how the user request is received by the FlaskWorker REST backend, how that triggers actions on independent ActivityWorker process hosting the ActivityService instance, and how the response is returned to the user
The Activity domain uses the same publish-subscribe system as Procedure domain for both communication between FlaskWorker and ActivityServiceWorker and for the ActivityService to communicate with the ScriptExecutionServiceWorker. For a diagram illustrating the flow of in-process pypubsub messages, see the Inter-process publish-subscribe section in the script execution API documentation.
Storing Scheduling Block in the Filesystem
It is currently only possible to deploy the activity and procedure services as one service. This means that the Scheduling Block can be written to file by the ActivityService and it will still be available to the Procedure domain. In the future the Activity and Procedure related services could be deployed in different locations so the current approach of saving SBs to a file should be refactored so that the script running on a different server can also access the SB.
Scheduling Block URI
Currently the Scheduling Block URI used in the OET system is a simple path string to a JSON file referred to by a keyword argument sb_json. In the future this will be expanded into a proper URI with several allowed prefixes such as file:// for SB located in a file and oda:// for SB that should be retrieved from the ODA.