Operation Request - Submit Operation Response - SubmitResponse

Co Table 31 – StatusReport usage for different state transitions of a Submit request task is in execution task is already completed 1 task is in execution task is already completed 1 task 1 estimatedT oC 0..1 NA optional NA NA optional NA NA NA event code 0..1 NA TaskSub mitted TaskComp leted NA TaskSub mitted TaskCom pleted NA TaskingRe questExpir ed percentCo mpletion 0..1 NA 100 NA 100 NA NA procedure 1 requestStat us code 1 Pending Accepted Accepted Rejected Accepted Accepted Rejected Rejected statusMes sage 0.. taskingPar ameters 0..1 taskStatus code 0..1 NA InExecuti on Completed NA InExecuti on Complete d NA NA updateTim e 1 alternative StatusRep ort encoded as Reservatio nReport Applicable in Submit Response yes yes yes yes no no no no service may provide additional information to client in human readable form NA Initial → Accepted Initial → Rejected Initial → Pending NA = not applicable, means element is not used in response Notes: 1 this is a shortcut to convey information in the SubmitResponse that the Submit request was accepted and the submitted task already made the transitions Initial → InExecution and InExecution → Final TaskCompleted may be provided by service NA property name cardinality new identifier provided by service Pending → Accepted Submit Request State Transitions From → To Pending → Rejected Pending → Rejected request expired point in time when transition was made identifier previously provided by service identifier of procedure for which Submit request was made pyright © 2011 Open Geospatial Consortium 69 70 Copyright © 2011 Open Geospatial Consortium Requirement http:www.opengis.netspecSPS2.0reqSubmitResponsetaskAlreadyCompleted REQ 53. If the SubmitResponse has taskStatus Completed then the service shall have performed state logging and notification – if supported – for the according task. That task then has made the transitions Initial Æ InExecution and InExecution Æ Final TaskCompleted.

7.3.5.5 Exceptions

Requirement http:www.opengis.netspecSPS2.0reqSubmitResponseexceptions REQ 54. When an SPS server encounters an error while performing a Submit operation, it shall return an exception message as specified in clause 7.2.

7.3.5.6 Examples

Clause 9.6 provides example XML instances for the Submit operation request and response. Copyright © 2011 Open Geospatial Consortium 71 Issue Name: After Submission Notification Gap JE, Dec 17 th ,09 Issue Description: When a service implements publishsubscribe functionality see clause 8 and publishes notifications on status changes of submitted tasks, then a client might miss notifications for his task unless he subscribed for status changes of all tasks beforehand. A client does not get the identifier for his task before it actually submitted it – only the SubmitResponse contains the task identifier, which can then be used in a subscription for notifications of that task. However, in the time it takes from the actual submission to a completed subscription the service might already have published notifications for the task. These notifications will be missed by the client. The same issue applies for task reservations. The client could try to retrieve the missing status information via a GetStatus request see clause 7.3.6 using the since parameter in the request. However, implementation of that parameter is optional for an SPS see clause 7.3.2.4.3. A client might also reserve the task first, then subscribe for it and then confirm it. However, implementation of the Reserve operation is optional for SPS. A solution could be to design an extension that allowed the inclusion of a subscription request directly in the submit request as a request extension parameter, with the semantics that all notifications published for the task – if the request is accepted – are in the scope of that subscription. Resolution: What usually is important to the client is to get the most updated status of his task. So if, right after submitting the task and subscribing for notifications about it, the client issues a GetStatus request, the response of this call fills the gap in the sense that the client is then aware of the latest status of the task and that he will be notified of any further changes.

7.3.6 GetStatus Operation

7.3.6.1 Introduction

The GetStatus operation allows SPS clients to retrieve status reports about a tasking request or a task. This operation is the default mechanism to retrieve status information about a task or tasking request. As explained in clause 6.3.6, a task or tasking request makes one or more state transitions before reaching its final state see Figure 8 and Figure 9 in clause 6.3.6. While not in the final state, a task can transition between several other states. Clients can retrieve a status report via the GetStatus operation. The response to the operation either contains a number of StatusReports or ReservationReports.