NFVSOL(25)000411r1_SOL026_Clause_9_Sequence_Diagrams

**Figure 6.4.4-1: Flow of Computer System modification**

The modification of an individual Computer System resource, as illustrated in Figure 6.4.41, consists of the following steps.

The modification of an individual Computer System resource, as illustrated in Figure 6.4.4-1, consists of the following steps.

The modification of an individual Computer System resource, as illustrated in Figure 6.4.4-1, consists of the following steps.

**Precondition:** The individual Computer System resource has been previously created.

**Figure 8.4.4-1: Flow of topology object modification**

The modification of a topology object, as illustrated in Figure 8.4.41, consists of the following steps.

The modification of a topology object, as illustrated in Figure 8.4.4-1, consists of the following steps.

The modification of a topology object, as illustrated in Figure 8.4.4-1, consists of the following steps.

**Precondition:** The individual topology object has been previously created.

Table 9.3-1 lists the API resources, and the applicable HTTP methods for each resource endpoint.

The HTTP methods marked as "M" (mandatory) in the "Cat" column of table 9.3-1 shall be supported by the PIM. The HTTP methods marked as "O" (optional) in the "Cat" column may be optionally supported by the PIM.

The HTTP methods marked as "M" (mandatory) in the "Cat" column of table 9.3-1 shall be supported by the PIM. The HTTP methods marked as "O" (optional) in the "Cat" column may be optionally supported by the PIM. The HTTP methods marked as "CM" (conditional mandatory) shall be supported by the PIM depending on the corresponding condition.

The HTTP methods marked as "M" (mandatory) in the "Cat" column of table 9.3-1 shall be supported by the PIM. The HTTP methods marked as "O" (optional) in the "Cat" column may be optionally supported by the PIM. The HTTP methods marked as "CM" (conditional mandatory) shall be supported by the PIM depending on the corresponding condition.

**Table 9.3-1: API Resources and HTTP methods of physical resource performance management service interface**<a name="table_9.3-1"></a>

|                         |                                 |DELETE           |M         |Delete an "Individual Subscription" resource.             |

+-------------------------+---------------------------------+-----------------+----------+----------------------------------------------------------+

|Notification endpoint    |{NotificationTargetURI}          |POST             |M         |Send a notification related to                            |

|                         |                                 |                 |          |a subscribed event (see note).                            |

|                         |                                 |                 |          |a subscribed event (see note 1).                          |

|                         |                                 |                 |          |Can also be used to send a performance                    |

|                         |                                 |                 |          |report asynchronously (see note 2).                       |

|                         |                                 |                 |          |a subscribed event (see note 1).                          |

|                         |                                 |                 |          |Can also be used to send a performance                    |

|                         |                                 |                 |          |report asynchronously (see note 2).                       |

+-------------------------+---------------------------------+-----------------+----------+----------------------------------------------------------+

|Individual Task Monitor  |/redfish/v1/TaskService\         |GET              |CM        |Enable API consumer to monitor the                        |

|                         |/TaskMonitors/{TaskMonitorId}    |                 |          |progress of an asynchronous operation                     |

|                         |(see note 3)                     |                 |          |as well as receive the result of the requested            |

|                         |                                 |                 |          |operation once the corresponding task has been completed. |

|                         |                                 |                 |          |This resource endpoint shall be supported                 |

|                         |                                 |                 |          |if the API producer supports asynchronous operations.     |

+-------------------------+---------------------------------+-----------------+----------+----------------------------------------------------------+

|NOTE: Notification endpoint resource and the corresponding NotficiationTargetURI                                                                   |

|NOTE 1: Notification endpoint resource and the corresponding NotficiationTargetURI                                                                 |

|is used by the API producer to send notifications to the API consumer.                                                                             |

|This resource is not produced by the API producer.                                                                                                 |

|NOTE 2: See clause 9.4.8 for the flow related to the API consumers receiving                                                                       |

|performance reports asynchronously as notifications.                                            .                                                  |

|NOTE 3: The URI of the task monitor is provided in the Location header                                                                             |

|of the HTTP response to the API consumer when the API producer returns a "202 Accepted" response.                                                  |

|NOTE 2: See clause 9.4.8 for the flow related to the API consumers receiving                                                                       |

|performance reports asynchronously as notifications.                                            .                                                  |

|NOTE 3: The URI of the task monitor is provided in the Location header                                                                             |

|of the HTTP response to the API consumer when the API producer returns a "202 Accepted" response.                                                  |

+---------------------------------------------------------------------------------------------------------------------------------------------------+

## 9.4    Sequence diagrams (informative)

### 9.4.1    Introduction

The sequence diagrams provided in the subsequent sub-clauses are generalized to indicate management of a generic performance management (PM) related object, which refers to either PmJob or Threshold specified in clause 5 of the present document. These diagrams and their description contain placeholders such as <PM object collection URI>, <PM object URI> and <PM object>, which correspond to the appropriate resource URIs and PM-related objects specified in clauses 9.3 and 5.4 respectively.

Sequence diagrams related to retrieval of performance reports do not contain generic placeholders. Specific resource URIs and object names are used in those sequence diagrams. 

Flows related to task monitoring, subscription management and notifications are described in Annex A of the present document.

### 9.4.2    Creation of a PM object

This clause describes a sequence for creating an individual resource corresponding to a PM object.

![Figure 9.4.2-1: Flow of PM object creation](media/image25.png)

**Figure 9.4.2-1: Flow of PM object creation**

The creation of a PM object, as illustrated in Figure 9.4.2-1, consists of the following steps.

**Precondition:** None.

1. The API consumer sends a POST request to the <PM object collection URI> including a valid <PM object> representation in the message content body.

1. If the PIM supports asynchronous operations and creation of the PM object resource requires some time to process, the PIM returns a "202 Accepted" response. The response also contains the URI of the associated Task Monitor in the Location header. The response body can optionally contain representation of the corresponding Task resource created by the PIM for this asynchronous operation.

1. The PIM creates an individual PM object.

1. The PIM returns a "201 Created" response to the API consumer and includes in the message content body a representation of the created PM object. The response also contains the URI of the newly created PM object in the Location header.

**Postcondition:** Upon successful completion of the synchronous operation or of the corresponding task in case of asynchronous operation, the individual PM object has been created.

**Error handling:** In case of failure, appropriate error information is provided in the response.

### 9.4.3    Querying information about PM objects

This clause describes the sequences for querying information about multiple and individual PM objects.

![Figure 9.4.3-1: Flow of querying information about PM objects](media/image26.png)

**Figure 9.4.3-1: Flow of querying information about PM objects**

The querying of information about one or more PM objects, as illustrated in Figure 9.4.3-1, consists of the following steps.

**Precondition:** One or more individual PM objects have previously been created.

1. If the API consumer intends to get information about multiple PM objects, it sends a GET request to the <PM object collection URI>.

1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of a <PM object collection>, containing information about all the individual PM objects that have been created.

1. If the API consumer intends to get information about an individual PM object, it sends a GET request to the <PM object URI>.

1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of the individual PM object.

**Postcondition:** None.

**Error handling:** In case of failure, appropriate error information is provided in the response.

### 9.4.4    Modifying a PM object

This clause describes a sequence for modifying an individual PM object.

![Figure 9.4.4-1: Flow of PM object modification](media/image27.png)

**Figure 9.4.4-1: Flow of PM object modification**

The modification of a PM object, as illustrated in Figure 9.4.4-1, consists of the following steps.

**Precondition:** The individual PM object has been previously created.

1. The API consumer sends a PATCH request to the <PM object URI>, including data structure in the message content body representing the modifiable properties to be modified in the individual PM object.

1. If the PIM supports asynchronous operations and modification of the PM object requires some time to process, the PIM returns a "202 Accepted" response. The response also contains the URI of the associated Task Monitor in the Location header. The response body can optionally contain representation of the corresponding Task resource created by the PIM for this asynchronous operation.

1. The PIM modifies the individual PM object.

1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of the modified PM object. Alternatively, the PIM can also return a "204 No Content" response to the API consumer indicating successful operation.

**Postcondition:** Upon successful completion of the synchronous operation or of the corresponding task in case of asynchronous operation, the individual PM object has been modified.

**Error handling:** In case of failure, appropriate error information is provided in the response.

### 9.4.5    Replacing a PM object

This clause describes a sequence for replacing an individual PM object.

![Figure 9.4.5-1: Flow of PM object replacement](media/image28.png)

**Figure 9.4.5-1: Flow of PM object replacement**

The replacement of an individual PM object, as illustrated in Figure 9.4.5-1, consists of the following steps.

**Precondition:** The individual PM object has been previously created.

1. The API consumer sends a PUT request to the <PM object URI> including a valid representation of the individual PM object to be replaced in the message content body.

1. If the PIM supports asynchronous operations and replacement of the PM object requires some time to process, the PIM returns a "202 Accepted" response. The response also contains the URI of the associated Task Monitor in the Location header. The response body can optionally contain representation of the corresponding Task resource created by the PIM for this asynchronous operation.

1. The PIM replaces the individual PM object.

1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of the replaced PM object. Alternatively, the PIM can also return a "204 No Content" response to the API consumer indicating successful operation.

**Postcondition:** Upon successful completion of the synchronous operation or of the corresponding task in case of asynchronous operation, the individual PM object has been replaced.

**Error handling:** In case of failure, appropriate error information is provided in the response.

### 9.4.6    Deleting a PM object

This clause describes a sequence for deleting an individual PM object.

![Figure 9.4.6-1: Flow of PM object deletion](media/image29.png)

**Figure 9.4.6-1: Flow of PM object deletion**

The deletion of an individual PM object, as illustrated in Figure 9.4.6-1, consists of the following steps.

**Precondition:** The individual PM object has been previously created.

1. The API consumer sends a DELETE request to the <PM object URI>.

1. If the PIM supports asynchronous operations and deletion of the PM object requires some time to process, the PIM returns a "202 Accepted" response. The response also contains the URI of the associated Task Monitor in the Location header. The response body can optionally contain representation of the corresponding Task resource created by the PIM for this asynchronous operation.

1. The PIM deletes the individual PM object.

1. The PIM returns a "204 No Content " response to the API consumer indicating that the PM object has been successfully deleted. Alternatively, the PIM can also return a "200 OK" response to the API consumer including a representation of the deleted PM object in the message content body.

**Postcondition:** Upon successful completion of the synchronous operation or of the corresponding task in case of asynchronous operation, the individual PM object has been deleted.

**Error handling:** In case of failure, appropriate error information is provided in the response.

### 9.4.7    Retrieving performance reports

This clause describes the sequence for querying information about multiple and individual performance reports.

![Figure 9.4.7-1: Flow of querying information about performance reports](media/image30.png)

**Figure 9.4.7-1: Flow of querying information about performance reports**

The querying of information about one or more performance reports, as illustrated in Figure 9.4.7-1, consists of the following steps.

**Precondition:** One or more individual performance reports have previously been generated by the PIM.

1. If the API consumer intends to get information about multiple performance reports, it sends a GET request to the performance reports URI.

1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of a collection of performance reports, containing information about all the individual performance reports that have been generated.

1. If the API consumer intends to get information about an individual performance report, it sends a GET request to the URI representing individual performance report.

1. The PIM returns a "200 OK" response to the API consumer and includes in the message content body a representation of the individual performance report.

**Postcondition:** None.

**Error handling:** In case of failure, appropriate error information is provided in the response.

### 9.4.8 Receiving performance reports asynchronously

This clause describes the sequence for receiving performance reports asynchrnously as notifications.

![Figure 9.4.8-1: Flow of receiving performance reports as notifications](media/image31.png)

**Figure 9.4.8-1: Flow of receiving performance reports as notifications**

The procedure consists of the following steps as illustrated in figure 9.4.8-1.

**Precondition:** The API consumer has previously created a subscription containing a PmJob to receive performance reports asynchronously.

1. When generating a performance report according to the configured PmJob (*MetricReportDefinition*) as part of the created subscription, an event of type *MetricReport* gets triggered. As a result of this, the PIM generates a notification that includes the performance report and sends it in the body of a POST request to the notification target URI which the API consumer had registered as part of the subscription request.

<<<<<<< HEAD

## 9.5    Resources

### 9.5.1    Introduction

## 9.6    Data model

The request and response data structures of the physical resource performance management service interface are defined in the Redfish® data model specification [\[3\]](#_ref_3).

=======

**Postcondition:** None.

**Error handling:** None.

>>>>>>> 8d782de (add postcondition and error handling fields in notification related flows)

# 10 Physical resource fault management service interface

1. If an event occurs that matches the eventing criteria which are part of the subscription, the PIM generates a notification that includes information about the event and sends it in the body of a POST request to the notification target URI which the API consumer had registered as part of the subscription request.

**Postcondition:** None.

**Error handling:** None.

Editor's Note:    To further check in Redfish interface specs and potentially with DMTF Redfish experts about the standard response (if any) from API consumer when it receives a notification from Redfish event service.

## A.4 Flow of monitoring tasks related to asynchronous operations (polling method)