search

IHE / ITI.DSUBm

Document Subscription for Mobile profile describes the use of document subscription and notification mechanisms for RESTful applications.
https://profiles.ihe.net/ITI/DSUBm/index.html
Creative Commons Attribution 4.0 International
2 stars 1 forks source link

Subscription Update Also Needed For Error Recovery #36

Closed slagesse-epic closed 12 months ago

slagesse-epic commented 1 year ago

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)

2:3.110.6

Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.

The section states:

"This message uses the HTTP PUT method on the target Resource Notification Broker endpoint to update an existing Subscription resource in order to deactivate it and unsubscribe."

However, I think this message is also needed to re-activate a subscription that has been deactivated due to errors.

Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.

Allow using the Update Subscription message to re-activate errored subscriptions.

Priority:

gpavan19 commented 1 year ago

The purpose of the update now is only to deactivate the subscription.

This issue could be related to the #37 and DSUBm_004 about managing the errors.

The Resource Notification Subscriber shall always perform another subscription by posting a Subscription Resource with the same creteria when a Subscription goes in error or goes off.

Further, if the Resource Notification Broker continues to try sending notification even in "error" status, the reacivation is not necessary until the Subscription goes off. Then again the Resource Notification Subscriber shall always perform another subscription.

slagesse-epic commented 1 year ago

This goes against the recommendation of the Recovering from Errors section of the backport IG.

"Once an application has returned to a functional state, it should request the subscription is reactivated by updating the status to either requested or active as appropriate."

gpavan19 commented 1 year ago

I think it is not a mandate, but it is a "should". So I think it is not againts.

But I can understand that could be usefull.

We can integrate it considering only the update with status to "requested" so that the Resource Notification Broker shall perform the handshake to verify the connection befor effectivelly reactivate the Subscription (as in the Subscription creation).

Does it fit for you? @slagesse-epic

slagesse-epic commented 1 year ago

Yes, that sounds good to me.