Trayio-task is a web microservice used to manage a simplified version of tray.io's core workflow execution platform.

The service is written using Play framework with Scala and H2 in memory database. Operations on the database are performed using Slick plugin. The application is built using sbt.

In order to deploy the service:

• Clone the project from gitHub git clone https://github.com/HoneyB4dger/trayio-task.git
• cd trayio-task
• sbt run - this will download the dependencies, check and compile the application
• You should see massage (Server started, use Enter to stop and go back to the console...)

The service is running on http://localhost:9500/. If this is on your local machine, you can view that url in your internet browser. Here you can use the service thorugh web forms.

If you prefer to use command line, use the following REST endpoints:

Returns a list of workflows.

Returns a list of workflow executions.

Adds a workflow to the service. Requires a number of steps in a workflow (int between 1-1024). Format: {"number_of_steps": n}

Adds a workflow execution to the service. Requires a workflow id it is attached to. Format: {"workflow_id": n}

Increment step index in workflow execution. Requires a workflow execution id. Format: {"workflow_execution_id": n}

Returns wheter or not a workflow execution has finished. Requires a workflow execution id. Format: {"workflow_execution_id": n}

Example call: curl --header "Content-type: application/json" -X POST http://localhost:9500/workflow -d '{"number_of_steps": 4}'

You can test the service manually by either interacting with the web interface or performing REST calls. To test the service performing under a higher load, you can use a Python script (autoTests.py). It sends a random REST call at a given interval. To use it: python autoTests.py -t <number_of_calls> -d <delay_between_calls>

Additional functionality to consider:

• Using in memory database H2. This can be replace with another database (for example PostgreSQL) by modifying build.sbt and application.conf files. Check evolutions settings so that the database is not dropped each time the service starts.
• Default port that the application runs on is 9500. You can change this in Play, however, a better way would be to set up a proxy server (Apache/Nginx).
• Interaction with the service takes place either via POST requests or http forms. This could be improved with Swagger which adds front end, documentation and testing functionality.
• Security needs to be reviewed - need to add claims authentication.
• Improve Play tests by adding additional scenarios.
• Need to convert the service into production setting and package.
• Number of threads should be optimised for the machine the service is running on.
• Workflow execution model would benefit from an additional field - "finished". This would help with the cleanup.
• Cleanup job could be improved - wait 1min after workflow execution has finished.
• Logging could be improved with an ELK stack.