SebastianOpriel
commented
7 months ago Subscription: Cron-triggered
- [ ] UI: Start Interval Based Data Transfer
- [ ] Either custom DB Entity
- [ ] or custom Transfer Type (but how do we prevent them from being handed to the DP)
- [ ] Needs to support full range of transfer types
- [ ] Opportunity: Clean / aggregate old transfers
- [ ] Quartz: Dynamic Schedules
- [ ] Restart after Connector Startup
Subscription: On update notify
- [ ] Architecture
- [ ] Note: Catena had a custom notification endpoint, maybe re-use that?
- [ ] Idea: Receive calls "onUpdate"
- [ ] Would require same tables as previous solution
- [ ] SUM: Opportunity: "Persistable Data Sinks", could be managed as such, would require CRUD UI
- [ ] List Endpoint
- [ ] List UI
- [ ] Delete Dialog
- [ ] Delete Endpoint
- [ ] Create Endpoint
- [ ] Create Form
- [ ] Selection in Transfer Dialog
- [ ] Flag: Supports Update Push. Display for assets, Create in Form, Add to API Wrapper
- [ ] Source: Flag data as updated action, as button for assets, API Wrapper endpoint, UI: Button in UI on provider side on the asset
- [ ] Notification receiving, automated transferring: Custom DB Table, these are not "transfers" but transfer plans. Create transfers
Feature Request
https://github.com/Mobility-Data-Space/MDS-Project/issues/65
Business value
How does this tie into the current product?
After successful contract negotiation the consumer intends to consume data. Among current functionalities he have a possibility to "subscribe" for a data offer. For this subscription he can choose between push and pull methods. If "push" is selected he shall get data immediately after the data are available on the provider side. If "pull" is selected he can define a request frequency. More than one subscription per offer shall be allowed. Subscriptions shall be represented as list and be manageable within the connector.
Outlook
TBD
(For sovity Team to complete) Stakeholders
Add more on who asked for this, i.e. company, person, how much they pay us, what their tier is, are they a strategic account, etc. Who needs to be kept up-to-date about this feature?
User stories
As consumer I want to have a possibility to subscribe for the push delivery to make my service more efficient and avoid any time delay. As provider I want to understand the push subscription to ensure the data delivery from the backend without any time delay. As consumer I want to have a possibility to subscribe for the continuous pull delivery and define the request frequency. More than one subscription per data offer is allowed. As consumer I want to see all subscirptions as manageable list to have possibility to delete, edit request frequency etc.
(For sovity Team to complete) Solution Proposal and Work Breakdown
--------------- MDS format for initial inspection---------- https://github.com/Mobility-Data-Space/MDS-Project/issues/65
Background
Background
Problem statement
In its current state, the UI implementation allows users to start data transfers using the "transfer-button" on a contract. This function lets users choose where to send the data. However, it's limited to one-off transfers, whereas real-world situations often need ongoing data exchange, either through push or pull methods.
In a push scenario, updates in the provider database should notify the consumer about new events, like emergency alerts. Otherwise, in a pull scenario, users might need data on a regular basis, e.g. every 5 minutes.
Currently, to enable continuous pull requests, users have to use the connector API along with an extra script (e.g. Python). This means you need to be good at scripting and understand how connectors work to implement practical use cases. Unfortunately, a push mechanism isn't available yet.
Customer perspective
Implementing this feature would significantly enhance the usability of the connector via the UI. Currently, setting up continuous data transfers through the connector API involves reading extensive documentation, modifying, or creating automation scripts to fit specific use cases, and finding deployment options.
Introducing the ability to initiate data transfers at user-defined time intervals or even through a push mechanism would empower connector users who lack API knowledge or scripting skills to take full advantage of the connector's functionality and set up real-time data exchange directly through the UI.
This feature not only adds usability value to the connector but also eliminates the need for time-consuming script implementations and the involvement of technical experts. Additionally, it facilitates quick test setups, streamlining the overall process.
Business value
Proposed solution
Description of the feature
After successful contract negotiation the consumer intends to consume data. Among current functionalities he have a possibility to "subscribe" for a data offer. For this subscription he can choose between push and pull methods. If "push" is selected he shall get data immediately after the data are available on the provider side. If "pull" is selected he can define a request frequency. More than one subsciption per offer shall be allowed. Subscriptions shall be represented as list and be manageable within the connector.
Dependencies
Not Known
Suggested visual realization
TBD
Challenges
TBD
User stories
As consumer I want to have a possibility to subscribe for the push delivery to make my service more efficient and avoid any time delay. As provider I want to understand the push subscription to ensure the data delivery from the backend without any time delay. As consumer I want to have a possibility to subscribe for the continuous pull delivery and define the request frequency. More than one subscription per data offer is allowed. As consumer I want to see all subscirptions as manageable list to have possibility to delete, edit request frequency etc.
Outlook
TBD
Comments
This refers to two different features:
Thus, I suggest to split those topics (even though the rationale might be similar)
I do not understand how both described features could help here to gain this advantage.
I think the title is not precise enough, since subscription might lack another object like "subscribe for data updates"
You mean per contract on consumer side, right? Or is the requirement only, that a data provider shall be able to offer the subscription logic to multiple receipients?
How does this requirement help the user? Why not simply implementing it as a list inside a contract details view? Maybe in the contract overview we could add an icon for subscription or interval transfer.