ModifyDocumentUploadFile
|
ModifyDocumentUploadFile
|
|||
|
Main
|
History-Relevant
|
||
|
Rückgabewert
|
|||
|
RET
|
|||
|
Parameterliste
|
|||
|
DocumentId
|
IN
|
LONG_NUMERIC_IDENTIFIER
|
>VERSION.DOCUMENTID
|
|
FileId
|
IN
|
LONG_NUMERIC_IDENTIFIER
|
>FILE.FILEID
|
|
NamedValueArray
|
IN
|
NamedValue[]
|
|
|
RealFileName
|
IN
|
REALFILENAME_STRING
|
>FILE.REALFILENAME
|
|
FileSize
|
IN
|
LONG_NUMERIC_IDENTIFIER
|
>FILE.FILESIZE
|
|
MasterFileFlag
|
INo
|
BOOLEAN
|
>FILE.MASTERFILEFLAG
|
|
ViewerFileFlag
|
INo
|
BOOLEAN
|
>FILE.VIEWERFILEFLAG
|
|
ExcludeFromIndex
|
INo
|
BOOLEAN
|
>FILE.EXCLUDEFROMINDEX
|
|
ByteArray
|
IN
|
JUNK_FILE_BYTE_ARRAY
|
MAX_JUNK_FILE_SIZE_IN_KB
|
|
FirstJunkFile
|
IN
|
Boolean
|
Kennzeichung des ersten JunkFiles
|
|
FileUploadMode
|
IN
|
Enum: FileUploadMode
|
|
|
FileTransferToDmsState
|
OUT
|
Enum: FileTransferToDmsState
|
>FILE.RECEIVINGSTATE
|
Kurzbeschreibung:
Dieser Service verändert einen DOCUMENT/VERSION-Eintrag indem ein
bestehender Eintrag in der Tabelle FILE angepasst wird.
Zuerst wird das Document geladen. Anschliessend wird die korrekte
Version zugeladen. Anhand der Version kann das Storage etabliert werden.
Nun wird in einem ersten Schritt der Eintrag der Tabelle FILE gelesen.
Nachdem in einem zweiten Schritt die Datei über das Storage physikalisch
geschrieben worden ist, wird dann in einem dritten Schritt der aktuelle
File-Zustand (TransferMode, UsedSize) auf der Datenbank nachgeführt.
FileUploadMode:
NEW - Beim Hochladen der Datei wird abgebrochen, sofern schon eine
physikalische Datei im DMS existiert
NEW_OR_UPDATE - Eine allenfalls physikalisch vorhandene Datei wird beim
Hochladen überschrieben
Fehlerhandling/Plausibilisierung:
Generell gelten die Regeln (PK, AK, FK, Unique, NotNull) der Datenbank.
Die zusätzlichen Fehler sind:
-
Aufgrund von Validator-Prüfungen (VD)
-
Wenn das Document über die DocumentId nicht gefunden wird (1)
-
Wenn die korrekte Version nicht gefunden wird (2)
-
Wenn das File über die FileId nicht gefunden wird (3/4/6)
-
Wenn für die korrekte Version die Modify-Rechte fehlen (5/7)
-
Wenn der RealFileName nicht übergeben wird (8)
-
Wenn der RealFileName leer übergeben wird (9)
-
Wenn der RealFileName in der Extension abweicht (10)
-
Wenn auf dem Storage nicht genügend freier Speicher verfügbar ist (11)
-
Wenn die FileSize den Wert 0 bekommen hat (12) vor Version 15.10.03 !
-
Wenn die FileSize einen Wert grösser der maximal zulässigen Grösse bekommen hat (13)
-
Wenn für die JunkFileSize der Wert 0 berechnet wurde (14) vor Version 15.10.03 !
-
Wenn für die JunkFileSize ein Wert grösser der maximal zulässigen Grösse berechnet wurde (15)
-
Wenn die Version zur FileId von der Checkout-Version des Dokuments abweicht (16)
-
Wenn im UploadMode NEW beim ersten Junk-File im DMS bereits eine Datei existiert (17)
-
Wenn der FileAccess nicht registriert ist (18)
-
Wenn der StorageDirectorAndProtector im FileAccess nicht registriert ist (19)
-
Wenn die empfangene Datei auf dem Medium grösser ist als sie deklariert wurde (20)
-
Wenn das Schreiben der Datei aufgrund des geschlossenen StorageDirectors blockiert wurde (21)
-
Wenn das Schreiben der Datei aufgrund des „ReadOnly“ StorageDirectors blockiert wurde (22)
-
Wenn das Löschen der bestehenden Datei aufgrund des geschlossenen StorageDirectors blockiert wurde (23)
-
Wenn das Löschen der bestehenden Datei aufgrund des „ReadOnly“ StorageDirectors blockiert wurde (24)
-
Wenn die bestehende Datei nicht gelöscht werden kann weil sie physikalisch nicht existiert (25)
-
Wenn das Dokument nicht ausgecheckt ist (26)
-
Wenn das Dokument nicht vom ContextUser ausgecheckt wurde (27)
-
Wenn die Version bei der Storage-Zuweisung nicht zugegriffen werden kann (28)
-
Wenn das WorkingStorage nicht zugewiesen werden kann (29)
-
Wenn die Datei nicht erweitert werden kann weil sie physikalisch nicht existiert (30)
-
Wenn UniqueFileNames des Dokuments true ist und der RealFileName auf der Version schon existiert! (31)
Bemerkungen:
(1): GetDocNEx
(2): GetVrsNEx
(3): GetFileNEx
(4): ModFileNEx
(5):
ModeFileInsuffPriv
(6): ModFileNEx
(7):
ModFileInsuffPriv
(8):
ModDocAddFileRealFileNmMs
(9):
ModDocAddFileRealFileNmIsEmpty
(10):
ModDocUplFileUplBlkExtMsm
(11):
ModDocUplFileUplBlkNEnoughSpace
(12):
ValMinFileSizeVio
(13):
ValMaxFileSizeVio
(14):
ValMinJunkFileSizeVio
(15):
ValMaxJunkFileSizeVio
(16):
ModDocUplFileVrsMsm
(17):
ModDocUplFileUplBlkAlreadyEx
(18):
EnvFileAccNReg
(19):
EnvStrgDirAndProtNReg
(20):
EnvStrgDirAndProtFileSizeExd
(21):
EnvStrgDirAndProtWriteBlkClosedStrg
(22):
EnvStrgDirAndProtWriteBlkReadOnlyStrg
(23):
EnvStrgDirAndProtDestrBlkClosedStrg
(24):
EnvStrgDirAndProtDestrBlkReadOnlyStrg
(25):
EnvStrgDirAndProtDestrBlkFileNEx
(26):
ModDocNCheckedOut
(27):
ModDocCheckoutUsrMsm
(28): ModVrsNEx
(29):
ModVrsNoStrg
(30):
LoadFileNEx
(31):
ModFileFileNmNUq
File an das DMS übertragen:
Das File ist in diesem Fall schon registriert. Beim eigentlichen Upload
wird über den Key (DocumentId, FileId) addressiert. Zwingend muss der
RealFileName und die FileSize übergeben werden. Der ByteArray darf maximal
die Grösse MAX_JUNK_FILE_IN_KB umfassen. Mit dem Boolean FirstJunkFile
wird dem DMS signalsiert, dass der ByteArray der Auftrakt der
Uebermittlung des neuen Files darstellt (Dies ist nötig, da Aufgrund eines
allfälligen Abbruchs bereits ein angefangener ByteArray im DMS stehen
könnte und dann automatisch ein Append erfolgen würde, was in diesem Fall
falsch wäre!)
Nach dem ersten Aufruf steht im Out-Parameter FileTransferToDmsState
FILE_TRANSFER_COMPLETE sofern die Datei bereits vollständig übertragen
wurde, oder FILE_TRANSFER_IN_PROGRESS wenn das DMS weitere ByteArrays
erwartet, die in ähnlicher Form übertragen werden müssen (FirstJunkFile
dann aber false setzen!).
 |
WichtigMasterFileFlag/ViewerFileFlag: Es wird nur das Setzen
(Wert „true“) unterstützt.
Es ist sichergestellt, dass immer genau
ein File das Master-Flag bzw. das Viewer-Flag gesetzt hat.
|