weaver.wps.service

Module Contents

weaver.wps.service.LOGGER

class weaver.wps.service.WorkerRequest(http_request: weaver.typedefs.AnyRequestType | None = None, http_headers: weaver.typedefs.AnyHeadersCookieContainer | None = None, **kwargs: Any)

Extended pywps request with additional handling provided by weaver.

_auth_headers

auth_headers

parse_auth_headers(headers: weaver.typedefs.AnyHeadersCookieContainer | None) → werkzeug.datastructures.Headers

class weaver.wps.service.WorkerExecuteResponse(wps_request: WorkerRequest, uuid: str, process: pywps.app.Process, job_url: str, settings: weaver.typedefs.SettingsType, *_: Any, **__: Any)

XML response generator from predefined job status URL and executed process definition.

constructor

Parameters:

• wps_request (pywps.app.WPSRequest.WPSRequest)

• process (pywps.app.Process.Process)

• uuid – string this request uuid

store_status_file = True

class weaver.wps.service.WorkerService(*_, is_worker=False, settings=None, **__)

Dispatches PyWPS requests from WPS-1/2 XML endpoint to WPS-REST as appropriate.

Note

For every WPS-Request type, the parsing of XML content is already handled by the PyWPS service for GET/POST. All data must be retrieved from parsed WPSRequest to avoid managing argument location and WPS versions.

When GetCapabilities or DescribeProcess requests are received, directly return to result as XML based on content (no need to subprocess as Celery task that gets resolved quickly with only the process(es) details). When JSON content is requested, instead return the redirect link to corresponding WPS-REST API endpoint.

When receiving Execute request, convert the XML payload to corresponding JSON and dispatch it to the Celery Worker to actually process it after job setup for monitoring.

is_worker = False

settings

dispatched_processes: Dict[str, weaver.datatype.Process]

_get_capabilities_redirect(wps_request: pywps.app.WPSRequest, *_: Any, **__: Any) → pywps.response.basic.WPSResponse | weaver.typedefs.HTTPValid | None

Redirects to WPS-REST endpoint if requested Content-Type is JSON.

get_capabilities(wps_request: pywps.app.WPSRequest, *_: Any, **__: Any) → pywps.response.basic.WPSResponse | weaver.typedefs.HTTPValid

Handles the GetCapabilities KVP/XML request submitted on the WPS endpoint.

Redirects to WPS-REST endpoint if requested Content-Type is JSON or handle GetCapabilities normally.

_describe_process_redirect(wps_request: pywps.app.WPSRequest, *_: Any, **__: Any) → pywps.response.basic.WPSResponse | weaver.typedefs.HTTPValid | None

Redirects to WPS-REST endpoint if requested Content-Type is JSON.

describe(wps_request: pywps.app.WPSRequest, uuid: uuid.UUID, identifiers: List[str], *_: Any, **__: Any) → pywps.response.basic.WPSResponse | weaver.typedefs.HTTPValid

Handles the DescribeProcess KVP/XML request submitted on the WPS endpoint.

Redirect to WPS-REST endpoint if requested Content-Type is JSON or handle DescribeProcess normally.

_submit_job(wps_request: pywps.app.WPSRequest) → pywps.response.basic.WPSResponse | weaver.typedefs.HTTPValid | weaver.typedefs.JSON

Dispatch operation to WPS-REST endpoint, which in turn should call back the real Celery Worker for execution.

Returns the status response as is if XML, or convert it to JSON, according to request Accept header.

create_complex_inputs(source: pywps.inout.basic.ComplexInput, inputs: List[Dict[str, str]]) → Deque[pywps.inout.basic.ComplexInput]

Dynamically adjust process input definitions to align with unrestricted format as applicable.

Due to how create_complex_inputs() of pywps is implemented (check of format by [0] index), a supported_formats property must always contain at least 1 format. However, that restriction erroneously rejects an “any” Media-Type input that does not enforce a specific format (i.e.: text/plain and */* by default). Therefore, update the input dynamically to inject the missing formats matching submitted inputs to make them succeed the validation transparently.

Without this patch, a submitted input trying to be more informative about its content by advertising its actual Media-Type, schema, encoding, etc. gets penalized over an input “just” submitting the complex data/file reference.

prepare_process_for_execution(identifier: str) → pywps.app.Process

Handles dispatched remote provider process preparation during execution request.

execute(identifier: str, wps_request: pywps.app.WPSRequest | WorkerRequest, uuid: str) → pywps.response.basic.WPSResponse | weaver.typedefs.HTTPValid

Handles the Execute KVP/XML request submitted on the WPS endpoint.

Submit WPS request to corresponding WPS-REST endpoint and convert back for requested Accept content-type.

Overrides the original execute operation, that will instead be handled by execute_job() following callback from celery worker, which handles Job creation and monitoring.

If Accept is JSON, the result is directly returned from _submit_job(). If Accept is XML or undefined, WorkerExecuteResponse converts the received JSON with XML template.

execute_job(job: weaver.datatype.Job, wps_inputs: List[weaver.typedefs.WPS_InputData], wps_outputs: List[weaver.typedefs.WPS_OutputRequested], remote_process: weaver.datatype.Process | None, headers: weaver.typedefs.AnyHeadersCookieContainer | None) → owslib.wps.WPSExecution

Real execution of the process by active Celery Worker.

weaver.wps.service.check_invalid_ids(identifiers: List[str], content_type: str | None) → None

weaver.wps.service.get_pywps_service(environ: weaver.typedefs.SettingsType = None, is_worker: bool = False, process_id: str = None) → WorkerService

Generates the PyWPS Service that provides WPS-1/2 XML endpoint.

Parameters:

• environ – Environment variables containing application settings and the contextual HTTP request.

• is_worker – Hint for managing active processes against WorkerService.

• process_id – Pre-resolved Process to use, skipping loading and resolution from the database. This is typically employed when a previous WPS request occurred to identify the relevant process (i.e.: DescribeProcess), and a following Execute request.