search

eiffel-community / eiffel-remrem-publish

eiffel-remrem-publish
https://eiffel-community.github.io/eiffel-remrem-publish
Apache License 2.0
8 stars 77 forks source link

Policy/Custom based REMReM #235

Open elebroerik opened 2 years ago

elebroerik commented 2 years ago

Description

New feature. REMReM to validate events based on customer schemas. The preferred solution is to use REMRem to publish and validate the event. The idea is that REMRem will not publish anything that is not according to schema.

Motivation

Today, we don’t know what data is sent in the Eiffel events. To find out, we need to go down to code level and investigate each tool that send events. And making confluence pages and Excel documents about what data is published by each tool/event is not a sustainable solution (those lists will always be obsolete). We need schemas that enforce the data, and the single contact of publishing events is (or should be) REMRem. Therefore, the validation functionality should be placed in REMRem.

Exemplification

Requests: Req-1. As an Eiffel event sender application in the Product Production System (note 1) I want to add Eiffel event data validation functionality to REMRem So I can insert schemas into my events, So the events are validated with respect to the schema, before they are published, So event consumers receive more correct and accurate Eiffel Messages. Note1:

Req-2. As an Eiffel event sender application in the Product Production System I want to be able to define my own validation procedure as a plugin to REMRem, So if the validation procedure need to change, there will be no need to redeliver or update REMRem.

Req-3.

  1. The eventData.optionalParameters.eventSchemaUrl parameter contains a schema link that shall be used to validate the event.

  2. If the eventSchemaUrl parameter empty or missing, no validation need to take place, before sending the Eiffel event.

  3. If the eventSchemaUrl parameter is not a valid HTTP link, or can’t be accessed, THEN

  4. eventSchemaUrl parameter shall be removed from the event (indicating that no validation is done)

  5. the Eiffel Event shall be sent

  6. return 214 Transformation Applied to the user

  7. If the link can be accesses, the content returned from GET shall be treated as a JSON schema.

  8. The whole event shall be validated towards that schema

  9. If the validation fails, a 422 Unprocessable Entity shall be returned, and the Eiffel Event shall not be sent.

  10. If the validation succeeds, a 200 OK shall be returned and the Eiffel Event shall be sent.

To ensure compatibility with upcoming Eiffel Protocol the following changes to the previous version of Eiffel protocol is proposed:

  1. Introduce a URL field in "eventData.optionalParameters.eventSchemaUrl" as proposed.
  2. Introduce a new URI field in "eventData.optionalParameters.eventSchemaUri" containing a IDENTIFIER of the schema.
  3. The URI schema field is expected to consist of the same URI as the upcoming counterpart in Eiffel protocol. This will enable the Eiffel Translator to easily translate between protocols with respect to schema validation. Of course, Eiffel protocol will need a dynamic mechanism to resolve the URI into a URL. This will be proposed by making a new event that can be emitted and follow the schema URL entity life cycle.

Benefits

Better traceability of what data has been sent.

Possible Drawbacks

Not aware of any.

m-linner-ericsson commented 2 years ago

This ticket is probably dependent on https://github.com/eiffel-community/eiffel/issues/280