... | ... | @@ -138,7 +138,7 @@ JSON response: |
|
|
* `error` contains `null` if the upload succeeded or a JSON object containing an error description if the upload fails for some reason. Value of `error` cannot be `null` if the value of `id` is `null`.
|
|
|
* `locations` is an array of all locations (human readable strings corresponding to `name` entries of **upload_hierarchy** response) where the document has been stored (including the new location) immediately after finishing the upload attempt. The list may be empty if the current upload fails and the uploaded file is nowhere to be found in the document service. The list serves for informative purposes such as notifying the user where the file is located. These values may be cached by the client application and may be used to indicate the presence in the document service by the client application.
|
|
|
|
|
|
'error' (if it is not `null`) is always a JSON object containing:
|
|
|
The `error` entry (if it is not `null`) is always a JSON object containing:
|
|
|
* `code` is a string holding one of the defined set of strings (codes).
|
|
|
* `description` is a string containing a more detailed description of the error. This value may be displayed by the client application on error occasions.
|
|
|
|
... | ... | @@ -150,17 +150,8 @@ Values of error `code` in **upload_file** responses: |
|
|
* `"UNSUPPORTED_FILE_FORMAT"` - uploaded file format is not supported (i.e. is not a ZFO file or the ZFO file is corrupt).
|
|
|
* `"ALREADY_PRESENT"` - the file is already present in the selected location; `description` should contain the name of the location where the file was intended to be stored the name of the already stored file that corresponds with the uploaded file and a statement that the file is already present.
|
|
|
|
|
|
**Current status:**
|
|
|
|
|
|
There is no need for additional error codes.
|
|
|
|
|
|
**Discussion:**
|
|
|
|
|
|
1. Should the client application differentiate between data message (**dm**) and a delivery information (**di**)?
|
|
|
|
|
|
>> ad 1. The document service does not distinguish between data messages (**dms**) and delivery infos (**dis**).
|
|
|
>
|
|
|
> The problem is, that the Datovka application makes a difference between a **dm** (which contains all the attachment files) and a **di** (which does not contain any attachments but contains only information about the delivery status). Therefore `locations` should be related only to the uploaded **dm** or **di**; `locations` must not mix **dms** and **dis** with equal ISDS identifier to prevent any confusion in Datovka application.
|
|
|
**Note:** The problem is, that the Datovka application makes a difference between a data message (**dm** -- which contains all the attachment files) and a delivery info (**di** -- which does not contain any attachments but contains only information about the delivery status). Therefore `locations` should be related only to the uploaded **dm** or **di**; `locations` must not mix **dms** and **dis** with equal ISDS identifier to prevent any confusion in Datovka application.
|
|
|
|
|
|
### Query for ZFO Files Held within the Record Management (**stored_files**)
|
|
|
|
... | ... | @@ -178,18 +169,15 @@ JSON request: |
|
|
}
|
|
|
```
|
|
|
|
|
|
* `dm_ids` is a list of data message identifiers (strings holding integer numbers as used by ISDS) whose location in the record management service we want to obtain. The list may be empty.
|
|
|
* `di_ids` is a list of delivery info identifiers (strings holding integer numbers as used by ISDS) whose location we want to obtain. The list may be empty.
|
|
|
* `dm_ids` is a list of data message identifiers (strings holding integer numbers as used by ISDS) whose location in the record management service the client wants to obtain. The list may be empty.
|
|
|
* `di_ids` is a list of delivery info identifiers (strings holding integer numbers as used by ISDS) whose location the client wants to obtain. The list may be empty.
|
|
|
|
|
|
We use strings containing positive integers because of the ambiguity in integer representation/size when converting from/to JSON on various architectures/implementations. We need to ensure that 64-bit integers are safely accommodated within the structure. It is necessary that 64-bit integers are used when converting these identifiers to numbers as the ISDS data message identifiers are soon going to exceed the range of 32-bit integers.
|
|
|
Strings containing positive integers are used because of the ambiguity in integer representation/size when converting from/to JSON on various architectures/implementations. We need to ensure that 64-bit integers are safely accommodated within the structure. It is necessary that 64-bit integers are used when converting these identifiers to numbers as the ISDS data message identifiers are soon going to exceed the range of 32-bit integers.
|
|
|
|
|
|
Means how to limit the amount of queried files within a single request are provided. The service provider needs to make sure that every batch will be processed in time (therefore the limit to the size of the batch).
|
|
|
|
|
|
**Discussion:**
|
|
|
|
|
|
>> Question is, if we need to differentiate between **dm** & **di**. On our side (SingleCase), those two queries will be implemented in the exactly same way (we don’t differentiate explicitly)
|
|
|
>
|
|
|
> In Datovka application need to clearly distinguish between a **dm** and a **di**. Primarily we are going to notify the user whether **dms** have been uploaded (ignoring **dis** for a start). We want to avoid any confusion therefore we want a clear information that a specific **dm** or **di** has been uploaded. Here we want to avoid any mistakes which could be introduced by treating **dms** and **dis** in the same manner.
|
|
|
**Note:** In Datovka application need to clearly distinguish between a **dm** and a **di**. Primarily we are going to notify the user whether **dms** have been uploaded (ignoring **dis** for a start). We want to avoid any confusion therefore we want a clear information that a specific **dm** or **di** has been uploaded. Here we want to avoid any mistakes which could be introduced by treating **dms** and **dis** in the same manner.
|
|
|
|
|
|
JSON response:
|
|
|
```
|
... | ... | @@ -229,8 +217,4 @@ JSON object describing a data message entry: |
|
|
```
|
|
|
|
|
|
* `dm_id` and `di_id` are data message (**dm**) and delivery info (**di**) identifiers as used in ISDS and in Datovka application (strings containing positive integers).
|
|
|
* `locations` list of all locations where the corresponding message or delivery info is stored. This may be an empty list if the corresponding **dm** or **di** is not stored by the service.
|
|
|
|
|
|
**Current status:**
|
|
|
|
|
|
There is no need for obtaining the internal service identifier of the **dms** or **dis**. These identifiers are irrelevant for Datovka application. |
|
|
\ No newline at end of file |
|
|
* `locations` list of all locations where the corresponding message or delivery info is stored. This may be an empty list if the corresponding **dm** or **di** is not stored by the service. |
|
|
\ No newline at end of file |