Getting Started

In this chapter we will explain the basic life-cycle and execution model of a "Frontier Fusion" prototype along with the main things to consider when developing it. If you'd rather directly start coding, please directly go to the first tutorial Python based prototype

Basic principle

Overview

The high-level execution model of a processing prototype is simple: It will be started by the respective runtime environment (AIRC Research or OpenApps) and load input data from a specified directory. After the input data is processed it will store the results in another directory and terminate.

The runtime environment will ensure that the configured directories are created and populated with the correct data before the prototype is executed. In the same sense it will collect the results, store them in a persistent storage and trigger downstream processing (e.g. sending to a DICOM node).

The prototype itself needs to support the possibility to pass the concrete directories as command line arguments. Details on the directories and command line parameters are given below.

Requirements for a prototype

The prototype to onboard must fulfill the following technical criteria:

• Needs to be a Windows executable (Linux is "in the making"...)
• Can be distributed as a self-contained "XCOPY deployable" ZIP file. This in particular means that all required libraries can be distributed within a single ZIP file. No system wide installation is required.
• Offer the possibility to pass the following directories as command line arguments:

Argument	Description	Mandatory?	Token
Input directory	The prototype needs to read its input data from this directory. Before the prototype is started, the infrastructure will provide all input data in this directory.	Yes	{InputDirectory}
Result directory	The prototype needs to store its results/output data in this directory. Prototype needs to terminate afterwards. Afterwards the infrastructure will pick up the data in this folder and make it persistent.	Yes	{ResultDirectory}
Configuration directory	Infrastructure will provide any configuration data in this folder before the prototype is triggered. This configuration data can typically be modified by the user using a provided configuration UI. The configuration UI can be developed together with the prototype or a generic configuration UI can be used.	No	{ConfigDirectory}
Log directory	The prototype needs to provide its log data into this directory. The infrastructure will further process it and ensure it is made available to the developer through developer portal (for AIRC Research deployment) or through syngo mechanisms (for OpenApps deployment).	No	{LogDirectory}
Intermediate storage directory	This is a special folder: Some prototypes require to be performed multiple times, for instance if a user interaction happens in between. Based on the user interaction, a reprocessing of the data is required. Prototypes which support this kind of reprocessing need to understand the concept of "intermediate storage directory". During the first run, they need to store appropriate data in this folder such that during the second run they can identify that this is a reprocessing of the same case. The content of this directory is treated by the framework as a black box and is deleted after results have been found in the results folder.	No	{IntermediateDirectory}
Share directory	To access the results generated by protype outside of AIRC and OpenApps, the prototype can share files via teamplay Data Lake. In order to share files, the user must have a valid data contract with teamplay Data Lake. Afterwards, the sharing needs to be enabled in the General configuration of the prototype and a valid data contract name must be specified. All the files stored in this directory are then shared via teamplay Data Lake.	No	{ShareDirectory}

note

Apart from the fact that the prototype needs to support these command line arguments, there are no further restrictions on their naming. The actual command line will be defined during the onboarding process, as described below. This gives the developer the freedom to choose whatever names the arguments need to have and assign the corresponding values using the tokens from the table above. Using this indirection even allows for onboarding existing prototypes where the source code is not available or cannot be modified as long as they are reading such command line arguments.

Processing only prototypes

This kind of prototypes is the only one currently supported. It needs to fulfil the abovementioned requirements. Results can be viewed with a generic viewing components provided by us. Furthermore it is possible to configure a generic configuration UI which fulfils basic configuration requirements for the prototype (see Using generic configuration).

Prototypes with a custom UI

Currently not supported. In a later version, the upload of a custom UI will be supported.

Future outlook

In addition to the uploaded executable there will be possibilities to directly upload the prototype as a container image. There are currently some limitations in deploying containers to the open apps environment. As soon as these are fixed, we will offer container onboarding.

Another topic is additional deployments. We are working on a standalone deployment variant. However, this is still work in progress.