Skip to content

Commit

Permalink
chore(concept): #436 update concept
Browse files Browse the repository at this point in the history
  • Loading branch information
ds-crehm committed Feb 15, 2024
1 parent 248ebc4 commit d03ba62
Show file tree
Hide file tree
Showing 2 changed files with 31 additions and 18 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,10 @@
# Table of Contents
1. [Overview](#overview)
2. [Requirements](#requirements)
3. [Concept](#concept)
4. [Glossary](#glossary)
5. [References](#references)
3. [Out of scope](#out-of-scope)
4. [Concept](#concept)
5. [Glossary](#glossary)
6. [References](#references)

# Overview
The standard notification status flow must be used by all applications in the Catena-X network.
Expand All @@ -23,28 +24,39 @@ The frontend must be able to display more nuanced status information, while the
- [ ] Intermediate statuses for notifications can be stored in Trace-X without affecting the standard notification flow.
- [ ] Intermediate statuses for notifications can be shown in Trace-X.
- [ ] Status flow is implemented. The transitions between statuses work.
- [ ] User manual is updated.

# Out of scope
"Forwarded" status is not yet confirmed. Concept will be adjusted depending on the decisions in https://github.com/eclipse-tractusx/sig-release/issues/385

# Concept
State machine:

| Step | Description | Resulting status shown to the user | Resulting internal status | Transition |
|-------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------|---------------------------|--------------------------------------------------------------------------------------------------------------------------|
| 1 | Notification is created. This can be done by the User manually or by forwarding an existing notification. | Queued | Created | **Manually:** Sender created a new notification <br/>**or**<br/>**Automatically:** Notification is automatically created |
| 2 | Notification is approved. | Requested | Sent | **Manually:** Sender approves notification |
| X | Sending of notification is cancelled. The notification is **not** synchronized with the receiver. Can be done by the sender at any time before the notification was successfully synchronized with the receiver. | Cancelled | Closed | **Manually:** Sender cancels the notification before it is successfully synchronized with the receiver |
| 3.1 | Notification successfully sent. The notification is synchronized with the receiver. | Received | Received | **Automatically:** After the notification is sent and Trace-X received a 201 success response |
| 3.2.1 | There was an exception during the send process. The notification is **not** synchronized with the receiver. | Exception | Received | **Automatically:** After the notification is sent and there was any exception |
| 3.2.2 | Notification is resent. | Requested | Sent | **Manually:** Sender resends notification |
| 4 | Notification is acknowledged. Status update will be sent to the sender. | Acknowledged | Acknowledged | **Manually:** Receiver acknowledges notification |
| 5.1 | Notification is accepted. Status update will be sent to the sender. | Accepted | Accepted | **Manually:** Receiver accepts notification |
| 5.2 | Notification is declined. Status update will be sent to the sender. | Declined | Declined | **Manually:** Receiver declines notification |
| 5.3.1 | Notification is forwarded. Status update will be sent to the sender. From this status the notification can be accepted or declined at any time. | Forwarded | Acknowledged | **Manually:** Receiver forwards notification |
| 5.3.2 | The notification is duplicated. The duplicate is forwarded to a new receiver. The forwarded notification will use the same state machine. The receiver becomes sender for the forwarded notification and there is a new receiver. One notification can be forwarded to multiple receivers. It can be forwarded further by any receiver. The forwarded notification(s) is/are independent of the original notification. | Forwarded | Acknowledged | **Automatically:** After the notification was duplicated |
| Y | Notification is closed. Status update will be sent to the receiver. The sender can close the notification at any time after the notification was synchronized with the receiver. | Closed | Closed | **Manually:** Sender closes notification |
![Intermediate-status-handling.png](Intermediate-status-handling.png)

| Step | Description | Resulting status shown to the user | Resulting internal status | Transition |
|-------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------|---------------------------|--------------------------------------------------------------------------------------------------------------------------------|
| 1 | Notification is created. This can be done by the User directly or by forwarding/duplicating an existing notification. | Queued | Created | **Manually:** Sender created a new notification <br/><br/>or<br/><br/>**Automatically:** Notification is automatically created |
| 2 | Notification is approved. | Requested | Sent | **Manually:** Sender approves notification |
| X | Sending of notification is cancelled. The notification is **not** synchronized with the receiver. Can be done by the sender at any time before the notification was successfully synchronized with the receiver. | Cancelled | Closed | **Manually:** Sender cancels the notification before it is successfully synchronized with the receiver |
| 3.1 | Notification successfully sent. The notification is synchronized with the receiver. | Received | Received | **Automatically:** After the notification is sent and Trace-X received a 201 success response |
| 3.2.1 | There was an exception during the send process. The notification is **not** synchronized with the receiver. | Exception | Received | **Automatically:** After the notification is sent and there was any exception |
| 3.2.2 | Notification is resent. | Requested | Sent | **Manually:** Sender resends notification |
| 4 | Notification is acknowledged. Status update will be sent to the sender. | Acknowledged | Acknowledged | **Manually:** Receiver acknowledges notification |
| 5.1 | Notification is accepted. Status update will be sent to the sender. | Accepted | Accepted | **Manually:** Receiver accepts notification |
| 5.2 | Notification is declined. Status update will be sent to the sender. | Declined | Declined | **Manually:** Receiver declines notification |
| 5.3.1 | Notification is forwarded. Status update will be sent to the sender. From this status the notification can be accepted or declined at any time. | Forwarded | Acknowledged | **Manually:** Receiver forwards notification |
| 5.3.2 | The notification is duplicated. The duplicate is forwarded to a new receiver. The forwarded notification will use the same state machine. The receiver becomes sender for the forwarded notification and there is a new receiver. One notification can be forwarded to multiple receivers. It can be forwarded further by any receiver. The forwarded notification(s) is/are independent of the original notification. | Forwarded | Acknowledged | **Automatically:** After the notification was duplicated |
| Y | Notification is closed. Status update will be sent to the receiver. The sender can close the notification at any time after the notification was synchronized with the receiver. | Closed | Closed | **Manually:** Sender closes notification |

The states must always be synchronized between sender and receiver. The transitions between synchronized states can skip one or multiple states.
This means the order of synchronized states must **not** be enforced. The message history must display enough information for both sender and receiver to understand why the status changes took place. (-> https://github.com/eclipse-tractusx/traceability-foss/issues/423)

![Intermediate-status-handling.png](Intermediate-status-handling.png)
Example A: The receiver acknowledges a notification. The status is synchronized. The notification has the state "Acknowledged" on both sides.
Now the sender closes the notification and synchronizes the state again. For the receiver the notification never had a state "Accepted"/"Declined"/"Forwarded".

Example B: The synchronization of the acknowledgement (step 4) failed. In this case the state of the notification at the sender's side will remain as "Received", while the notification is saved as "Acknowledged" in the receiver's system.
Now the receiver accepts the notification and the status switches to "Accepted". If the synchronization is then successful, the sender will receive the message that the state has changed to "Accepted". For the sender the notification was never in the state "Acknowledged" but instead skipped to the state "Accepted" directly.

# Glossary

Expand All @@ -54,3 +66,4 @@ State machine:
| | | |

# References
Notification messages: https://github.com/eclipse-tractusx/traceability-foss/issues/423
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit d03ba62

Please sign in to comment.