Echo process and OGC API Processes validation

[ChristianBeilschmidt]

• I agree to follow the project's code of conduct.
• I added an entry to the project's change log file if knowledge of this change could be valuable to users.
  • Usually called CHANGES.md or CHANGELOG.md
  • Prefix changelog entries for breaking changes with "BREAKING: "

---

The goal is to have the echo process for OGC API Processes that is described here:
https://docs.ogc.org/is/18-062r2/18-062r2.html#_443805da-dfcc-84bd-1820-4a41a69f629a

Moreover, I added a CI test that uses the OGC CITE validator for OGC API Processes.
It fails currently, obviously, but the validation job itself works.

Here are the Java implementations of the tests: https://github.com/opengeospatial/ets-ogcapi-processes10/blob/75abd1f37fc3aad95163fdce2e33e393b1ba5a88/src/main/java/org/opengis/cite/ogcapiprocesses10/jobs/Jobs.java#L1296

[b4l]

@ChristianBeilschmidt I pushed some fixes, hope you don't mind. Some types/schemas were wrong. I think there are more mistakes; some originate from before the official release of the standard.

[ChristianBeilschmidt]

@ChristianBeilschmidt I pushed some fixes, hope you don't mind. Some types/schemas were wrong. I think there are more mistakes; some originate from before the official release of the standard.

Thank you very much!

We are currently at 36 passed tests, 12 failed and 6 skipped.

From what I see, most errors come from two parts:

1. Allow types with multiple outputs.
2. Allow creating jobs and querying their status and results.

How would you put this into the library's design?

For 1., I saw

let exeption = Exception::new_from_status(status.as_u16())
                        .detail("Multiple raw outputs as multipart/related not implemented yet!");

in the code. But I'm not sure this is it.

For 2., I guess we have to listen to header values

request.setHeader("Prefer", "respond-async ");

. The job lists are there, but are currently not filled.
I guess if these two things are tackled, the rest is fine tuning.

[b4l]

How would you put this into the library's design?

For 1., we probably have to compose a (streaming) body conforming to multipart/related by ourselves (https://www.ietf.org/rfc/rfc2387.txt)

For 2., extracting the Prefer header and acting upon it seems the way to go. This might require some sort of job runner/manager to run the job outside the request. Maybe we can just start by spawning a process/task for that with a provided execute_async function on the Processor trait.

[ChristianBeilschmidt]

I for now removed async and ref from the supported modes to at least get the server right for sync and value.

Luckily, there is a certified compliant instance out there with https://maps.gnosis.earth/ogcapi/processes/echo. This helps in understanding what went wrong.

However, I cannot get my head around the error on test Job Creation Op, yet.

Detail	Value
Test Name	test Job Creation Op
Test Result	FAILED ❌
Test Description	Implements Requirement /req/core/job-creation-op Details ↗ Class Name: Jobs Method Name: testJobCreationOp Path: org/opengis/cite/ogcapiprocesses10/jobs/Jobs

Test Request
Method: POST
URL: POST http://localhost:8484//processes/echo/execution HTTP/1.1
Body:

{
  "inputs" : {
    "stringInput" : "teststring"
  },
  "outputs" : {
    "stringOutput" : {
      "transmissionMode" : "value"
    }
  }
}

Test Outputs

<cnt:rest>teststring</cnt:rest>

Reason of Failure

java.lang.AssertionError: Unrecognized token 'teststring': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false')
at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 11]

[b4l]

Well, CITE has its limits. Reason of Failure: Content type 'text/plain' is not allowed for body content. (code: 203) . I guess we can ignore this for now.

[ChristianBeilschmidt]

Ok, I cleaned the CI up and added an option to ignore failed tests (and not fail the CI).
From what I've seen, you can be standards-compliant by not implementing the async stuff. However, the failing tests are still dubious.

I guess I will try to use the API as is and, in parallel to this, think about adding some async stuff.

[ChristianBeilschmidt]

@b4l I guess it now works and has a decent structure. Maybe you can review it.

[b4l]

@ChristianBeilschmidt Thank you! I think this is a big step forward. Just some general remarks and nits. Nothing blocking, rather like to land this and address things in follow-ups. A changelog entry would be nice, though.

[ChristianBeilschmidt]

@b4l I addressed your review comments

[b4l]

Just some questions about artifacts, the rest looks good.