547 convers the epic of supporting send conditions in notifications. A part of this is to evaluate the send condition using the condition during the processing of an order to decide if a notification should be sent or not.
The scope of this issue is to validate, accept/deny and persist the send condition endpoint along with the notification order.
Specification
Questions:
could a dialogue be read and deleted before the requested send time? if so what would the response of the send condition endpoint be? Strongly linked to dialogue element or to a persistent log?
Should condition be evaluated before or after a notification is generated?
To be more specific, if the send condition fails is the notification generated at all ? And if not, does the creator need to be made aware that the send condition failed? Is this then persisted in the order status?
If a notification IS NOT generated when condition fails
ACCEPTED Solution: We could consider adding a new status to the OrderProcessing status currently holds values Registered, Processing, Completed. We could add SendConditionNotMet.
Pros:
We limit the logic to the orderprocessing never involving the notification creation logic.
Cons:
The SendConditionNotMet as a part of the orderProcessingStatus this seems a bit unrelated to the actual processing of the order.
If a notification IS generated when condition fails
Solution: we could have a decorator shared between all order processing to lookup send condition to avoid duplication. Handling the buypass of lookup and going directly to generation of notification would need to be handled somehow. This is a need both with the decorator solution and not.
Pros:
We can add the status to the email and sms notificationResultType as SendConditionNotMet. A benefit of this solution is that it is explicit for the creator of the notification that send condition was not met.
Cons:
Recipient lookup. But we could in this case avoid the lookup if we know send condition is not met, and only reference the user with the provided organization or national identity number.
Metrics. Currently we count each notification being generated as something that needs to be billed. For SMS we can solve it by setting the count to 0, but for emails each generated notification is counted a billable email. We could tweak the script to not count notifications where send condition has not been met.
How are errors during condition lookups handled?
Fail fast
Pros:
No retry count to persists.
Cons:
Notifications that should be sent are not sent.
If error is fixed we might be required to manually trigger processing again.
Retry
Pros:
could be a passing error and a retry would fix the issue.
Cons:
at some point we stop retry and the problem with the endpoint might still not be fixed. Retries will then just prolong the processing of an issue.
Manual intervention and responsibilities
How do we want to split responsibility here. If service owner provides an endpoint (even via Dialogporten) they should be responsible for ensuring the endpoint is available. However, does Altinn have a responsibility to monitor the failures her and report back to them or do we simply register the failure on the order/notification as SendConditionEvaluationFailed or SendConditionNotEvaluated?
Do we need to manually re-set order status on error or can we expect the creator to place a new order?
Accepted solution
Condition is evaluated before notifications are generated.
negative condition check is persisted to ProcessingStatus. SendConditionNotMet
Condition check is retried once using a retry topic
If condition check fails due to error after x retries, notification is sent.
Retry hooked up to existing retry mechanisms with topic altinn.notifications.orders.pastdue.retry
Tasks
[x] Add business logic to handle condition checks
[x] Unit tests
[x] Review (QA)
[x] Manual tests
[x] Documentation
Acceptance Criterias
[x] When condition is not satisfied, the order is not processed. Status is updated to be SendConditionNotMet
[x] When condition is satisfied the order is processed and notifications are produced and sent.
[x] When condition check fails the order processing is retried
[x] When a condition check retry fails a second time, the order is processed and the notifications are sent.
Description
547 convers the epic of supporting send conditions in notifications. A part of this is to evaluate the send condition using the condition during the processing of an order to decide if a notification should be sent or not.
The scope of this issue is to validate, accept/deny and persist the send condition endpoint along with the notification order.
Specification
Questions:
could a dialogue be read and deleted before the requested send time? if so what would the response of the send condition endpoint be? Strongly linked to dialogue element or to a persistent log?
Should condition be evaluated before or after a notification is generated?
To be more specific, if the send condition fails is the notification generated at all ? And if not, does the creator need to be made aware that the send condition failed? Is this then persisted in the order status?
If a notification IS NOT generated when condition fails
ACCEPTED Solution: We could consider adding a new status to the OrderProcessing status currently holds values Registered, Processing, Completed. We could add
SendConditionNotMet.Pros:
Cons:
If a notification IS generated when condition fails Solution: we could have a decorator shared between all order processing to lookup send condition to avoid duplication. Handling the buypass of lookup and going directly to generation of notification would need to be handled somehow. This is a need both with the decorator solution and not.
Pros:
SendConditionNotMet. A benefit of this solution is that it is explicit for the creator of the notification that send condition was not met.Cons:
How are errors during condition lookups handled?
Fail fast
Pros:
Cons:
Retry
Pros:
Cons:
Manual intervention and responsibilities How do we want to split responsibility here. If service owner provides an endpoint (even via Dialogporten) they should be responsible for ensuring the endpoint is available. However, does Altinn have a responsibility to monitor the failures her and report back to them or do we simply register the failure on the order/notification as
SendConditionEvaluationFailedorSendConditionNotEvaluated?Do we need to manually re-set order status on error or can we expect the creator to place a new order?
Accepted solution
SendConditionNotMetTasks
Acceptance Criterias
SendConditionNotMet