Mock Activity Endpoint.

Arkadiusz Ryś 1f18e05289 Modernize tasks 8 ay önce
data 7d49a12f4f Allow setting storage endpoint uri 1 yıl önce
docs 1f18e05289 Modernize tasks 8 ay önce
mocka 8d1243001e Update changelog version 0.1.1 1 yıl önce
tests 798664ed7f Fix notch filter file referencing 1 yıl önce
.dockerignore 285fc1e3f5 Prevent docker from ignoring data 1 yıl önce
.editorconfig b6aeff41e9 Create boilerplate 1 yıl önce
.gitignore 448b1725cf Set options to ignore generated images 1 yıl önce
.gitlab-ci.yml b6aeff41e9 Create boilerplate 1 yıl önce
Dockerfile 7d6e57d346 Fix dockerfile dependencies 1 yıl önce
HISTORY.rst 8d1243001e Update changelog version 0.1.1 1 yıl önce
LICENSE b6aeff41e9 Create boilerplate 1 yıl önce
README.md 798664ed7f Fix notch filter file referencing 1 yıl önce
pyproject.toml 2de19d2c55 Clean up tasks 1 yıl önce
requirements.txt 2de19d2c55 Clean up tasks 1 yıl önce
tasks.py 1f18e05289 Modernize tasks 8 ay önce

README.md

Mocka

Mock Activity Endpoint. Automated activity enactments must be HTTP calls where users must specify the endpoint in the FTG's Transformation, and the timeout in the PM's Activity. As an activity gets triggered it requires knowledge of the control and artefact flow. This endpoint expects this context in the form of a json body following a highly specific format.

{
    "ctrl": "<name of control port going into the activity>",
    "input": {
        "<name of artefact port going into the activity>": {
            "type": "<inline|reference>",
            "content": <the contents of the artefact going into this port in case it's inlined>,
            "name": "<the file name>",
            "encoding": "<the encoding of said artefact>"
        }
    }
}

Anything between < and > is to be filled in by the requester. Only inline and reference type artefacts are supported at the moment. Which one you should use depends on the activity. A good rule to follow is: "If the filetype is text-like, use inline.".

Barring any errors, mocka will retaliate with a json response in the same gist.

{
    "ctrl": "<the name of the control port which should be taken out of the activity>",
    "output": {
        "<the name of the artefact which got generated>": {
            "type": "<inline|reference>",
            "content": <the contents of the generated artefact>,
            "name": "<the file name>",
            "encoding": "<the encoding of said artefact>"
        }
    }
}

This response can contain multiple artefacts. It can even be an error stating a timeout or broken input. The expectation is that the Workflow Enactment Engine will deal with the fallout.

NOTE: A call to store the artefact in the backend will be needed when the type of the output artefact is set to reference.

Deploying a mock activity endpoint

NOTE: Be sure to have ´libmagic´ installed. It is used to figure out the encoding of the artefacts being sent on their journey.

Drop into a shell and sing the magic incantation python3 -m mocka. This will leave you haunted with an endpoint lingering on port 7999 by default. From this point onward you're on your own and can perform any request you want.

Extra dependencies

There are multiple mock routers. The notch and octiva routers require external software to be installed. OpenCV in the case octiva and open-modelica in the case of notch. Installing the Python opencv-python package will the trick for the first one. Good luck on the modelica one.

Wishful thinking

It would be nice if this endpoint would support gradual progress updates. This would also require the Workflow Enactment Engine to do the same.

The storage backend location is hardcoded. It might be useful not to do this.

Not all the possible options are available when sending data. An example of this is an image. It should always be sent as a reference.