Validating a process execution document without yet executing the process

[jerstlouis]

In the context of building a bridge between our server supporting the Workflows extension with a core OGC API - Processes, we realized it would be very useful to validate the submission of a process execution document without actually triggering the processing.

This could be as simple as introducing a "mode" : "validate", and would allow the server to validate all inputs, and if successful return the list of outputs (without actual data) that would have been returned if the process was executed. This may also be related to the Quotation extension (e.g. "mode" : "quotation").

In the proposed Workflows extension, a workflow involving one or more processes can first be validated along the full chain to make sure it will work, before requests can be issued for specific AoI+resolution. Supporting this would allow to implement this bridge while properly validating processes from APIs not supporting the Workflows extension, used as part of such a workflow.

[jerstlouis]

mode is gone now (#172) The Styles API has a dry-run=true query parameter for validation.

[pvretano]

@jerstlouis so we can close this one?

[jerstlouis]

@pvretano no please don't close this one.

Maybe it could be tagged an extension, but ideally it should be included at least as a conformance class in Core to allow e.g. workflows to validate Core processes integrated as part of the workflows before actually doing any processing.

A mechanism to ask the server: will you be able to execute this request?

[bpross-52n]

It will remain an extension topic.

[bpross-52n]

SWG meeting from 2024-03-18: Add mechanism to validate a execution request without actually executing it. See Testbed-14 Quotation and Billing APIs for harmonization.

[fmigneault]

validate Core processes integrated as part of the workflows before actually doing any processing. A mechanism to ask the server: will you be able to execute this request?

I would like to highlight that this is part of what the POST /processes DRU's role can accomplish when submitting the executionUnit consisting of a Workflow, to validate if the workflow is valid in order to execute it afterward. This ties in nicely with @pvretano's comment during the SWG meeting of 2024-07-08.

[jerstlouis]

@fmigneault Yes, DRU usually implies validation, but the difference between DRU and ad-hoc execution (which could validate or quote only) are:

• ad-hoc execution doesn't create a new process resource available to everyone accessing the API (extra privacy / security / authentication considerations),
• ad-hoc execution requires completely filled in inputs, whereas workflows targeting deployment as a process usually (though not always e.g. "ringing a bell process") map input parameters to the process to inputs within the workflow, and outputs of the workflow processes to outputs of the deployed process.

[fmigneault]

extra privacy / security / authentication considerations

I think those are non issues. Our server handles all of them without problem. Only the user creating the process (or groups/users that he shared it with) see the process when listing /processes.

ad-hoc execution requires completely filled in inputs [...]

My main concern is that we keep duplicating endpoints and capabilities to support ad-hoc workflows, whereas everything would be completely transparent if those were handled as DRU, whether they are a simple process or a very convoluted workflow. The simplification of ad-hoc, while useful for simple use cases, seems to always over-complicate all other cases.

[jerstlouis]

I think those are non issues. Our server handles all of them without problem.

They are an issue if you wish to set up an easily accessible deployment supporting some amount of ad-hoc workflow execution without requiring a user account / registration.

The simplification of ad-hoc, while useful for simple use cases, seems to always over-complicate all other cases.

It is a different use cases.

What people can do with DRU, they can already do. So we shold not be over-complicating something that Core + DRU (1 + 2) can already do, since people can keep doing the exact same thing.

The ad-hoc workflow supports those other use cases, where you want to allow anyone to just put together these relatively safe processes that you've already provided at an end-point.