Currently the notification service has a single endpoint that just describes, very particularly, what message to send.
This should be improved so that the Notification services responsibilities are:
to determine how a user may be notified, and which channel they prefer (e.g. SMS over email, or just SMS, or only email).
to queue messages for sending (this would also support a use case where we only send between 9am-5pm)
To do this we'll change the endpoint to be:
the userid of the person to notify so that we can lookup email address, phone number, etc
a dictionary of messages to send. The key of this dictionary is a channel (e.g. "email", "sms", etc) and the value is the message to send in 2 parts: subject and body. The subject and body are defined in the Service's Resource Property bundle (along with all the other translatable message keys) and should arrive at the notification service with any needed message parameters already substituted.
The response to POST to this endpoint should generally be a 202 - indicating an async endpoint. The body should include a field for "notificationQueueId" which is a UUID of an endpoint we'll build later in OLMIS-2270. For now this endpoint may still be synchronous, and the other endpoint may be built in the future.
A 400 status may be returned if the format of the body doesn't make sense. 401 if the token is invalid. 403 if the token isn't a service level token.
Acceptance criteria:
the "from" field is removed from the body of the endpoint /api/notification. Instead this service should source the one system-wide setting of the from address from the environment, which will come from the .env file.
the body of the endpoint /api/notificiation takes in a dictionary of which the value is the message to send (e.g. "hello you need to do blah...") and the key is the channel (e.g. SMS, email, IVR, in-app, etc). See example above. Only 1 message may be given per channel, and at-least one-channel with message must be given.
When a Service wants to send a message, it ideally will give all the messages it knows of for all channels it has translations for to this endpoint, and the Notification service will be responsible for choosing which message(s) to actually send by channel(s) based on the user profile configuration in Reference Data. (this isn't an action item as of yet)
the "to" field in the body of the endpoint /api/notification is a user's UUID.
notifications are stored in a table for future reference - in the future this will be turned into a queue.
client services are refactored to support the change to this endpoint
I have double checked all of the acceptance criteria is handled in the tickets in the epic OLMIS-4902, so moving this to Dead.
Brandon Bowersox-Johnson April 24, 2017 at 7:13 PM
Okay, I also moved it from 3.0.2 and 3.1 fixVersion (and I put a note on the Backlog Grooming Sprint 25 wiki).
Paweł Gesek April 20, 2017 at 8:55 AM
Ok, in that case I moving this out of the sprint
Brandon Bowersox-Johnson April 20, 2017 at 12:49 AM
Edited
I agree that we don't need to do this ticket for 3.0.1. And I agree with Mary Jo that if we have any extra capacity, there are a few bugs that are small and more important than trying to do this redesign.
(And I see that all the work-in-progress was pushed on a branch called OLMIS-1751, nothing on Master.)
Mary Jo Kochendorfer April 19, 2017 at 4:59 PM
Edited
I'm okay with this AND I'd love for more bugs to be picked up.
Won't Fix
Pinned fields
Click on the next to a field label to start pinning.
Currently the notification service has a single endpoint that just describes, very particularly, what message to send.
This should be improved so that the Notification services responsibilities are:
to determine how a user may be notified, and which channel they prefer (e.g. SMS over email, or just SMS, or only email).
to queue messages for sending (this would also support a use case where we only send between 9am-5pm)
To do this we'll change the endpoint to be:
the userid of the person to notify so that we can lookup email address, phone number, etc
a dictionary of messages to send. The key of this dictionary is a channel (e.g. "email", "sms", etc) and the value is the message to send in 2 parts: subject and body. The subject and body are defined in the Service's Resource Property bundle (along with all the other translatable message keys) and should arrive at the notification service with any needed message parameters already substituted.
The response to POST to this endpoint should generally be a 202 - indicating an async endpoint. The body should include a field for "notificationQueueId" which is a UUID of an endpoint we'll build later in OLMIS-2270. For now this endpoint may still be synchronous, and the other endpoint may be built in the future.
A 400 status may be returned if the format of the body doesn't make sense. 401 if the token is invalid. 403 if the token isn't a service level token.
Acceptance criteria:
the "from" field is removed from the body of the endpoint /api/notification. Instead this service should source the one system-wide setting of the from address from the environment, which will come from the .env file.
the body of the endpoint /api/notificiation takes in a dictionary of which the value is the message to send (e.g. "hello you need to do blah...") and the key is the channel (e.g. SMS, email, IVR, in-app, etc). See example above. Only 1 message may be given per channel, and at-least one-channel with message must be given.
When a Service wants to send a message, it ideally will give all the messages it knows of for all channels it has translations for to this endpoint, and the Notification service will be responsible for choosing which message(s) to actually send by channel(s) based on the user profile configuration in Reference Data. (this isn't an action item as of yet)
the "to" field in the body of the endpoint /api/notification is a user's UUID.
notifications are stored in a table for future reference - in the future this will be turned into a queue.
client services are refactored to support the change to this endpoint
RAML is updated, documentation, tests, etc