This tutorial demonstrates how to build and deploy a Galaxy Interactive Tool (GxIT). GxITs are accessible through the Galaxy tool panel, like any installed Galaxy tool. Our example application is a simple R Shiny app that we call Tabulator.

There are three elements to a GxIT - an application script, a Docker container and a Galaxy tool XML file. This tutorial will take you through creating those components, and installing them as a new Interactive Tool into a local Galaxy instance and an existing Galaxy instance.

Comment: If you plan to use an existing Galaxy instance

The Galaxy server requires specific configuration in order to run Interactive Tools! Please refer to this admin tutorial for setting up a compatible Galaxy instance for development and testing of your GxIT. As well as updating the Galaxy server configuration, you will also have to configure the server’s DNS provider to allow wildcard DNS records. This allows Galaxy to create unique host names (subdomains) for GxITs to be served over, separating them from the main Galaxy application.

Agenda

In this tutorial, we will cover:

1. How do Interactive Tools work?
2. When is an Interactive Tool appropriate?
3. The development process
4. The application
   1. The R scripts
   2. The Dockerfile
   3. Test the image
   4. Push the image
   5. The tool XML
5. Additional components
   1. Run script
   2. Templated config files
   3. Reserved environment variables
   4. Galaxy history interaction
6. The JupyterLab
   1. The Dockerfile
   2. Test the image
   3. Push the image
   4. The tool XML
7. Testing locally
   1. Docker installation
   2. Galaxy installation
   3. Galaxy configuration
   4. Run Galaxy
8. Deployment in a running Galaxy instancce
9. Debugging
   1. Self-destruct script
10. Troubleshooting

How do Interactive Tools work?

Interactive tools are a special breed of Galaxy tools, which is relatively new to the Galaxy ecosystem - they are a work in progress! GxITs enable the user to run an entire web application through Galaxy, which opens as a new tab in the browser. This can enable users to explore and manipulate data in a rich interface, such as Jupyter notebooks and RStudio. To see some examples of GxITs in action, take a look at Galaxy EU “Live”.

Interactive tool development builds on the canonical tool-wrapping process. Instead of running a command, the tool feeds user input to a Docker container running the application. Once it’s up and running, the GxIT application can then be accessed through a unique URL generated by the Galaxy server. The user can then open the application, interact with their Galaxy data and then terminate the tool. On termination, the Docker container is stopped and removed, and the job is considered “complete”.

When is an Interactive Tool appropriate?

In a regular Galaxy tool the user passes data to the tool and waits for it to run. They then get some output file(s) when the tool run is complete. In an Interactive Tool, however, the users are provided with a graphical web interface allowing them to interact with their data in real time. This is great for visualising data, but if it is possible to provide the same functionality with a regular tool (e.g. by rendering an HTML file as an output), then an Interactive Tool might not be necessary.

If you are sure that a static output is not sufficient, then it’s time to start building your first Interactive Tool!

Comment: Interactive tool infrastructure

Interactive tools require some rather complex infrastructure in order to work! However, most of the infrastructure requirements are taken care of by Galaxy core. As such, wrapping a new GxIT requires only three components:

• Application script(s)
• Docker container image
• Galaxy tool XML

However, as we will see in the next section, testing and deploying a GxIT is not so simple.

The development process

Since the infrastructure for building GxITs is not as well developed as regular tool wrapping, the development process is unfortunately not so streamlined. Where Planemo is typically used for tool linting and testing, the complex architecture of GxITs requires a local instance or a development server to be built to manually test and run the tool. In addition, they are currently not supported by the Galaxy ToolShed and have to be installed manually. This means that distributed GxITs can be found in the Galaxy core codebase, and they can be manually enabled by the Galaxy server administrator.

However, the build process itself is not too complex! We can break it down into just a few steps:

1. Find or create the application you wish to install on Galaxy
2. Find or create a Docker image containing this application
3. Write a Galaxy tool XML to pass IT details to Galaxy and pass user input to the Docker container
4. Add the tool XML to your Galaxy server (local or distant)
5. Try out the tool in the Galaxy interface. Error messages might appear in the Galaxy history.
6. If errors occur, revise the container or tool XML, and try again until the application is working.

The last step is likely where the most time is spent - the process requires iterative development of the Docker image and tool XML until they work together. As such, reducing the iteration time is the key to quick development! Throughout the tutorial, we’ll sprinkle in some tips on how to speed up the development cycle.

Comment: A note on architecture

When building a GxIT, it is best to keep as much logic as possible in the tool XML, while keeping the Docker image as generic as possible. Why? Updating the tool XML is simple for Galaxy admins and developers in the future. They can view the tool XML directly on the server and understand how the tool works. The Docker image, meanwhile, is relatively opaque to other developers and administrators. To understand the container they must locate the original Dockerfile, which is not always available. Updating the container is more complex, as we will see later. Additionally, keeping the Docker container generic makes it testable outside of Galaxy.

In short: updating the Docker container is hard, but updating the tool XML is easy!

Hands-on: Choose Your Own Tutorial

This is a "Choose Your Own Tutorial" section, where you can select between multiple paths. Click one of the buttons below to select how you want to follow the tutorial

Do you want to build a desktop application or a JupyterLab tool ?

Application JupyterLab

# Set image to build upon
FROM rocker/shiny

# set author
MAINTAINER Lain Pavot <lain.pavot@inra.fr>

## we copy the installer and run it before copying the entire project to prevent
## reinstalling everything each time the project has changed

COPY ./gxit/install.R /tmp/

RUN \
        apt-get update                                \
    &&  apt-get install -y --no-install-recommends    \
        fonts-texgyre                                 \
    &&  Rscript /tmp/install.R                        \
    &&  apt-get clean autoclean                       \
    &&  apt-get autoremove --yes                      \
    &&  rm -rf /var/lib/{apt,dpkg,cache,log}/         \
    &&  rm -rf /tmp/*                                 ;


# ------------------------------------------------------------------------------

# These default values can be overridden when we run the container:
#     docker run -p 8080:8080 -e PORT=8080 -e LOG_PATH=/tmp/shiny/gxit.log <container_name>

# We can also bind the container $LOG_PATH to a local directory in order to
# follow the log file from the host machine as the container runs. This command
# will create the log/ directory in our current working directory at runtime -
# inside we will find our Shiny app log file:
#     docker run -p 8888:8888 -e LOG_PATH=/tmp/shiny/gxit.log -v $PWD/log:/tmp/shiny <container_name>

ARG PORT=8765
ARG LOG_PATH=/tmp/gxit.log

ENV LOG_PATH=$LOG_PATH
ENV PORT=$PORT

# ------------------------------------------------------------------------------

# Edit shiny-server config to use our port
RUN cat /etc/shiny-server/shiny-server.conf \
    | sed "s/3838/${PORT}/" > /etc/shiny-server/shiny-server.conf.1
RUN mv /etc/shiny-server/shiny-server.conf.1 /etc/shiny-server/shiny-server.conf

# ------------------------------------------------------------------------------

RUN mkdir -p $(dirname "${LOG_PATH}")
EXPOSE $PORT
COPY ./gxit/app.R /srv/shiny-server/

CMD ["/bin/sh", "-c", "shiny-server > ${LOG_PATH} 2>&1"]

$__tool_directory__
$__root_dir__
$__user_id__
$__user_email__

<environment_variables>
    <environment_variable name="HISTORY_ID" strip="True">${__app__.security.encode_id($jupyter_notebook.history_id)}</environment_variable>
    <environment_variable name="REMOTE_HOST">${__app__.config.galaxy_infrastructure_url}</environment_variable>
    <environment_variable name="GALAXY_WEB_PORT">8080</environment_variable>
    <environment_variable name="GALAXY_URL">$__galaxy_url__</environment_variable>
    <environment_variable name="DEBUG">true</environment_variable>
    <environment_variable name="DISABLE_AUTH">true</environment_variable>
    <environment_variable name="API_KEY" inject="api_key" />
</environment_variables>

# Jupyter container used for Galaxy copernicus notebooks (+other kernels) Integration

# from 5th March 2021
FROM jupyter/datascience-notebook:python-3.10

MAINTAINER Björn A. Grüning, bjoern.gruening@gmail.com

ENV DEBIAN_FRONTEND noninteractive
USER root

RUN apt-get -qq update && \
    apt-get install -y wget unzip net-tools procps && \
    apt-get autoremove -y && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

# Set channels to (defaults) > bioconda > conda-forge
RUN conda config --add channels conda-forge && \
    conda config --add channels bioconda
    #conda config --add channels defaults
RUN pip install --upgrade pip
RUN pip install --no-cache-dir bioblend galaxy-ie-helpers

ENV JUPYTER /opt/conda/bin/jupyter
ENV PYTHON /opt/conda/bin/python
ENV LD_LIBRARY_PATH /opt/conda/lib/

# Python packages
RUN conda config --add channels conda-forge && \
    conda config --add channels bioconda && \
    conda install --yes --quiet \
    bash_kernel \
    ansible-kernel \
    bioblend galaxy-ie-helpers \

    # specific sentinel, openeo packages
    sentinelhub \
    openeo \
    # other packages for notebooks
    geopandas \
    rasterio \
    ipyleaflet \
    netcdf4 \
    h5netcdf \
    # Jupyter widgets
    jupytext && \
    conda clean -yt && \
    pip install jupyterlab_hdf \
    fusets

ADD ./startup.sh /startup.sh
ADD ./get_notebook.py /get_notebook.py

# We can get away with just creating this single file and Jupyter will create the rest of the
# profile for us.
RUN mkdir -p /home/$NB_USER/.ipython/profile_default/startup/ && \
    mkdir -p /home/$NB_USER/.jupyter/custom/

COPY ./ipython-profile.py /home/$NB_USER/.ipython/profile_default/startup/00-load.py
COPY jupyter_notebook_config.py /home/$NB_USER/.jupyter/
COPY jupyter_lab_config.py /home/$NB_USER/.jupyter/

ADD ./custom.js /home/$NB_USER/.jupyter/custom/custom.js
ADD ./custom.css /home/$NB_USER/.jupyter/custom/custom.css
ADD ./default_notebook.ipynb /home/$NB_USER/notebook.ipynb

# Download notebooks
RUN cd /home/$NB_USER/ &&  \
    wget -O notebook-samples.zip https://github.com/eu-cdse/notebook-samples/archive/refs/heads/main.zip && \
    unzip notebook-samples.zip && \
    rm /home/$NB_USER/notebook-samples.zip && \
    mv /home/$NB_USER/notebook-samples-main/geo /home/$NB_USER && \
    mv /home/$NB_USER/notebook-samples-main/sentinelhub /home/$NB_USER && \
    mv /home/$NB_USER/notebook-samples-main/openeo /home/$NB_USER && \
    rm -r /home/$NB_USER/notebook-samples-main

# ENV variables to replace conf file
ENV DEBUG=false \
    GALAXY_WEB_PORT=10000 \
    NOTEBOOK_PASSWORD=none \
    CORS_ORIGIN=none \
    DOCKER_PORT=none \
    API_KEY=none \
    HISTORY_ID=none \
    REMOTE_HOST=none \
    GALAXY_URL=none

# @jupyterlab/google-drive  not yet supported

USER root
WORKDIR /import

# Start Jupyter Notebook
CMD /startup.sh

Testing locally

You would like to check your GxIT integration in Galaxy but don’t have a development server or don’t want to disturb your sysadmin at this point? Let’s check this integration on your machine. You can use a VM if you prefer not to modify your machine environment.

Comment: A note on the OS

This part of the tutorial has been tested on Ubuntu and Debian and there is no guaranteed success for other operating systems. If you have another OS on your machine (i.e. Windows or MacOS), you may need to use an Ubuntu virtual machine or perhaps try Windows subsystem for Linux.

Docker installation

Hands-on: Install Docker

Install Docker as described on the docker website. Click on your distribution name to get specific information.

Galaxy installation

Hands-on: Install Galaxy

For Ubuntu:

# Install git to get Galaxy project
sudo apt-get install git
# Create a working directory and move to it
mkdir ~/GxIT && cd ~/GxIT
# Get the galaxy project. A new directory named "galaxy" will be created.
# This directory contains the whole project
git clone https://github.com/galaxyproject/galaxy
# Checkout the last stable version (v23.1 as the time of writing)
cd galaxy && git checkout release_23.1

Galaxy configuration

Hands-on

cd ~/GxIT/galaxy/config
# Create custom config files
cat galaxy.yml.interactivetools > galaxy.yml
cat tool_conf.xml.sample > tool_conf.xml

In galaxy.yml, ensure that the galaxy_infrastructure_url parameter is present under the galaxy section:

galaxy:
  galaxy_infrastructure_url: http://localhost:8080

This will make galaxy to provide your GxIT using links like http://your_gxit_identifier.localhost:8080.

Configure the tool panel by adding a section in ~/GxIT/galaxy/config/tool_conf.xml:

  <section id="interactivetools" name="Interactive tools">
    <tool file="interactive/interactivetool_tabulator.xml" />
    <tool file="interactive/interactivetool_copernicus.xml" />
  </section>

With these lines, Galaxy will create a new section named “Interactive tools” in the tool panel with our interactive tabulator inside. Choose whatever name and id you want as long as the id is unique. And of course, you have no obligation to put your GxITs in this section. You can put them in any section.

Next, create a simple job_conf.xml with the following contents, which basically specifies how Galaxy should execute a job. It is also possible to execute the tools directly from the local environment, but here we would like the tool to make use of the container we have just made.

<?xml version="1.0"?>
<job_conf>
    <plugins>
        <plugin id="local" type="runner" load="galaxy.jobs.runners.local:LocalJobRunner" workers="4"/>
    </plugins>
    <destinations default="docker_dispatch">
        <destination id="local" runner="local"/>
        <destination id="docker_local" runner="local">
            <param id="docker_enabled">true</param>
            <param id="docker_volumes">$defaults</param>
            <param id="docker_sudo">false</param>
            <param id="docker_net">bridge</param>
            <param id="docker_auto_rm">true</param>
            <param id="require_container">true</param>
            <param id="container_monitor">true</param>
            <param id="docker_set_user"></param>
            <param id="docker_run_extra_arguments">--add-host localhost:host-gateway</param>
        </destination>
        <destination id="docker_dispatch" runner="dynamic">
            <param id="type">docker_dispatch</param>
            <param id="docker_destination_id">docker_local</param>
            <param id="default_destination_id">local</param>
        </destination>
    </destinations>
</job_conf>

Finally, copy your GxIT wrapper to the Interactive Tool directory (depending on if you followed the Application or Jupyterlab part of the tuto):

cp ~/my_filepath/interactivetool_tabulator.xml ~/GxIT/galaxy/tools/interactive/

OR

cp ~/my_filepath/interactivetool_copernicus.xml ~/GxIT/galaxy/tools/interactive/

Run Galaxy

Go to the Galaxy directory and:

./run.sh

Galaxy is available at http://localhost:8080/ and you should be able to use your GxIT. Congrats!

Deployment in a running Galaxy instancce

We now have all the required components and tested in a local Galaxy instance above, we can install the tool in our configured Galaxy instance for immediate production use. This is as simple as dropping the tool XML in the right location inside the Galaxy core application directory, and adding the tool to our tool_conf_interactive.xml file.

Hands-on: Installing

1. Add the tool XML

   Access your Galaxy instance and take a look at the Galaxy application directory on to see the existing Interactive Tools:

   # Drop into the Galaxy application directory
   cd /srv/galaxy/server/
   
   # Show the existing GxIT tool files
   ls -l tools/interactive
   

2. Now we can simply create our tools XML here by writing it with nano

   # Open a new file for editing
   sudo nano tools/interactive/interactivetool_tabulator.xml
   
   # >>>  paste the XML content from your code editor and save the file
   

3. Enable the new tool

   This step is the same as activating any other existing Interactive Tool. See the admin tutorial for detailed instructions.

   # Open the Interactive Tools config file for editing:
   sudo nano /srv/galaxy/config/tool_conf.xml
   

4. This configuration file should have been created when administering the Galaxy instance to serve Interactive Tools We just need to add a single line to this file to enable our tool. Can you figure it out?

   Solution

   <toolbox monitor="true">
       <section id="interactivetools" name="Interactive Tools">
           <tool file="interactive/interactivetool_tabulator.xml" />
       </section>
   </toolbox>
   

   OR

   <toolbox monitor="true">
       <section id="interactivetools" name="Interactive Tools">
           <tool file="interactive/interactivetool_copernicus.xml" />
       </section>
   </toolbox>
   

5. Now we just need to restart the Galaxy server to refresh the tool registry

   sudo galaxyctl restart
   

Have a look in the web interface of your Galaxy instance. You should find the new tool under the “Interactive tools” section in the tool panel. If so, we are ready to start testing it out!

Tip: Distributing a new GxIT

To release a GxIT for production use, we must distribute two components:

• the Galaxy tool XML
• the Docker image

We have already pushed the Docker image to the cloud (though it should be hosted on an approved registry for production use).

All that’s left is to distribute the tool XML. This would conventionally be done through the ToolShed. But the ToolShed doesn’t support GxITs yet! This leaves us only two options for distributing the tool XML:

• Make a pull request against Galaxy core to include the XML file under tools/interactive/
• Deploy the tool to specific Galaxy instance(s) in an Ansible Playbook

Tip: Install a GxIT with an Ansible playbook

The steps that we took in this section can be easily incorporated into an Ansible playbook for deploying GxITs to a Galaxy server. This means that you can manage and deploy a GxIT as part of your Galaxy instance without merging into the galaxyproject/galaxy repository (or a fork of it).

The Interactive Tools admin tutorial demonstrates how this can be acheived by adding our tool XML to the “local tools” section of the Ansible Playbook. However, for our GxIT to show up in the correct tool panel, we need to add an extra config file: local_tool_conf.xml.

1. Copy the GxIT tool XML to files/galaxy/tools/interactivetool_tabulator.xml in your Ansible directory

2. Create the template templates/galaxy/local_tool_conf.xml.j2

   <?xml version='1.0' encoding='utf-8'?>
   <toolbox monitor="true" tool_path="{{ galaxy_local_tools_dir }}">
       <section id="interactivetools" name="Interactive tools">
           <tool file="interactivetool_tabulator.xml" />
       </section>
   </toolbox>
   

OR

   <?xml version='1.0' encoding='utf-8'?>
   <toolbox monitor="true" tool_path="{{ galaxy_local_tools_dir }}">
       <section id="interactivetools" name="Interactive tools">
           <tool file="interactivetool_copernicus.xml" />
       </section>
   </toolbox>

1. Create variables in the following sections of group_vars/galaxyservers.yml

   # ...
   galaxy_local_tools_dir: "{{ galaxy_server_dir }}/tools/local"
   galaxy_tool_config_files:
     # ...
     - "{{ galaxy_config_dir }}/local_tool_conf.xml"
   

2. Run the playbook and your Interactive Tool should be available at the bottom of the tool panel

   ansible-playbook galaxy.yml
   

Debugging

The most obvious way to test a tool is simply to run it in the Galaxy UI, straight from the tool panel. If you are extremely lucky, you will find that the tool starts up and runs without error. But we all know that never happens! So this is where we start iteratively debugging our tool, until it functions as expected.

Comment: A successful tool run

It is worth pointing out that the appearance of a GxIT in the Galaxy user history is not intuitive when you are used to running “regular” tool jobs. When the history item turns orange (“processing”), that’s when a GxIT is actually ready to use! At this point, the tool UI should refresh and display a link to the active GxIT. Remember, the history item doesn’t turn green until a job has terminated. With a GxIT, that only happens when the tool has been stopped by the user, or by wall time limits imposed by the Galaxy administrators.

Tip: GxIT testing infrastructure

Testing and debugging is currently the trickiest part of GxIT development. Ideally, Galaxy core will be developed in the future to better support the process, but for the time being we have to make the most with what is available! In the future, we would like to see GxITs being tested with Planemo, and being installed and tested by Ephemeris from the ToolShed.

Self-destruct script

Unlike regular tools that exit after the execution of the underlying command is complete, web applications will run indefinitely until terminated. With Galaxy’s legacy “Interactive Environments”, this used to result in “zombie” containers hanging around and clogging up the Galaxy server. You may notice a terminate.sh script in some older GxITs as a workaround to this problem, but the new GxIT architecture handles container termination for you. This script is no longer required nor recommended.

Troubleshooting

Having issues with your Interactive Tool? Here are a few ideas for how to troubleshoot your application. Remember that Galaxy Interactive Tools are a work in progress, so feel free to get creative with your solutions here!

• Getting an error in the Galaxy History? Click on the “view” icon to see details of the tool run, including the tool command, stdout and stderr.
• If the tool’s stdout/stderr is not enough, consider modifying the Docker image to make it more verbose. Add print/log statements and assertions. Write an application log to a file that can be collected as Galaxy output.
• Try running the container with Docker directly on your development machine. If the application doesn’t work independently, it certainly won’t work inside Galaxy!
• If you need to debug the Docker container itself, it can be useful to write output/logging to a mounted volume that can be inspected after the tool has run.
• You can also open a bash terminal inside the container to check the container state while the application is running: docker exec -it mycontainer /bin/bash

You've Finished the Tutorial

Please also consider filling out the Feedback Form as well!

Key points

• Galaxy Interactive Tools (GxIT) provide an interface for external web applications to be embedded in Galaxy

• GxITs require complex architecture, but most of this is handled by Galaxy core

• Example GxITs are Jupyter notebooks, RStudio or R Shiny apps

• GxITs are heavily dependant on container technologies like Docker

• If a tool is containerized, it can be integrated rapidly into Galaxy as a GxIT

• In theory, any containerized web application can be wrapped as a GxIT

Frequently Asked Questions

Feedback

Did you use this material as an instructor? Feel free to give us feedback on how it went.
Did you use this material as a learner or student? Click the form below to leave feedback.

Citing this Tutorial

1. Estelle Ancelet, Yvan Le Bras, Cameron Hyde, Lain Pavot, Anthony Bretaudeau, Helena Rasche, Marie Josse, Galaxy Interactive Tools (Galaxy Training Materials). https://training.galaxyproject.org/training-material/topics/dev/tutorials/interactive-tools/tutorial.html Online; accessed TODAY
2. Hiltemann, Saskia, Rasche, Helena et al., 2023 Galaxy Training: A Powerful Framework for Teaching! PLOS Computational Biology 10.1371/journal.pcbi.1010752
3. Batut et al., 2018 Community-Driven Data Analysis Training for Biology Cell Systems 10.1016/j.cels.2018.05.012

BibTeX

@misc{dev-interactive-tools,
author = "Estelle Ancelet and Yvan Le Bras and Cameron Hyde and Lain Pavot and Anthony Bretaudeau and Helena Rasche and Marie Josse",
	title = "Galaxy Interactive Tools (Galaxy Training Materials)",
	year = "",
	month = "",
	day = "",
	url = "\url{https://training.galaxyproject.org/training-material/topics/dev/tutorials/interactive-tools/tutorial.html}",
	note = "[Online; accessed TODAY]"
}
@article{Hiltemann_2023,
	doi = {10.1371/journal.pcbi.1010752},
	url = {https://doi.org/10.1371%2Fjournal.pcbi.1010752},
	year = 2023,
	month = {jan},
	publisher = {Public Library of Science ({PLoS})},
	volume = {19},
	number = {1},
	pages = {e1010752},
	author = {Saskia Hiltemann and Helena Rasche and Simon Gladman and Hans-Rudolf Hotz and Delphine Larivi{\`{e}}re and Daniel Blankenberg and Pratik D. Jagtap and Thomas Wollmann and Anthony Bretaudeau and Nadia Gou{\'{e}} and Timothy J. Griffin and Coline Royaux and Yvan Le Bras and Subina Mehta and Anna Syme and Frederik Coppens and Bert Droesbeke and Nicola Soranzo and Wendi Bacon and Fotis Psomopoulos and Crist{\'{o}}bal Gallardo-Alba and John Davis and Melanie Christine Föll and Matthias Fahrner and Maria A. Doyle and Beatriz Serrano-Solano and Anne Claire Fouilloux and Peter van Heusden and Wolfgang Maier and Dave Clements and Florian Heyl and Björn Grüning and B{\'{e}}r{\'{e}}nice Batut and},
	editor = {Francis Ouellette},
	title = {Galaxy Training: A powerful framework for teaching!},
	journal = {PLoS Comput Biol}
}

                   

Galaxy Administrators: Install the missing tools

You can use Ephemeris's shed-tools install command to install the tools used in this tutorial.

shed-tools install [-g GALAXY] [-a API_KEY] -t <(curl https://training.galaxyproject.org/training-material/api/topics/dev/tutorials/interactive-tools/tutorial.json | jq .admin_install_yaml -r)

Alternatively you can copy and paste the following YAML

---
install_tool_dependencies: true
install_repository_dependencies: true
install_resolver_dependencies: true
tools: []

Feedback

No feedback has been recieved yet for this training. Be the first one by filling in the feedback form from above.