Software integrations
It is possible to perform analyses with the use of third-party software directly from the VIKTOR interface. This guide will provide information on how to implement an analysis using third-party software in your app using a so-called VIKTOR worker.
Installation
Please follow the steps listed in installation to set up an integration.
Supported software
Currently, the integrations listed in the table below are available. If the software package that you want to interact with is not listed below, you can make use of our generic integrations.
Whether or not the software package you want to integrate with is listed, please reach out to us if you need help setting up an integration through the Community Forum!
Worker
A worker is a small application (executable) that is installed on a designated machine on which the software of interest is installed. This machine can either be physical or virtual. A worker is always built for one specific VIKTOR application (domain) and when executed will run in the background and wait for a 'task' from that domain. This task consists of the input(s) required for the software. When the worker receives the task, it will call the software and perform an analysis with the provided input(s). Meanwhile, the application from which the task is sent waits until the worker finishes the calculation and sends back the results. The following schematic shows this concept:
VIKTOR worker flow
Implementation example
Each integration makes use of viktor.ExternalProgram. The
ExternalProgram.execute method is the
trigger to send a task to the worker on the external machine.
The following piece of code shows an example implementation of an integration with SCIA Engineer:
import viktor as vkt
input_esa = ...
input_xml = ...
input_xml_def = ...
scia_analysis = vkt.scia.SciaAnalysis(input_xml, input_xml_def, input_esa)
scia_analysis.execute(timeout=300) # triggers the worker, wait until complete
results = scia_analysis.get_xml_output_file()
Multiple worker instances
The VIKTOR - worker interaction is configured such that it can easily be scaled up (or down). For example, the worker application can execute multiple instances (processes) of the software package.
Worker running multiple processes on single machine
Running parallel routines requires a worker version of at least v4.7.1 and should not be a generic worker.
A worker can also be executed multiple times across multiple different machines. Tasks are distributed randomly over the running worker instances, and thus multiple users can make use of the external integration at the same time!
Multiple workers across multiple machines
Parallel execution has to be supported by the software. Often each job will require an individual license of the software. So when 2 jobs run in parallel, this will probably require 2 software licenses as well. If no license is available, the worker will fail to execute the program and the external analysis will return a LicenseError to the VIKTOR application (unless a TimeoutError is returned first).
Worker status
Within the VIKTOR interface, a user can see the status of the connected workers via the icon in the top right corner:
This gives a user insights in:
- which workers are connected and available
- how many workers per external package are connected
- whether a worker is currently running a job or not
Worker status
Note that the worker status does not provide information about licenses being available or not!