|
Post by sunitha on Nov 8, 2017 9:30:31 GMT
As per the EventDestination schema, while subscribing for the events, the client can send Destination, EventTypes, MessageIds and OriginResources. Here the EventTypes, MessageIds and OriginResources are the arrays.
My question is : If there are 3 members in each of these parameters, then there is 27 combinations of the event-message-resource need to be taken care. How does the server behave, if some of them are not supported. Should it respond as the subscription was a complete failure ? or report a partial failure by marking the failed combinations in the response?
|
|
|
Post by sunitha on Nov 23, 2017 6:36:21 GMT
Any thoughts from anyone ?
|
|
|
Post by Venkatesh Periyasamy on Nov 23, 2017 12:30:15 GMT
My suggestion is to respond with complete failure with the error message that what and all is not supported and remove those entries and retry the request/operation.
|
|
|
Post by mraineri on Nov 28, 2017 21:19:51 GMT
I would expect the subscription would be successful. Checking the validity of each of the combinations does not appear terribly useful and would likely over-complicate the service, especially since particular registries and resource IDs may come and go during the life of the service. It will also create a burden on the client to constantly try/fail the subscription request. When an event is generated, I would expect the service would put the event information through some matching routine for each of the event destinations, and if a match is found, it would send it to the appropriate destination. Just because a particular combination may never happen, that's okay; the client simply wants something that will never happen.
I imagine most clients likely wouldn't be providing all of those fields in the subscription request. For example, a client may simply want all events from a particular Thermal resource, regardless of the message ID or event type.
|
|
|
Post by sunitha on Nov 30, 2017 10:40:40 GMT
Thanks mraineri. I will consider the approach suggested by you. I have another question in the same line. Can you please give some hints on how the MessageId must be used in the event subscription?
|
|
|
Post by mraineri on Nov 30, 2017 12:58:30 GMT
MessageIds is an optional field in the event subscription; if a client makes a subscription request without MessageIds in the payload, then the service will send an event to the client for all MessageIds (assuming the other parameters match the subscription). However, if a client does provide MessageIds as part of the subscription request, then the service will only send events to the client that match one of the MessageIds in the subscription (also assuming the other parameters match the subscription).
|
|
|
Post by sunitha on Nov 30, 2017 13:53:40 GMT
Thank you. If i am not wrong ; during the event subscription, the message id if passed, it must be of the below pattern. Please confirm
RegistryName.MajorVersion.MinorVersion.MessageKey
|
|
|
Post by mraineri on Nov 30, 2017 15:57:38 GMT
That's correct; all MessageIds follow that format and will be in that format in the request.
|
|