Support for a Business Process to Notify consumers of negotiated contracts

[SebastianOpriel]

We face a challenge, which on a business process level needs to be handled on a business process layer. We need to notify data consumers about availability of datasets' source systems about

• planned downtimes,
• planned deprecation or
• emergency suspensions.

Specific examples, which might be generalized:

• Stopping a data offering: A provider might face a leakage of data, e.g. because an offered API "suddenly" offers sensitive or additional data, which were not intended. The provider needs somehow an "emergency halt" sequence. Sure this will be possible, by provider's IT department, simply restricting access to the specific API for a DPSPACE-protocol implementing software. Nevertheless, consumers shall be notified about the incident. Currently a business process might rely on additional information in a datasets DCAT information.
• Announcement of shutting down source systems: In case a consumer has negotiated a contract which's validity will span a long time (which is intended for a consumer, to rely on the availability of the data for integration into own services), and the provider is not able to provide the API from a specific future date in the future, the consumer must be notifiable.

Solution ideas to provide consumer's contact details (e.g. email address):

• Dataspace Authority Portal offers possibility to identify a connectors organization
• SSI / DAPS-DAT provide further information

@PeterKoen-MSFT Could you please take that to Best Practices document of @ssteinbuss ?

[jimmarino]

I think we already discussed this. Notifications do not need to be first-class concepts in the DSP as they can be modeled as a streaming Dataset and delivered over a pub/sub data transfer protocol.

[ssteinbuss]

Discuss this in the best practices document and shape the problem and potential solution there.

We need to check if the scope of this is really the DSP or something else.