@ -254,13 +254,15 @@ After the transition to the the Launch state, like for every other transition, t
After a successful *Launch*, the Method execution moves into *Deploy* state. As shown by the script task decorator, this task is scripted meaning that by default it's a no-operation and the commands to be performed are supplied by the creator of the Method at definition time through the *deploy-script* attribute. Example operations that could occur during this phase in a deploy script are: fetching of code on Git repositories, installation of fine grained dependencies (for example *pip install -r requirements.txt*), building of code, downloading of resource files.
From the *Deploy* phase a Method execution enters the *Execute* phase. Like for the *Deploy* phase what exactly happens during this phase is determined by the *execute-script* provided by the Method creator at Method definition time. Instructions in the execute-script usually contain invocation of main code components.
After the *Deploy* phase, a Method execution enters the *Execute* phase. Like for the *Deploy* phase what exactly happens during this phase is determined by the *execute-script* provided by the Method creator at Method definition time. Instructions in the execute-script usually contain invocation of main code components.
The time spent in the *Execute* phase is limited by the Infrastructure. It is up the the Infrastructure manager to define what is the maximum amount of time allowed for Method execution. If the method allows it, the execution time can be futher limited by the user requesting the execution of a Method, by setting the *ccpmaxtime* input parameter.
The *Fetch* following a successful *Execute* phase is a non scriptable transition in charge of uploading the outputs of a Method execution to the Execution storage.
The following *Undeploy* phase can be used by Method developers to perform operations after the Method execution has terminated. This phase is not thought to be a cleanup task because on containerised Infrastructures the system takes autonoumously care of destroying resources at the end of a Method execution. Instead it could be used to perform extra work like notifying external systems or sharing outputs.
.. The following *Undeploy* phase can be used by Method developers to perform operations after the Method execution has terminated. This phase is not thought to be a cleanup task because on containerised Infrastructures the system takes autonoumously care of destroying resources at the end of a Method execution. Instead it could be used to perform extra work like notifying external systems or sharing outputs.
It is currently not possible to script the "Undeploy" phase because, on container based Infrastructures, the system takes autonoumously care of destroying resources at the end of a Method execution.
Finally, the *Destroy* phase is the time where the Infrastructure controller literally destroys the Runtime of the execution and all resources created during the previous phases.
@ -394,7 +396,7 @@ The Method list widget is comprised of a toolbar, a search field and the list of
Method editor
~~~~~~~~~~~~~
The *Method editor* widget is a visual tool for creating, deleting, editing or cloning a Method descriptor.
The *Method editor* widget is a visual tool for creating, deleting, editing, cloning or deriving a Method descriptor.
The following Figure shows an example visualization of the Method editor.
@ -420,7 +422,9 @@ The following Figure shows an example visualization of the Method execution form
Method execution form
In the area labelled with [1], the principal metadata of the Method is shown. In the Inputs area [2] it is possible to edit the input values that are passed to the Execution. The input fields try to match as close as possible the constraints defined for the input in the Method descriptor. The execute button [4] triggers the sending of the execution request. A code generator widget [5] can be used in order to download code snippets that act as working examples for requesting the Execution programmatically through the CCP APIs (see :ref:`rest`). Currently Python 3, R, Jupyter Notebook are supported but the list will grow in the future.
In the area labelled with [1], the principal metadata of the Method is shown. In the Inputs area [2] it is possible to edit the input values that are passed to the Execution. The input fields try to match as close as possible the constraints defined for the input in the Method descriptor. The execute button [4] triggers the sending of the execution request. A code generator widget [5] can be used in order to download code snippets that act as working examples for requesting the Execution programmatically through the CCP APIs (see :ref:`rest`). Currently Python 3, R, Jupyter Notebook and Julia are supported but the list will grow in the future.
A direct link is provided that, when navigated to, will open the execution form with exactly the same parametrization that has been submitted for execution.
Execution monitor
~~~~~~~~~~~~~~~~~
@ -434,7 +438,11 @@ The following Figure shows an example visualization of the Execution monitor.
Execution monitor
The list of Executions are organized by their Method names [1]. For every Method the number of executions in the different states ('accepted', 'running', 'successful', 'failed') is reported. When expanding a Method the list of all Executions is shown [2]. Every list item reports information about the Method version, the status, timing, Infrastructure and Runtime of the Execution. When outputs are available a link to download them is shown [3]. Actions that can be performed on an Execution [5] are download as zip archive, archive to workspace, download provenance descriptor in Prov-O format, re-execute and delete. An Execution item can also be drag and dropped onto the Execution form widget in order to prepare a request for a new onne. Code for programmatically requesting the same Execution can be generated with a proper code generation widget [6]. Currently Python 3, R and Jupyter Notebooks are supported. By using the triggers on the global toolbar [6] the list of Executions can be refreshed, a previously exported Execution can be reimported from a local zip file and archived Exections can be re-imported from their sharable workspace link.
The list of Executions are organized by their Method names [1]. For every Method the number of executions in the different states ('accepted', 'running', 'successful', 'failed') is reported. When expanding a Method the list of all Executions is shown [2]. Every list item reports information about the Method version, the status, timing, Infrastructure and Runtime of the Execution. When outputs are available a link to download them is shown [3]. Actions that can be performed on an Execution [5] are download as zip archive, archive to workspace, download provenance descriptor in Prov-O format, re-execute and delete. An Execution item can also be drag and dropped onto the Execution form widget in order to prepare a request for a new onne. Code for programmatically requesting the same Execution can be generated with a proper code generation widget [6]. Currently Python 3, R, Julia and Jupyter Notebooks are currently supported.
A direct link is shown that allows, when navigated to, to open the execution form with exatly the same parametrization of the execution itself.
By using the triggers on the global toolbar [6] the list of Executions can be refreshed, a previously exported Execution can be reimported from a local zip file and archived Exections can be re-imported from their sharable workspace link.
.. _rest:
@ -445,7 +453,7 @@ Most of the services that build up CCP are accessible programmatically via REST
In particular, listing Methods (Jobs), executing them or getting infromation on running executions (jobStatus) are accessible through a standard API defined by OGC (Open Geospatial Consortium).
The REST API is Processes 1.2 described at (https://ogcapi.ogc.org/processes/) and can be considered a modern rework of the former WPS spcification.
The CCP REST API is documented as OpenAPI 3 specification at ().
The CCP REST API is documented as OpenAPI 3 specification at (https://app.swaggerhub.com/apis/OGC/ogcapi-processes-1-example-1/1.0.0).
Through the code generation widgets available in the UI elements described above, it is possible to obtain stubs that show how to interact programmatically with CCP in order to request a Method execution or re-execution and to monitor the evolution.
<liclass="toctree-l2"><aclass="reference internal"href="usermanual/index.html#rest-apis-interacting-with-methods-and-executions-programmatically">REST APIs: Interacting with Methods and Executions programmatically</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="#rest-apis-interacting-with-methods-and-executions-programmatically">REST APIs: Interacting with Methods and Executions programmatically</a></li>
@ -122,187 +121,187 @@ The technology and the list of available Runtimes is strictly related to type of
<p>At its heart a Method is a JSON structure that aggregates a section of metadata, the definition of input parameters, the description of expected outputs, instructions for customising the deploy and execute steps of its lifecycle and link to a compatible Infrastructure.</p>
<p>The syntax of the JSON data structure is constrained by the grammar proposed by the OGC Processes API specification (<<aclass="reference external"href="https://ogcapi.ogc.org/processes/">https://ogcapi.ogc.org/processes/</a>>).</p>
<p>The following code snippet illustrates an example.</p>
<spanclass="w"></span><spanclass="nt">"title"</span><spanclass="p">:</span><spanclass="s2">"JDK-8 Example maven"</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Test for executing a jdk8 sample app from GitHub repository built with maven"</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"The image of the runtime to use for method execution. This depends on the infrastructure specific protocol for interacting with registries."</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Git url to repository"</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"The main class to run"</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Some output is written in txt format to file.txt"</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Some output is written in XML format to file.xml"</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Some output is written in JSON format to file.json"</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Some output is written in CSV format to file.csv"</span><spanclass="p">,</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"title"</span><spanclass="p">:</span><spanclass="s2">"Docker swarm with NFS on Nubis cluster"</span><spanclass="w"></span>
<spanclass="w"></span><spanclass="nt">"title"</span><spanclass="p">:</span><spanclass="s2">"JDK-8 Example maven"</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Test for executing a jdk8 sample app from GitHub repository built with maven"</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"The image of the runtime to use for method execution. This depends on the infrastructure specific protocol for interacting with registries."</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Git url to repository"</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"The main class to run"</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Some output is written in txt format to file.txt"</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Some output is written in XML format to file.xml"</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Some output is written in JSON format to file.json"</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"description"</span><spanclass="p">:</span><spanclass="s2">"Some output is written in CSV format to file.csv"</span><spanclass="p">,</span>
<spanclass="w"></span><spanclass="nt">"title"</span><spanclass="p">:</span><spanclass="s2">"Docker swarm with NFS on Nubis cluster"</span>
<spanclass="w"></span><spanclass="p">}</span>
<spanclass="w"></span><spanclass="p">]</span>
<spanclass="p">}</span>
</pre></div>
</div>
<p>This is an example of a Method that executes Java 8 code rooted at a main class <em>example.HelloWorld</em> and cloned from a public GitHub reposiotry. The code is built with Maven.</p>
@ -329,10 +328,10 @@ The technology and the list of available Runtimes is strictly related to type of
<p>The message carrying the execution request is sent to CCP and the execution starts. The first task puts the execution in <em>Launch</em> state. During this phase the Runtime for the execution is prepared. On a container based Infrastructure this usually resolves to using the <em>ccpimage</em> input parameter in order to fetch the container image from a reposiory and instantiatiate the container.</p>
<p>After the transition to the the Launch state, like for every other transition, the outcome of the operation is evaluated and in case of errors the process terminates by transitioning directly to the <em>Destroy</em> state thus ensuring that the infrastructure is cleaned up.</p>
<p>After a successful <em>Launch</em>, the Method execution moves into <em>Deploy</em> state. As shown by the script task decorator, this task is scripted meaning that by default it’s a no-operation and the commands to be performed are supplied by the creator of the Method at definition time through the <em>deploy-script</em> attribute. Example operations that could occur during this phase in a deploy script are: fetching of code on Git repositories, installation of fine grained dependencies (for example <em>pip install -r requirements.txt</em>), building of code, downloading of resource files.</p>
<p>From the <em>Deploy</em> phase a Method execution enters the <em>Execute</em> phase. Like for the <em>Deploy</em> phase what exactly happens during this phase is determined by the <em>execute-script</em> provided by the Method creator at Method definition time. Instructions in the execute-script usually contain invocation of main code components.</p>
<p>After the <em>Deploy</em> phase, a Method execution enters the <em>Execute</em> phase. Like for the <em>Deploy</em> phase what exactly happens during this phase is determined by the <em>execute-script</em> provided by the Method creator at Method definition time. Instructions in the execute-script usually contain invocation of main code components.</p>
<p>The time spent in the <em>Execute</em> phase is limited by the Infrastructure. It is up the the Infrastructure manager to define what is the maximum amount of time allowed for Method execution. If the method allows it, the execution time can be futher limited by the user requesting the execution of a Method, by setting the <em>ccpmaxtime</em> input parameter.</p>
<p>The <em>Fetch</em> following a successful <em>Execute</em> phase is a non scriptable transition in charge of uploading the outputs of a Method execution to the Execution storage.</p>
<p>The following <em>Undeploy</em> phase can be used by Method developers to perform operations after the Method execution has terminated. This phase is not thought to be a cleanup task because on containerised Infrastructures the system takes autonoumously care of destroying resources at the end of a Method execution. Instead it could be used to perform extra work like notifying external systems or sharing outputs.</p>
<p>It is currently not possible to script the “Undeploy” phase because, on container based Infrastructures, the system takes autonoumously care of destroying resources at the end of a Method execution.</p>
<p>Finally, the <em>Destroy</em> phase is the time where the Infrastructure controller literally destroys the Runtime of the execution and all resources created during the previous phases.</p>
</section>
<sectionid="execution-context-of-a-method">
@ -356,7 +355,7 @@ The technology and the list of available Runtimes is strictly related to type of
<p>The following variables are related to the authentication and authorization context of the Method execution. They can be used to access D4Science services in a secure and convenient way also for very long lasting executions.</p>
<divclass="code-block-caption"><spanclass="caption-text">How to use <em>ccptaskid</em> to separate output of different replicas to different files in <em>execute-script</em>.</span><aclass="headerlink"href="#id2"title="Permalink to this code"></a></div>
@ -477,7 +476,8 @@ The following is a representation of the data structure representing an Executio
<p><spanclass="caption-text">Method execution form</span><aclass="headerlink"href="#id6"title="Permalink to this image"></a></p>
</figcaption>
</figure>
<p>In the area labelled with [1], the principal metadata of the Method is shown. In the Inputs area [2] it is possible to edit the input values that are passed to the Execution. The input fields try to match as close as possible the constraints defined for the input in the Method descriptor. The execute button [4] triggers the sending of the execution request. A code generator widget [5] can be used in order to download code snippets that act as working examples for requesting the Execution programmatically through the CCP APIs (see <aclass="reference internal"href="#rest"><spanclass="std std-ref">REST APIs: Interacting with Methods and Executions programmatically</span></a>). Currently Python 3, R, Jupyter Notebook are supported but the list will grow in the future.</p>
<p>In the area labelled with [1], the principal metadata of the Method is shown. In the Inputs area [2] it is possible to edit the input values that are passed to the Execution. The input fields try to match as close as possible the constraints defined for the input in the Method descriptor. The execute button [4] triggers the sending of the execution request. A code generator widget [5] can be used in order to download code snippets that act as working examples for requesting the Execution programmatically through the CCP APIs (see <aclass="reference internal"href="#rest"><spanclass="std std-ref">REST APIs: Interacting with Methods and Executions programmatically</span></a>). Currently Python 3, R, Jupyter Notebook and Julia are supported but the list will grow in the future.</p>
<p>A direct link is provided that, when navigated to, will open the execution form with exactly the same parametrization that has been submitted for execution.</p>
</section>
<sectionid="execution-monitor">
<h3>Execution monitor<aclass="headerlink"href="#execution-monitor"title="Permalink to this heading"></a></h3>
@ -489,7 +489,9 @@ The following is a representation of the data structure representing an Executio
<p><spanclass="caption-text">Execution monitor</span><aclass="headerlink"href="#id7"title="Permalink to this image"></a></p>
</figcaption>
</figure>
<p>The list of Executions are organized by their Method names [1]. For every Method the number of executions in the different states (‘accepted’, ‘running’, ‘successful’, ‘failed’) is reported. When expanding a Method the list of all Executions is shown [2]. Every list item reports information about the Method version, the status, timing, Infrastructure and Runtime of the Execution. When outputs are available a link to download them is shown [3]. Actions that can be performed on an Execution [5] are download as zip archive, archive to workspace, download provenance descriptor in Prov-O format, re-execute and delete. An Execution item can also be drag and dropped onto the Execution form widget in order to prepare a request for a new onne. Code for programmatically requesting the same Execution can be generated with a proper code generation widget [6]. Currently Python 3, R and Jupyter Notebooks are supported. By using the triggers on the global toolbar [6] the list of Executions can be refreshed, a previously exported Execution can be reimported from a local zip file and archived Exections can be re-imported from their sharable workspace link.</p>
<p>The list of Executions are organized by their Method names [1]. For every Method the number of executions in the different states (‘accepted’, ‘running’, ‘successful’, ‘failed’) is reported. When expanding a Method the list of all Executions is shown [2]. Every list item reports information about the Method version, the status, timing, Infrastructure and Runtime of the Execution. When outputs are available a link to download them is shown [3]. Actions that can be performed on an Execution [5] are download as zip archive, archive to workspace, download provenance descriptor in Prov-O format, re-execute and delete. An Execution item can also be drag and dropped onto the Execution form widget in order to prepare a request for a new onne. Code for programmatically requesting the same Execution can be generated with a proper code generation widget [6]. Currently Python 3, R, Julia and Jupyter Notebooks are currently supported.</p>
<p>A direct link is shown that allows, when navigated to, to open the execution form with exatly the same parametrization of the execution itself.</p>
<p>By using the triggers on the global toolbar [6] the list of Executions can be refreshed, a previously exported Execution can be reimported from a local zip file and archived Exections can be re-imported from their sharable workspace link.</p>
@ -497,36 +499,36 @@ The following is a representation of the data structure representing an Executio
<p>Most of the services that build up CCP are accessible programmatically via REST endpoints.
In particular, listing Methods (Jobs), executing them or getting infromation on running executions (jobStatus) are accessible through a standard API defined by OGC (Open Geospatial Consortium).
The REST API is Processes 1.2 described at (<aclass="reference external"href="https://ogcapi.ogc.org/processes/">https://ogcapi.ogc.org/processes/</a>) and can be considered a modern rework of the former WPS spcification.</p>
<p>The CCP REST API is documented as OpenAPI 3 specification at ().</p>
<p>The CCP REST API is documented as OpenAPI 3 specification at (<aclass="reference external"href="https://app.swaggerhub.com/apis/OGC/ogcapi-processes-1-example-1/1.0.0">https://app.swaggerhub.com/apis/OGC/ogcapi-processes-1-example-1/1.0.0</a>).</p>
<p>Through the code generation widgets available in the UI elements described above, it is possible to obtain stubs that show how to interact programmatically with CCP in order to request a Method execution or re-execution and to monitor the evolution.</p>
<p>The following is an example code stub generated for the R programming language.</p>
<divclass="code-block-caption"><spanclass="caption-text">Example code for requesting a Method execution on CCP</span><aclass="headerlink"href="#id8"title="Permalink to this code"></a></div>
<spanclass="n">pwd</span><spanclass="o">=</span><spanclass="nf">askForPassword</span><spanclass="p">(</span><spanclass="s">'Password to login'</span><spanclass="p">)</span>
<spanclass="w"></span><spanclass="n">pwd</span><spanclass="w"></span><spanclass="o">=</span><spanclass="w"></span><spanclass="nf">askForPassword</span><spanclass="p">(</span><spanclass="s">'Password to login'</span><spanclass="p">)</span>
<spanclass="nf">stop</span><spanclass="p">(</span><spanclass="nf">paste</span><spanclass="p">(</span><spanclass="s">'Unable to start execution:'</span><spanclass="p">,</span><spanclass="nf">content</span><spanclass="p">(</span><spanclass="n">res</span><spanclass="p">,</span><spanclass="s">'text'</span><spanclass="p">)))</span>
<spanclass="w"></span><spanclass="nf">stop</span><spanclass="p">(</span><spanclass="nf">paste</span><spanclass="p">(</span><spanclass="s">'Unable to start execution:'</span><spanclass="p">,</span><spanclass="w"></span><spanclass="nf">content</span><spanclass="p">(</span><spanclass="n">res</span><spanclass="p">,</span><spanclass="w"></span><spanclass="s">'text'</span><spanclass="p">)))</span>
<spanclass="w"></span><spanclass="nf">stop</span><spanclass="p">(</span><spanclass="s">'Unable to poll for execution status'</span><spanclass="p">)</span>
@ -254,13 +254,15 @@ After the transition to the the Launch state, like for every other transition, t
After a successful *Launch*, the Method execution moves into *Deploy* state. As shown by the script task decorator, this task is scripted meaning that by default it's a no-operation and the commands to be performed are supplied by the creator of the Method at definition time through the *deploy-script* attribute. Example operations that could occur during this phase in a deploy script are: fetching of code on Git repositories, installation of fine grained dependencies (for example *pip install -r requirements.txt*), building of code, downloading of resource files.
From the *Deploy* phase a Method execution enters the *Execute* phase. Like for the *Deploy* phase what exactly happens during this phase is determined by the *execute-script* provided by the Method creator at Method definition time. Instructions in the execute-script usually contain invocation of main code components.
After the *Deploy* phase, a Method execution enters the *Execute* phase. Like for the *Deploy* phase what exactly happens during this phase is determined by the *execute-script* provided by the Method creator at Method definition time. Instructions in the execute-script usually contain invocation of main code components.
The time spent in the *Execute* phase is limited by the Infrastructure. It is up the the Infrastructure manager to define what is the maximum amount of time allowed for Method execution. If the method allows it, the execution time can be futher limited by the user requesting the execution of a Method, by setting the *ccpmaxtime* input parameter.
The *Fetch* following a successful *Execute* phase is a non scriptable transition in charge of uploading the outputs of a Method execution to the Execution storage.
The following *Undeploy* phase can be used by Method developers to perform operations after the Method execution has terminated. This phase is not thought to be a cleanup task because on containerised Infrastructures the system takes autonoumously care of destroying resources at the end of a Method execution. Instead it could be used to perform extra work like notifying external systems or sharing outputs.
.. The following *Undeploy* phase can be used by Method developers to perform operations after the Method execution has terminated. This phase is not thought to be a cleanup task because on containerised Infrastructures the system takes autonoumously care of destroying resources at the end of a Method execution. Instead it could be used to perform extra work like notifying external systems or sharing outputs.
It is currently not possible to script the "Undeploy" phase because, on container based Infrastructures, the system takes autonoumously care of destroying resources at the end of a Method execution.
Finally, the *Destroy* phase is the time where the Infrastructure controller literally destroys the Runtime of the execution and all resources created during the previous phases.
@ -394,7 +396,7 @@ The Method list widget is comprised of a toolbar, a search field and the list of
Method editor
~~~~~~~~~~~~~
The *Method editor* widget is a visual tool for creating, deleting, editing or cloning a Method descriptor.
The *Method editor* widget is a visual tool for creating, deleting, editing, cloning or deriving a Method descriptor.
The following Figure shows an example visualization of the Method editor.
@ -420,7 +422,9 @@ The following Figure shows an example visualization of the Method execution form
Method execution form
In the area labelled with [1], the principal metadata of the Method is shown. In the Inputs area [2] it is possible to edit the input values that are passed to the Execution. The input fields try to match as close as possible the constraints defined for the input in the Method descriptor. The execute button [4] triggers the sending of the execution request. A code generator widget [5] can be used in order to download code snippets that act as working examples for requesting the Execution programmatically through the CCP APIs (see :ref:`rest`). Currently Python 3, R, Jupyter Notebook are supported but the list will grow in the future.
In the area labelled with [1], the principal metadata of the Method is shown. In the Inputs area [2] it is possible to edit the input values that are passed to the Execution. The input fields try to match as close as possible the constraints defined for the input in the Method descriptor. The execute button [4] triggers the sending of the execution request. A code generator widget [5] can be used in order to download code snippets that act as working examples for requesting the Execution programmatically through the CCP APIs (see :ref:`rest`). Currently Python 3, R, Jupyter Notebook and Julia are supported but the list will grow in the future.
A direct link is provided that, when navigated to, will open the execution form with exactly the same parametrization that has been submitted for execution.
Execution monitor
~~~~~~~~~~~~~~~~~
@ -434,7 +438,11 @@ The following Figure shows an example visualization of the Execution monitor.
Execution monitor
The list of Executions are organized by their Method names [1]. For every Method the number of executions in the different states ('accepted', 'running', 'successful', 'failed') is reported. When expanding a Method the list of all Executions is shown [2]. Every list item reports information about the Method version, the status, timing, Infrastructure and Runtime of the Execution. When outputs are available a link to download them is shown [3]. Actions that can be performed on an Execution [5] are download as zip archive, archive to workspace, download provenance descriptor in Prov-O format, re-execute and delete. An Execution item can also be drag and dropped onto the Execution form widget in order to prepare a request for a new onne. Code for programmatically requesting the same Execution can be generated with a proper code generation widget [6]. Currently Python 3, R and Jupyter Notebooks are supported. By using the triggers on the global toolbar [6] the list of Executions can be refreshed, a previously exported Execution can be reimported from a local zip file and archived Exections can be re-imported from their sharable workspace link.
The list of Executions are organized by their Method names [1]. For every Method the number of executions in the different states ('accepted', 'running', 'successful', 'failed') is reported. When expanding a Method the list of all Executions is shown [2]. Every list item reports information about the Method version, the status, timing, Infrastructure and Runtime of the Execution. When outputs are available a link to download them is shown [3]. Actions that can be performed on an Execution [5] are download as zip archive, archive to workspace, download provenance descriptor in Prov-O format, re-execute and delete. An Execution item can also be drag and dropped onto the Execution form widget in order to prepare a request for a new onne. Code for programmatically requesting the same Execution can be generated with a proper code generation widget [6]. Currently Python 3, R, Julia and Jupyter Notebooks are currently supported.
A direct link is shown that allows, when navigated to, to open the execution form with exatly the same parametrization of the execution itself.
By using the triggers on the global toolbar [6] the list of Executions can be refreshed, a previously exported Execution can be reimported from a local zip file and archived Exections can be re-imported from their sharable workspace link.
.._rest:
@ -445,7 +453,7 @@ Most of the services that build up CCP are accessible programmatically via REST
In particular, listing Methods (Jobs), executing them or getting infromation on running executions (jobStatus) are accessible through a standard API defined by OGC (Open Geospatial Consortium).
The REST API is Processes 1.2 described at (https://ogcapi.ogc.org/processes/) and can be considered a modern rework of the former WPS spcification.
The CCP REST API is documented as OpenAPI 3 specification at ().
The CCP REST API is documented as OpenAPI 3 specification at (https://app.swaggerhub.com/apis/OGC/ogcapi-processes-1-example-1/1.0.0).
Through the code generation widgets available in the UI elements described above, it is possible to obtain stubs that show how to interact programmatically with CCP in order to request a Method execution or re-execution and to monitor the evolution.
dcore94