-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.json
309 lines (309 loc) · 119 KB
/
index.json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
[
{
"uri": "https://myakimov.github.io/documaster-api-docs/general/",
"title": "Getting Started",
"tags": [],
"description": "",
"content": "Chapter 1 Getting started Discover what Documaster Norak5 API provides, how to get access and start developing integrations using it.\n"
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/",
"title": "Documaster Noark5 API",
"tags": [],
"description": "",
"content": "Documaster Noark5 API This is the documentation site for the Documaster Noark5 Compliant API v1.0. Documentation is divided in multiple sections described below.\nGetting Started Getting Started section outlines the details regarding onboarding integrating parties, API security, basic infromation of the API operations, model, usage and general develoler guidelines. Additionally all details regarding Documaster Client SDKs usage (Java, .NET) are in the section.\nThe section contains all the required information for an integration developers to be able to have a working developer environment towards a Documaster integration instance.\n Getting Started Operations Operations section contains details regarding all the operations available in the API, their usage and provided functionality.\n Operations Data Model Data Model section is the reference for all data model entities,their fields, relations and usages.\n Data Model Examples Examples section is the one-stop place in the documentation site for every example available, separted per entity, but also containing examples for common or specific use cases of the API.\n Examples "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/operations/",
"title": "Operations",
"tags": [],
"description": "",
"content": "Chapter 2 Operations Take a detailed look at the operations provided by Documaster Noark5 API\n"
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/overview/",
"title": "Overview",
"tags": ["documentation", "tutorial"],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/operations/core/",
"title": "Core Operations",
"tags": [],
"description": "",
"content": "Overview Core operations are considered all operations which manage the most important entities in the system, those being part of the Noark5 model.\nAny update of the Documaster Archive structure is done using the Transaction :: POST /noark5/v1/transaction operation. Retrieving data from the archive is done using the Query :: POST /noark5/v1/query oepration.\nWhen working with the electronic documents, uploading a documents is done using the Upload :: POST /noark5/v1/upload operation. Respectively, downloading a document is done using the Download :: POST /noark5/v1/download operation.\nEntities Managed with Core Operations Below is a complete list of the entities that are managed using Core Operations, more specifically transaction and query operations.\nTake a look at the Data Model Oveview page for more details on the entities and their relations.\nFonds Fonds (Arkiv) Fonds Creator (Arkivskaper) Classification Classification System (Klassifikasjonssystem) Class (Klasse) Series Seies (Arkivdel) Folders Level Basic Folder (Mappe) Meeting Folder (Moetemappe) Meeting Participant (Moetedeltaker) Case File (Saksmappe) Case Party (Sakspart) Records Level Basic Record (Basisregistrering) Registry Entry (Journalpost) Correspondence Party (Korrespondansepart) Document Flow (Dokumentflyt) Sign-Off (Avskrivning) Meeting Record (Moeteregistrering) Documents Document (Dokument) Document Version (Dokumentversjon) National Identifiers Address (Adresse) Building (Bygning) Property (Eiendom) Plan (Plan) Shared Entities External ID (EksternId) Keywords (Noekkelord) Note (Merknad) "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/general/overview/",
"title": "Overview",
"tags": [],
"description": "",
"content": "Overview Documaster API provides the capabilities of managing the Noark5 compliant model, that Documaster Archive is based on. Supporting various use cases and integration scenarios is at the basis of the API design, combined with strong focus on security, consistency and efficiency.\nDocumaster Noark5 API key features:\n Supports full control over Noark5 compliant model of Documaster Archive Strong consistency model for entities creation Flexible query language Full-text search capabilities Bulk operations Secured using OAuth2/OIC, which combined with Documaster Archive internal security model, provides fine grained control over each and every aspect of the Noark5 entities Support for external IDP (Identity Providers) such as Azure ADFS (Office365 integration), Active Directory, LDAP, others. HTTP/JSON based, making it easy to integrate with wide varieaty of external systems API designed to be solely consumed in a server-to-server manner Documaster developed client SDKs for both Java and .NET Noark5 Noark is a Norwegian national standard for electronic records management and archiving which began its history in 1984. The latest major version of the standard, Noark 5, is based on the EU standard MoReq. Even though there are many similarities between the two, Noark 5 is more pragmatic than MoReq in certain areas where MoReq follows core archival principles more strictly.\nNoark5 Standard Official Page\nStart Using the Documaster Noark5 API As a very first step of using the API, one should be provided with the required access (credentils, certificates, hosts, etc.).\n Onboarding Second would be deciding on the type of client you would be developing. If your system is Java or .NET based, please consider using our Client SDKs.\n Client SDKs Third, authenticate using your credentials agains the integration instance you gained access to. We provide IDP Client SDKs for Java and .NET in case this is your preffered way.\n Authentication and Authorization Forth, take a brief look at the Documaster Noark5 Model and Operations.\n Model and Operatons Overview As a last of having a working development environment, try a couple of examples.\n First API Interaction "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractfolder/casefile/",
"title": "Case File",
"tags": [],
"description": "",
"content": "Saksmappe "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractfolder/casefile/caseparty/",
"title": "Case Party",
"tags": [],
"description": "",
"content": "Sakspart "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/common/",
"title": "Common",
"tags": [],
"description": "",
"content": "AbstraktRegistrering / Abstract Record Fields Field no. Type Field Not null Has default Code list Save View Query Sort Comment string id x x sm x x x string version x x sm x x M001 string .definition { visibility: hidden; width: 220px; background-color: #555; color: #fff; text-align: left; border-radius: 6px; padding: 5px 0; position: absolute; z-index: 1; bottom: 125%; left: 50%; margin-left: -60px; opacity: 0; transition: opacity 0.3s; padding: 5px 5px 5px 5px; } .term { position: relative; display: inline-block; border-bottom: 1px dotted black; } .term:hover .definition { visibility: visible; opacity: 1; } uuid unique identifer of entity in Documaster system x x cw x x x M600 timestamp .definition { visibility: hidden; width: 220px; background-color: #555; color: #fff; text-align: left; border-radius: 6px; padding: 5px 0; position: absolute; z-index: 1; bottom: 125%; left: 50%; margin-left: -60px; opacity: 0; transition: opacity 0.3s; padding: 5px 5px 5px 5px; } .term { position: relative; display: inline-block; border-bottom: 1px dotted black; } .term:hover .definition { visibility: visible; opacity: 1; } opprettetDato createdDate (en) date at which the entity was created x x cw x x x M601 string opprettetAv x x cw x x x M601 string opprettetAvBrukerIdent x x cw x x x M602 timestamp avsluttetDato cw x x x M603 string avsluttetAv cw x x x M603 string avsluttetAvBrukerIdent cw x x x string prefiks cw x x x • optional identifier of the system this Journalpost originated from\n• it is strongly advised to populate this field when the target system contains or will contain data from multiple source case management systems\n• once set, this value cannot be modified\n "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractrecord/registryentry/",
"title": "Registry Entry",
"tags": [],
"description": "",
"content": "Overview Registry Entry is a journaling entry collecting documents part of an interaction with a correspondence party.\n Registry Entry Journalpost is a subtype of AbstraktRegistrering and as such inherits fields part of the parent object. Being a core Noark5 model entity, Registry Entry is managed using the POST /transaction operation. Registry Entry can be linked under either a Case File (Saksmappe) or a Folder (Mappe). Registry Entry cannot be created without a transaction::link action to an entity on the folders level through refMappe Any Registry Entry, should be linked to a Correspondence Party(Korrespondansepart) that needs to be created in the same transaction as the Registry Entry itself. Registry entries are referenced by Document(Dokument) entities during Document, DocumentVersion creation Document (Dokument) Entity Reference Table below contains the names with which the entity can be used in transaction and query operations.\n Context Entity Name referred to in transaction::save action as Journalpost referred to in transaction::link action Journalpost referred to in transaction::unlink action Journalpost referred to in query operation Journalpost or AbstraktRegistrering Diagram showing the relation of Registry Entry entity (Journalpsot) to any other entities through its reference fields. The diagram depicts the most important set of fields, leaving some of the use cases out of it for simplicity. Diagram of the relation of Registry Entry and Abstract Record and siblings. Fields AbstraktRegistrering / Abstract Record Fields Field no. Type Field Not null Has default Code list Save View Query Sort Comment string id x x sm x x x string version x x sm x x M001 string .definition { visibility: hidden; width: 220px; background-color: #555; color: #fff; text-align: left; border-radius: 6px; padding: 5px 0; position: absolute; z-index: 1; bottom: 125%; left: 50%; margin-left: -60px; opacity: 0; transition: opacity 0.3s; padding: 5px 5px 5px 5px; } .term { position: relative; display: inline-block; border-bottom: 1px dotted black; } .term:hover .definition { visibility: visible; opacity: 1; } uuid unique identifer of entity in Documaster system x x cw x x x M600 timestamp .definition { visibility: hidden; width: 220px; background-color: #555; color: #fff; text-align: left; border-radius: 6px; padding: 5px 0; position: absolute; z-index: 1; bottom: 125%; left: 50%; margin-left: -60px; opacity: 0; transition: opacity 0.3s; padding: 5px 5px 5px 5px; } .term { position: relative; display: inline-block; border-bottom: 1px dotted black; } .term:hover .definition { visibility: visible; opacity: 1; } opprettetDato createdDate (en) date at which the entity was created x x cw x x x M601 string opprettetAv x x cw x x x M601 string opprettetAvBrukerIdent x x cw x x x M602 timestamp avsluttetDato cw x x x M603 string avsluttetAv cw x x x M603 string avsluttetAvBrukerIdent cw x x x string prefiks cw x x x • optional identifier of the system this Journalpost originated from\n• it is strongly advised to populate this field when the target system contains or will contain data from multiple source case management systems\n• once set, this value cannot be modified\n Entity Fields Field no. Type Field Not null Has default Code list Save View Query Sort Comment string id x sm x x x string version x x sm x x M001 string .definition { visibility: hidden; width: 220px; background-color: #555; color: #fff; text-align: left; border-radius: 6px; padding: 5px 0; position: absolute; z-index: 1; bottom: 125%; left: 50%; margin-left: -60px; opacity: 0; transition: opacity 0.3s; padding: 5px 5px 5px 5px; } .term { position: relative; display: inline-block; border-bottom: 1px dotted black; } .term:hover .definition { visibility: visible; opacity: 1; } uuid unique identifer of entity in Documaster system x x cw x x x M600 timestamp .definition { visibility: hidden; width: 220px; background-color: #555; color: #fff; text-align: left; border-radius: 6px; padding: 5px 0; position: absolute; z-index: 1; bottom: 125%; left: 50%; margin-left: -60px; opacity: 0; transition: opacity 0.3s; padding: 5px 5px 5px 5px; } .term { position: relative; display: inline-block; border-bottom: 1px dotted black; } .term:hover .definition { visibility: visible; opacity: 1; } opprettetDato createdDate (en) date at which the entity was created x x cw x x x M601 string opprettetAv x x cw x x x M601 string opprettetAvBrukerIdent x x cw x x x M602 timestamp avsluttetDato cw x x x M603 string avsluttetAv cw x x x M603 string avsluttetAvBrukerIdent cw x x x string prefiks cw x x x • optional identifier of the system this Journalpost originated from\n• it is strongly advised to populate this field when the target system contains or will contain data from multiple source case management systems\n• once set, this value cannot be modified\n M004 string registreringsIdent x x cw x x x M020 string tittel x x x x x M025 string offentligTittel x x x x M021 string beskrivelse x x x x M024 string forfatter x x x x M300 string dokumentmedium x x dokumentmedium x x x M013 number journalaar x x cw x x x M014 number journalsekvensnummer x x cw x x x M015 number journalpostnummer x x cw x x x string journalansvarlig x x x x x x • The name of the person responsible for this Journalpost (similar to M306 Saksmappe#saksansvarlig)\n string journalansvarligBrukerIdent x x x x x x • The user ID of the person responsible for this Journalpost as stored in journalansvarlig (similar to M306 Saksmappe#saksansvarligBrukerIdent)\n M082 string journalposttype x journalposttype x x x M053 string journalstatus x x journalstatus x x x M101 date registreringsDato x x x x x x M103 date dokumentetsDato x x x x M109 date forfallsdato x x x x M104 timestamp mottattDato x x x x M105 timestamp sendtDato x x x x M110 date offentlighetsvurdertDato x x x x boolean skjermKorrespondanseParterEInnsyn x x x x x When true, it indicates that Korrespondansepart objects of this Journalpost referenced by refKorrespondansepart will be screened in eInnsyn, even if the Journalpost is not effectively screened. When false or null, it indicates that Korrespondansepart objects will not be screened in eInnsyn, even if the Journalpost is effectively screened. Defaults to false. M500 string skjerming skjerming x x x M711 object virksomhetsspesifikkeMetadata x x Reference Fields Field Not null View Query Link Unlink Comment refMappe c x x x x • references Saksmappe\n• exactly one of refMappe and refArkivdel is required\n refArkivdel c x x x x • references Arkivdel\n• exactly one of refMappe and refArkivdel is required\n refKorrespondansepart x x x refDokument x x x refPrimaerKlasse x x x x • references a Klasse from the primary Klassifikasjonssystem of the Arkivdel\n refSekundaerKlasse x x x • references a Klasse from any Klassifikasjonssystem\n refEksternId x x refDokumentflyt x x refNoekkelord x x refAvskrivning x x refTilknyttetAvskrivning x x x refMerknad x x x refNasjonalIdentifikator x x refKryssreferanseTilMappe x x x refers to AbstraktMappe that the current AbstraktRegistrering cross references refKryssreferanseFraMappe x x x refers to AbstraktMappe that cross reference the current AbstraktRegistrering refKryssreferanseTilRegistrering x x x refers to AbstraktRegistrering that the current AbstraktRegistrering cross references refKryssreferanseFraRegistrering x x x refers to AbstraktRegistrering that cross reference the current AbstraktRegistrering Working with Registry Entry Creating Registry Entry Registry entries are created using transaction API, where in a single transaction the newly created registry entry should be linked to a case file (Saksmappe) or a basic folder (Mappe). Bear in mind that the registry entry can be under only one folder. Newly created registry entry requires at least one correspondence party (Korrespondansepart) to be created and associated with the registry entry. The link is done using transaction::link action following the guidelines to use newly created entry reference field to parent entry (Korrespondansepart::refRegistrering), rather than parent entry reference field (Journalpost::refKorrespondansepart). Take a look at the Fields section of this document for details about the mandatory/optional fields for registry entries.\nDocument (Dokument) entities are associated to Registry entries during documents creation. Examples how a document is created and associated to a registry entry can be found here.\n Correspondence Party Entity Document Entity Document Version Entity HTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/transaction HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;691\u0026#34; }, { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;korrespondansepart-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;korrespondanseparttype\u0026#34;: \u0026#34;EA\u0026#34;, \u0026#34;korrespondansepartNavn\u0026#34;: \u0026#34;Correspondence Party Name\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;korrespondansepart-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refRegistrering\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34; } ] } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;journalpost-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;938\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;35926f91-96d2-40d7-961e-9ffb368673af\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.933+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;registreringsIdent\u0026#34;: \u0026#34;2021/5\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;registreringsDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.950+0100\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;journalaar\u0026#34;: 2021, \u0026#34;journalsekvensnummer\u0026#34;: 5, \u0026#34;journalpostnummer\u0026#34;: 5, \u0026#34;journalansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;journalansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34;, \u0026#34;journalstatus\u0026#34;: \u0026#34;J\u0026#34;, \u0026#34;skjermKorrespondanseParterEInnsyn\u0026#34;: false }, \u0026#34;links\u0026#34;: { \u0026#34;refMappe\u0026#34;: 691 } }, \u0026#34;korrespondansepart-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;939\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;3\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;3f7bad64-9560-45d2-82a5-4e5fb06a5c13\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.953+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;korrespondanseparttype\u0026#34;: \u0026#34;EA\u0026#34;, \u0026#34;korrespondansepartNavn\u0026#34;: \u0026#34;Correspondence Party Name\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refRegistrering\u0026#34;: 938 } } } } Update Registry Entry Updating a registry entry is done through transaction::save action in the same way it is used to create it, with the difference that the actual id of the registry entry should be used (returned in create call response in $.saved.{tempIDofRegistryEntry}.id). The example below show an update of the registry entry (chaning the description) and linking a new Address (Adresse).\nHTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/transaction HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;938\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;beskrivelse\u0026#34;: \u0026#34;Updated Registry Entry Description\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Adresse\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;adresse-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;adresseKnr\u0026#34;: \u0026#34;0301\u0026#34;, \u0026#34;postnr\u0026#34;: \u0026#34;0301\u0026#34;, \u0026#34;poststed\u0026#34;: \u0026#34;Oslo\u0026#34;, \u0026#34;adressenavn\u0026#34;: \u0026#34;Rådhusplassen\u0026#34;, \u0026#34;nummer\u0026#34;: \u0026#34;1\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Adresse\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;adresse-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refRegistrering\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;938\u0026#34; } ] } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;938\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;938\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;9\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;35926f91-96d2-40d7-961e-9ffb368673af\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.933+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;registreringsIdent\u0026#34;: \u0026#34;2021/5\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Updated Registry Entry Description\u0026#34;, \u0026#34;registreringsDato\u0026#34;: \u0026#34;2021-11-24\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;journalaar\u0026#34;: 2021, \u0026#34;journalsekvensnummer\u0026#34;: 5, \u0026#34;journalpostnummer\u0026#34;: 5, \u0026#34;journalansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;journalansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34;, \u0026#34;journalstatus\u0026#34;: \u0026#34;J\u0026#34;, \u0026#34;skjermKorrespondanseParterEInnsyn\u0026#34;: false }, \u0026#34;links\u0026#34;: { \u0026#34;refMappe\u0026#34;: 691 } }, \u0026#34;adresse-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Adresse\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;967\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;7276dd75-d4aa-4b0c-956c-0ae31ee233b0\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:38:49.625+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;adresseKnr\u0026#34;: \u0026#34;0301\u0026#34;, \u0026#34;postnr\u0026#34;: \u0026#34;0301\u0026#34;, \u0026#34;poststed\u0026#34;: \u0026#34;Oslo\u0026#34;, \u0026#34;adressenavn\u0026#34;: \u0026#34;Rådhusplassen\u0026#34;, \u0026#34;nummer\u0026#34;: \u0026#34;1\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refRegistrering\u0026#34;: 938 } } } } "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/operations/core/transaction/",
"title": "Transaction",
"tags": [],
"description": "",
"content": "Description POST /noark5/v1/transaction The POST /noark5/v1/transaction or as referred to in the documentation transaction operation is the only way to introduce changes inside the Documaster Archive Noark5 structure of core entities. The operation payload is an ordered set of actions, which are executed in a sequential manner. Call execution is considered successful only in case all the actions part of the transaction are completed successfully, otherwise all of the actions are reverted back. This way the structure remains consistent, with no partial updates or corrupted links as a result of a partially executed set of actions.\nActions supported by the operation are as follows:\n save - used to create or update a core entity fields. link - used to link two (or more) core entities using one of the entities reference field to the connecton between the two delete - used to delete a core entity from the structure (used only with special permissions) unlink - used to disassociate two entities Order of the actions in a transaction is important for the execution, especially during creation of new entity objects. Always order the actions in a way that newly created entity objects are linked to the existing structure and only then link other entity objects to them.\n Request Actions are supplied in the payload body of the request in an array $.actions[], where each action has a field $.actions[].action which can take one of the values above.\nTypical transaction is depicted below, showing a new Registry Entry (Journalpost) created and a Correspondence Party (Korrespondansepart). The Registry Entry is linked to an existing Case File (Saksmappe), while the Correspondence Party is linked to the Registry Entry.\nCommon HTTP Request Mapping Field Location Mandatory Type Description Authorization Header yes string access token aquired as part of the authentication call, prefixed with Bearer Content-Type Header yes string content type header, should always be provided as application/json X-Documaster-Error-Response-Type Header yes string custom header indicating that any error should be reported in JSON format, rather than the standard text format, should always be provided as application/json $.actions[] Body yes array array of actions executed sequentially $.actions[].action Body yes string one of the supported action types : save, link, delete, unlink $.actions[].type Body yes string type of the core entity affected by the action (Arkiv, Arkivdel, Saksmappe, Journalpost, etc.) $.actions[].id Body yes string Unique identifier of the entity which is being affected by the action. If the entity is a new one, the identifer should be a non-numeric ID valid only in the context of the transaction Key Points Actions order is important since they are executed sequentially All transaction actions should succeed for the transaction to be successful Each action can work on a single entity, identified by the combination of $.actions[].type and $.actions[].id Creating an entity object with save should always be followed by a link action, where a reference of the new entity is used to link it to another entity link actions should be executed against the child object which is linking to an entity up the structure, not the other way around. Registry Entry is linking itself to the Case File, through the refMappe reference, not the Case File adding the Registry Entry to the list of its records. Temporary IDs $.actions[].id is used only for object that are being created and are valid only in the scope of the transaction. Temporary IDs must be non-numberic values Always link the new entity objects to the existing structure or to another new entity which was already linked to the structure Response Response of an a transaction contains only the saved objects details in an element $.saved, which contains one element with the name of the object ID with all the details about it, including fields filled in with default values. The object ID is either the temporary ID, in case the object is newly created, or the actual numeric ID in case it is just updated.\n$.saved element would be empty in cases where no entity object fields are updated. transaction::link, transaction::unlink and transaction:delete actions will always result in a response containing an empty $.saved element.\nHTTP Response Field Location Type Description Content-Type Header string content type header, always is application/json $.saved[].{savedEntityID} Body string one element for each of the entity objects that were saved, where {savedEntityID} is the ID of the element that was saved, either a temporary ID or the actual ID. HTTP Java C# Save Entites Response\nHTTP/1.1 200 OK ... Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;journalpost-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;938\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;35926f91-96d2-40d7-961e-9ffb368673af\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.933+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;registreringsIdent\u0026#34;: \u0026#34;2021/5\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;registreringsDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.950+0100\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;journalaar\u0026#34;: 2021, \u0026#34;journalsekvensnummer\u0026#34;: 5, \u0026#34;journalpostnummer\u0026#34;: 5, \u0026#34;journalansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;journalansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34;, \u0026#34;journalstatus\u0026#34;: \u0026#34;J\u0026#34;, \u0026#34;skjermKorrespondanseParterEInnsyn\u0026#34;: false }, \u0026#34;links\u0026#34;: { \u0026#34;refMappe\u0026#34;: 691 } }, \u0026#34;korrespondansepart-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;939\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;3\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;3f7bad64-9560-45d2-82a5-4e5fb06a5c13\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.953+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;korrespondanseparttype\u0026#34;: \u0026#34;EA\u0026#34;, \u0026#34;korrespondansepartNavn\u0026#34;: \u0026#34;Correspondence Party Name\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refRegistrering\u0026#34;: 938 } } } } Link/Unlink/Delete Response\nHTTP/1.1 200 OK ... Content-Type: application/json { \u0026#34;saved\u0026#34;: {} } Actions Action::Save save action is used to create or update an entity object part. As part of the save action, only fields related to the specific entity can be set or modified. Reference fields (fields prefixed with ref) cannot be accessed using the save action. Reference fields are used in link and unlink actions to indicate a connection between two entities.\nUsage Creating a new entity object - save should be followed by a link action in the same transaction, connecting the new entity to an entity in the existing structure. Exception of this rule are the Fonds (Arkiv) as being root objects in the structure and Classification Systems (Klassifikasjonssystem), which can be created without reference to any other entity in the structure Updating an existing entity object - save is used to update the entity object fields, it cannot be used to update references (ref) HTTP Request Mapping Only modified elements in the current request are shown, other headers/body elements remain the same\n Field Location Mandatory Type Description $.actions[].action Body yes string value of save $.actions[].id Body yes string Unique identifier of the entity which is being affected by the action. If the entity is a new one, the identifer should be a non-numeric ID valid only in the context of the transaction $.actions[].fields Body yes object an object containing entity specific fields and their respective values. Entity specific fields can be found in the Model section of the documentation HTTP Java C# Create\n{ \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34; } }, .... required link action to link the entity to the structure .... { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;691\u0026#34; }, .... other actions .... ] } Update\n{ \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;864\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry(Updated Title)\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description (Updated Description)\u0026#34; } }, .... other actions .... ] } Action::Link link action is used to connect core entities using their reference fields.\nUsage Creating a new entity object - usage scenario is described in the Action::Save::Usage, where link action follows a save action Linking Class as secondary to an entity - link can be used to link a Class (Klasse) as secondary to entities in the structure Linking entity objects through cross references - link can be used to link core entities that don\u0026rsquo;t have parent child relations through cross reference relations, as an example : a Registry Entry (Journalpost) can reference another RegisryEntry through refKryssreferanseTilRegistrering refernece field (cross-reference to record) Moving an entity object in the structure - link is used right after unlink action to implement \u0026ldquo;move\u0026rdquo; functionality. Kind of entities that can be moved depends on the particular use cases and permissions of the integration account. HTTP Request Mapping Only modified elements in the current request are shown, other headers/body elements remain the same\n Field Location Mandatory Type Description $.actions[].action Body yes string value of link $.actions[].id Body yes string unique identifier of the entity which is being affected by the action. If the entity is a new one, the identifer should be a non-numeric ID valid only in the context of the transaction $.actions[].ref Body yes string name of the reference field which is updated by the link action. The reference field is part of the entity model identified by $.actons[].type element $.actions[].linkToId Body yes array a string array (or a single string value) identifying another core entity which can be referenced using the field in $.actions[].ref. It can contain a temporary ID in case the referenced entity object is also created in the same transaction HTTP Java C# Link New Entity\n{ \u0026#34;actions\u0026#34;: [ .... save action creating new Regisry Entry (Journalpost) .... { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34; } }, .... required link action to link the entity to the structure .... { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;691\u0026#34; }, .... other actions .... ] } Link Existing Entities\n{ \u0026#34;actions\u0026#34;: [ .... link existing Case File (Saksmappe) with ID 981 to a Class (Klasse) 598 as secondary class .... { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;981\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refSekundaerKlasse\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;598\u0026#34; }, .... other actions .... ] } Move Entity Objects (unlink + link)\n{ \u0026#34;actions\u0026#34;: [ .... unlink RegisryEntry from Case File (981).... { \u0026#34;action\u0026#34;: \u0026#34;unlink\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1001\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;unlinkFromId\u0026#34;: \u0026#34;981\u0026#34; }, .... link RegisryEntry to another Case File (666).... { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1001\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;666\u0026#34; }, .... other actions .... ] } Action::Unlink unlink action is used to remove connection between core entity objects. It can be used to remove links between entities which can remain unattached, like Case File (Saksmappe) and a Class (Klasse) as secondary. The action does not allow unlinking an entity which cannot exist without its parent, like unlinking a Registry Entry (Journalpost) from the Case File (Saksmappe) it is part of.\nUsage Unlinking Class as secondary to an entity - unlink can be used to remove a Class (Klasse) as secondary for entities in the structure Unlinking entity objects cross references - unlink can be used to remove cross-reference between core entities Moving an entity object in the structure - link is used right after unlink action to implement \u0026ldquo;move\u0026rdquo; functionality. Kind of entities that can be moved depends on the particular use cases and permissions of the integration account. HTTP Request Mapping Only modified elements in the current request are shown, other headers/body elements remain the same\n Field Location Mandatory Type Description $.actions[].action Body yes string value of unlink $.actions[].id Body yes string unique identifier of the entity which is being affected by the action. $.actions[].ref Body yes string name of the reference field which is updated by the unlink action. The reference field is part of the entity model identified by $.actons[].type element $.actions[].unlinkFromId Body yes array a string array (or a single string value) identifying another core entity which is linked to the entity HTTP Java C# Unlink Entities\n{ \u0026#34;actions\u0026#34;: [ .... unlink existing Case File (Saksmappe) with ID 981 and linked to it Class (Klasse) 598 as secondary class .... { \u0026#34;action\u0026#34;: \u0026#34;unlink\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;981\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refSekundaerKlasse\u0026#34;, \u0026#34;unlinkFromId\u0026#34;: \u0026#34;598\u0026#34; }, .... other actions .... ] } Move Entity Objects (unlink + link)\n{ \u0026#34;actions\u0026#34;: [ .... unlink RegisryEntry from Case File (981).... { \u0026#34;action\u0026#34;: \u0026#34;unlink\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1001\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;unlinkFromId\u0026#34;: \u0026#34;981\u0026#34; }, .... link RegisryEntry to another Case File (666).... { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1001\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;666\u0026#34; }, .... other actions .... ] } Action::Delete delete action is used to remove core entities objects from the archive structure.\nThe delete action is available only for internal use and mentioned here for completenes. It is not available to integrating parties unless a specific uses cases require it.\n HTTP Request Mapping Only modified elements in the current request are shown, other headers/body elements remain the same\n Field Location Mandatory Type Description $.actions[].action Body yes string value of delete $.actions[].id Body yes string unique identifier of the entity which is being affected by the action. HTTP Java C# Delete Entities\n{ \u0026#34;actions\u0026#34;: [ .... delete Registry Entry (Journalpost) with ID 994 .... { \u0026#34;action\u0026#34;: \u0026#34;delete\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;994\u0026#34; }, .... other actions .... ] } "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/operations/core/transaction/usage-guidelines/",
"title": "Usage Guidelines",
"tags": [],
"description": "",
"content": "Key Usage Points Actions order is important since they are executed sequentially All transaction actions should succeed for the transaction to be successful Each action works on a single entity, identified by the combination of $.actions[].type and $.actions[].id save action manages entity fields, while link/unlink actions use the reference field (prefixed with ref) Creating an entity object with save should always be followed by a link action, where a reference of the new entity is used to link it to another entity Always link the new entity objects to the existing structure or to another new entity which was already linked to the structure Temporary IDs in $.actions[].id are used only for objects that are being created in the tranasction. The validity of the temporary IDs is only in the scope of the transaction. Temporary IDs must be non-numberic values, while permanent IDs are numeric values. Best Practices Although the transaction operation allows creating many entity objects at once, restrict its usage to entities at atmost 2 levels (Folders Level, Records Level, etc.), where having it restricted to a single level makes it more easily reusable Create a Case File (Saksmappe) linked to a primary Class (Klasse) and an ExternalID (EksternId) 1 level - Folder Level Create a Registry Entry (Journalpost) linked to a Correspondence Party (Korrespondansepart) 1 level - Records Level Create a Registry Entry (Journalpost), Document (Dokument) and Dokument Version (Dokumentversjon) 2 levels - Records and Document Level Avoid modifying in the same transacton unrelated entities link actions should be executed against the child object which is linking to an entity up the structure, not the other way around. Registry Entry is linking itself to the Case File, through the refMappe reference, not the Case File adding the Registry Entry to the list of its records. "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/general/onboarding/",
"title": "Onboarding",
"tags": [],
"description": "",
"content": "Integration Team Documaster Integration Team is reachable at [email protected]. This is the team that would support you in your integration effort and can be contacted for any issues or questions related to the Documaster Noark5 APIs.\nSetting up access Documaster supports a set of integration environments that a developer can be granted access to. Depending on the specific project and use cases, the setup process on Documaster side includes the following steps:\n client_id and client_secret, together with username and password for the integration user are setup on the integration servers and provided back to integration developers in a secure manner Documaster Archive integration instance endpoint is provide back to integration developers Any additional security measures required (VPN, 2-way TLS, etc.) coming as a specific requirement of the project are setup by Documaster team At least one Fonds (Arkiv) with a single Series (Arkivdel) is setup, to which the developers have access to. Details of the Fonds and Series are provided back to developers Integration user is assigned a particular Documaster Archive access group, which restricts access to certain functionality Having all the details above, you can try to aquire an access token.\n If you would be using our Client SDKs, please take a look at the next section.\n Client SDKs If you are using the Raw HTTP approach, you can proceed to Authentication and Authorization section.\n Authentication and Authorization "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/general/clientsdk/",
"title": "Client SDKs",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/operations/core/query/",
"title": "Query",
"tags": [],
"description": "",
"content": "Description POST /noark5/v1/query The POST /noark5/v1/query or as referred to in the documentation as query, is the operation for retrieving entitiy details from the Documaster Archive model. The operation allows querying for a single type of entity (or entities from a common type). Flexible query language allows retrieval of entities by complex relations traversal throught the archive structure.\nRequest HTTP Request Mapping Field Location Mandatory Type Description Authorization Header yes string access token aquired as part of the authentication call, prefixed with Bearer Content-Type Header yes string content type header, should always be provided as application/json X-Documaster-Error-Response-Type Header yes string custom header indicating that any error should be reported in JSON format, rather than the standard text format, should always be provided as application/json $.type Body yes array type of the core entity to be retrieved by the query (Arkiv, Arkivdel, Saksmappe, Journalpost, etc.). The query can refere to abstract types like AbstraktMappe, AbstraktRegistrering or NasjonalIdentifikator. $.limit Body yes number number of entity objects to be returned as a result of the query. Using limit that is too high may result in slow queries, so consider using a sensible value in accordance with the use case the query is used in. Maximum allowed value for the $.limit parameter is 500. $.offset Body no number offset of the first result of the query, used when an initial query results exceed the defined limit (indicated in the response by the $.hasMore element set to true) and a consequent calls wants to return the remaining entity objects $.query Body no string API specific query language expression using parameters defined in $.parameters, details in the Query Language section $.joins Body no object object in which each element name is an alias definition and the value is the reference field of the entity object to which the alias points. Take a look at the Query Joins section. $.joins.{alias} Body cond string join alias for the reference field in the value. The alias should be prefixed with #. $.parameters Body cond object object with elements for each parameter used in $.query, should always be provided in case specific query is used $.parameters.{paramName} Body cond string name of the parameter as used in the $.query element, the name of the element must be prefixed with @ indicating it is a parameter $.sortOrder[] Body no array list of sorting parameters to be applied on the returned entity objects, each of the elemetn $.sortOrder[].field and $.sortOrder[].order are required for the elements of the array $.sortOrder[].field Body cond string entity field used to sort over. Note that reference fields (prefixed with ref) cannot be used to sort over $.sortOrder[].order Body cond string sorting order, supported values are asc and desc $.publicUse Body no boolean true/false value indicating whether screened entities should be returned or not. Default is true indicating no screened entities will be returned. Example of a simple query using parameters can be found in the Getting Starter/First API Interaction section. Sample queries for every core entity type can be found in the Examples section. A more complex query utilizing parameters, joins and sorting follows. The sample query below queries for any type of Folders, through basic type AbstraktMappe type, that has 2 distinct secondary classes, referenced through refSekundaerKlasse field. One of the classes is with id 1111, while the other one has an class identity APIC2. The results are sorder by the folder identity element mappeIdent. Note that some of the response entities fields in the response are omitted from the sample for clarity.\nAlthough the example below uses joins, it is done mainly for illustrating possible operation uses. Most practical use cases do not require use of joins or complex deep reference chaining to filter results.\n HTTP Java C# Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/query HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;type\u0026#34;: \u0026#34;AbstraktMappe\u0026#34;, \u0026#34;limit\u0026#34;: 10, \u0026#34;query\u0026#34;: \u0026#34;#secClass1.id = @class1Id \u0026amp;\u0026amp; #secClass2.klasseIdent = @class2Ident\u0026#34;, \u0026#34;parameters\u0026#34; : { \u0026#34;@class1Id\u0026#34; : \u0026#34;1111\u0026#34;, \u0026#34;@class2Ident\u0026#34; : \u0026#34;APIC2\u0026#34; }, \u0026#34;joins\u0026#34;: { \u0026#34;#secClass1\u0026#34; : \u0026#34;refSekundaerKlasse\u0026#34;, \u0026#34;#secClass2\u0026#34; : \u0026#34;refSekundaerKlasse\u0026#34; }, \u0026#34;sortOrder\u0026#34; : [ { \u0026#34;field\u0026#34; : \u0026#34;mappeIdent\u0026#34;, \u0026#34;order\u0026#34; : \u0026#34;desc\u0026#34; } ] } Response\nHTTP/1.1 200 OK ... Content-Type: application/json HTTP/1.1 200 OK Connection: close Date: Mon, 06 Dec 2021 09:57:13 GMT Content-Type: application/json { \u0026#34;hasMore\u0026#34;: false, \u0026#34;results\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1122\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;10\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;mappeIdent\u0026#34;: \u0026#34;2021/7\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Case File - 2\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Second API created Case File\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;saksaar\u0026#34;: 2021, \u0026#34;sakssekvensnummer\u0026#34;: 7, \u0026#34;administrativEnhet\u0026#34;: \u0026#34;AD1\u0026#34;, \u0026#34;saksansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;saksstatus\u0026#34;: \u0026#34;B\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refPrimaerKlasse\u0026#34;: 681, \u0026#34;refArkivdel\u0026#34;: 688 } }, { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;981\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;14\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;mappeIdent\u0026#34;: \u0026#34;2021/6\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Case File\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;First API created Case File\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;saksaar\u0026#34;: 2021, \u0026#34;sakssekvensnummer\u0026#34;: 6, \u0026#34;administrativEnhet\u0026#34;: \u0026#34;AD1\u0026#34;, \u0026#34;saksansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;saksstatus\u0026#34;: \u0026#34;B\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refPrimaerKlasse\u0026#34;: 681, \u0026#34;refArkivdel\u0026#34;: 688 } } ] } Response Response of the operation is an array($.results), with the entity objects matching the specified $.query in the request. The matched entity objects are returned with their complete representation and no filtering on the entity fields is supported currently. Successful execution of the query would result in an HTTP 200 OK response as shown in the example above.\nHTTP Response Fields Field Location Mandatory Type Description Content-Type Header yes string content type header, always returned as application/json $.hasMore Body yes boolean indicates whether there are more results which are not returned as part of this response. This field should be used as an indicator that subsequent queries should be made with the required $.offset parameter set to the value of previous query $.offset value + previous query $.limit value. $.results[] Body yes array list of entities which match the query parameters. The array can be empty in case no entity matches the criteris. In case it is not empty, the objects below should contain the $.results[].id, $.results[].type, $.results[].version and $.results[].fields elements. $.results[].type Body yes string type of the entity being returned. The value matches the request $.type element if concrete types are used for the query. If a basic type is used, one of AbstraktMappe, AbstraktRegistrering or NasjonalIdentifikator), the response contains the real type of the entity. No basic types are returned in the response. $.results[].id Body yes string unique numeric identifier of the entity object in the Documaster Archive $.results[].version Body yes string version of the entity object, used for optimistic locking $.results[].fields.{fieldName} Body yes any all the fields of the entity objects, excluding reference fields (prefixed with ref) $.results[].links.{referenceField} Body no string important reference fields and their values identifying other entities in the structure. Note that not all reference fields are returned, check the documentation of the respective entity for reference fields that would be returned. As part of the resposne, business specific metadata is also returned for those entities that has it under $.results[].fields.virksomhetsspesifikkeMetadata. The table below provides the details about BSM values returned. The full path of the elemetns for BSM is shortened for clarity.\n Field Location Mandatory Type Description $..\u0026lt;bsm\u0026gt;.{bsmGroupID} Body no object element under $.results[].fields.virksomhetsspesifikkeMetadata.{bsmGroupID}, business specific metadata definition for the bsm groupID configured for the entity. BSM data is returned only for the following set of entities : Basic Folder(Mappe), Meeting Folder(Moetemappe), Case File (Saksmappe), Case Party (Sakspart), Basic Record (Registrering), Meeting Record (Moeteregistrering), Registry Entry (Journalpost), Correspondence Party (Korrespondansepart), Document (Dokument), and Class (Klasse) $..\u0026lt;bsm\u0026gt;.{bsmGroupID}.{bsmFieldID} Body no object element under $.results[].fields.virksomhetsspesifikkeMetadata.{bsmGroupID}.{bsmFieldID}, business specific metadata field part of the BSM group identified by {bsmGroupID} $..\u0026lt;bsm\u0026gt;.{bsmGroupID}.{bsmFieldID}.type Body no object element under $.results[].fields.virksomhetsspesifikkeMetadata.{bsmGroupID}.{bsmFieldID}.type, type of the BSM field, supported values are string, long, double, timestamp, and encrypted $..\u0026lt;bsm\u0026gt;.{bsmGroupID}.{bsmFieldID}.value Body no object element under $.results[].fields.virksomhetsspesifikkeMetadata.{bsmGroupID}.{bsmFieldID}.value, value of the BSM field assigned to the entity object Query Language Query Language Section\n"
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/general/authentication/",
"title": "Authentication and Authorization",
"tags": [],
"description": "",
"content": "Authentication Documaster Noark5 API is secured using OAuth2/OIC and more specifically the Resource Owner Passoword Grant. This is a standard flow part of the OAuth2 specification here https://datatracker.ietf.org/doc/html/rfc6749#section-4.3. This particular flow is used only in server-to-server integrations.\nEach integrating party should make sure the provided credentials as part of the onboarding process and kept secure on the integrating system server side. The credentials should never be embedded in any Web or mobile applications.\n OAuth2 scopes are not currently used to restrict access to the API, a single scope openid should be provided indicating that OIC capabilities should be enabled on the IDP side.\nAuthorization Documaster Archive has an internal security mechanism based on access groups. Access groups provide Read/Write/Update control over Noark5 entity model. As part of the project that the integration is implemented, specific permissions will be assigned to the integration access group and from there to the integration user.\nIDP Client SDKs Documaster provides IDP Client SDKs for both Java and .NET. Their code and samples can be found here:\n Java IDP Client SDK .NET IDP Client SDK Aquire an Access Token Retrieving an access token and a related refresh token, a call to the IDP endpoint /oauth2/token should be made with the provided credentials part of the onboarding.\nHTTP parameters mapping Field Location Value Authorization Header Base64 encoded client_id:client_secret Content-Type Header fixed value of application/x-www-form-urlencoded grant_type Body fixed value of password username Body username provided during onboarding process password Body password provided during onboarding process scope Body fixed value of openid HTTP Java C# Request\nPOST https://v2-34-0.local.documaster.tech/idp/oauth2/token HTTP/1.1 ... Authorization: Basic {client_id:client_secret} Content-Type: application/x-www-form-urlencoded grant_type=password \u0026amp;username={username} \u0026amp;password={password} \u0026amp;scope=openid Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;access_token\u0026#34;: \u0026#34;f295ace60f0a92808c496249a572a5784aa6af6f\u0026#34;, \u0026#34;expires_in\u0026#34;: 3600, \u0026#34;token_type\u0026#34;: \u0026#34;Bearer\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;openid\u0026#34;, \u0026#34;refresh_token\u0026#34;: \u0026#34;0a4a4f8633a8c9a289fca751e181eeaea5cd2455\u0026#34; } Query by CaseYear and CaseSequenceNumber\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;saksaar = @caseYear \u0026amp;\u0026amp; sakssekvensnummer = @caseSequenceNumber\u0026#34;, 1) .addQueryParam(\u0026#34;@caseYear\u0026#34;, \u0026#34;2021\u0026#34;) .addQueryParam(\u0026#34;@caseSequenceNumber\u0026#34;, \u0026#34;6\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Query Request by ExternalID\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;refEksternId.eksternID = @externalID\u0026#34;, 1) .addQueryParam(\u0026#34;@externalID\u0026#34;, \u0026#34;ISID:0000004572\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Query by CaseYear and CaseSequenceNumber\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;saksaar = @caseYear \u0026amp;\u0026amp; sakssekvensnummer = @caseSequenceNumber\u0026#34;, 1) .addQueryParam(\u0026#34;@caseYear\u0026#34;, \u0026#34;2021\u0026#34;) .addQueryParam(\u0026#34;@caseSequenceNumber\u0026#34;, \u0026#34;6\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Query Request by ExternalID\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;refEksternId.eksternID = @externalID\u0026#34;, 1) .addQueryParam(\u0026#34;@externalID\u0026#34;, \u0026#34;ISID:0000004572\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Using the Access Token Access tokens are supplied with each and every call to the Documaster Noark5 API in the Authorization HTTP header, in the format Bearer {{accessTokenIntegrator}}. Calls to the API without the header or with an invalid format or access token result in HTTP 401 Unauthorized code to be returned back.\nAccess Token Management Access tokens ($.accessToken in HTTP response) generated by Documaster IDP are with default lifetime of 3600 seconds, which is 1 hour. Refresh tokens are valid for 14 days.\nThe access tokens should be cached and reused across calls, for the period of their validity (1 hour). Refreshing the access token can be done in one of two ways - either aquire a new access token, or use the refresh token ($.refreshToken) to aquire a new access token.\nRecommended approach is to use the refresh token as shown in the samples below. The result of refreshing the access token using the refresh token is another set of both tokens. Refresh token should also be cached if that would be the chosen uproach for aquiring new access tokens.\nAccess token should be renewed in one of two scenarios - when an API call return HTTP 401 Unauthorized or on a regular basis. Recommended is the first scenario, since there is always a chance that access tokens may get invalidated on IDP side earlier than they are to expire.\n HTTP parameters mapping Field Location Value Authorization Header Base64 encoded client_id:client_secret Content-Type Header fixed value of application/x-www-form-urlencoded grant_type Body fixed value of refresh_token refresh_token Body refresh token received as a response of the Resource Owner Password Grant call above, from element $.refresh_token HTTP Java C# Request\nPOST https://v2-34-0.local.documaster.tech/idp/oauth2/token Authorization: Basic {client_id:client_secret} Content-Type: application/x-www-form-urlencoded grant_type=refresh_token \u0026amp;refresh_token=0a4a4f8633a8c9a289fca751e181eeaea5cd2455 Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;access_token\u0026#34;: \u0026#34;504e347005b2df9a8769b884c2bbfcb6fe4ab387\u0026#34;, \u0026#34;expires_in\u0026#34;: 3600, \u0026#34;token_type\u0026#34;: \u0026#34;Bearer\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;openid\u0026#34;, \u0026#34;refresh_token\u0026#34;: \u0026#34;6562ff52129474fe9029518b28bbb1a20f8c9ecc\u0026#34; } Query by CaseYear and CaseSequenceNumber\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;saksaar = @caseYear \u0026amp;\u0026amp; sakssekvensnummer = @caseSequenceNumber\u0026#34;, 1) .addQueryParam(\u0026#34;@caseYear\u0026#34;, \u0026#34;2021\u0026#34;) .addQueryParam(\u0026#34;@caseSequenceNumber\u0026#34;, \u0026#34;6\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Query Request by ExternalID\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;refEksternId.eksternID = @externalID\u0026#34;, 1) .addQueryParam(\u0026#34;@externalID\u0026#34;, \u0026#34;ISID:0000004572\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Query by CaseYear and CaseSequenceNumber\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;saksaar = @caseYear \u0026amp;\u0026amp; sakssekvensnummer = @caseSequenceNumber\u0026#34;, 1) .addQueryParam(\u0026#34;@caseYear\u0026#34;, \u0026#34;2021\u0026#34;) .addQueryParam(\u0026#34;@caseSequenceNumber\u0026#34;, \u0026#34;6\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Query Request by ExternalID\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;refEksternId.eksternID = @externalID\u0026#34;, 1) .addQueryParam(\u0026#34;@externalID\u0026#34;, \u0026#34;ISID:0000004572\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Before proceeding with making first calls to the API, short introduction to Documaster API model and operations needs to be covered.\n Model and Operatons Overview "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractfolder/folder/",
"title": "Basic Folder",
"tags": [],
"description": "",
"content": "Mappe "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/fonds/",
"title": "Fonds",
"tags": [],
"description": "",
"content": "Arkiv "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/fonds/fondscreator/",
"title": "Fonds Creator",
"tags": [],
"description": "",
"content": "Arkivskaper "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/classification/class/",
"title": "Class",
"tags": [],
"description": "",
"content": "Klasse "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/classification/",
"title": "Classification System",
"tags": [],
"description": "",
"content": "Klassifikasjonssystem "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/general/modeloverview/",
"title": "Model and Operations Overview",
"tags": [],
"description": "",
"content": "Documaster Model Documaster model closely follows the Noark5 stadnard. As in the Noark5 definition, at the very top of the entities objects structure are the Fonds (Arkiv).\nAs depicted on the diagram below, a Fonds (Arkiv) should have at least one Fonds Creator (Arkivskaper) and can have zero or many (0..*) linked Series (Arkivdel). Relations between entities can be referenced by two different names depending on the entity which is using the link. As in the example below, Fonds (Arkiv) link to Series (Arkivdel), when referenced from the Fonds is accessed by the reference name refArkivdel. When the same link is refferred to from the Series (Arkivde) it is accesed by the reference name refArkiv. All reference names start with the ref prefix.\nEach relation also has cardinality depicted on the diagrams, which indicates whether the relation is one-to-one, one-to-many or many-to-many.\nOperations Transaction Keeping data in consistent state, requires fine grained control over core entities creation and modification. Documaster Noark5 API v1 uses a single operation POST /noark5/v1/transaction to execute a sequencial series of actions towards the Noark5 structure in order to modify it. Transaction is considered successfully completed only when all the actions part of it are executed without an error. An error in any of the actions would result in rollback of the whole transaction, which means the data will remain the the state before the transaction.\nQuery Looking for entity objects in Documaster Archive is done using POST /noark5/v1/query operation. It allows retrieving one or more entitie object of the same type (or the same base type) using a comprehensive query language, that allows following relations between entities deep in the structure.\nUpload and Download Operations Documaster Archive provides two opeations for managing electronic docments:\n for uploading an electronic document - POST /noark5/v1/upload for downloading an electronic document - GET /noark5/v1/download Document metadata cannot be added to Documaster Archive before the electronic version of the document is uploaded (excluding use cases where real documents are not electronic).\n Code Lists, Business Specific Metadata (BSM), Bulk Operations Any other model data, that is not part of the core set of entities, in Documaster Noark5 API is managed through a separate set of API operations.\nKey Takeouts Core Noark5 entity objects are modified using POST /noark5/v1/transaction API (reffered in the documentation as transacton) Core Noark5 entity objects are queries using POST /noark5/v1/query API (reffered in the documentation as query) Relations Relations between entities are used for two purposes:\n link entities to each other (using POST /noark/v1/transaction operation, transaction::link action)\n query linked entities (using POST /noark/v1/query operation)\n While the Documaster implementation is flexible in regards of how references are used, as a general rule, when two objects are linked using POST /noark5/v1/transaction operation, the child entity (the one lower in the Noark5 structure), should reference an entity object up the structure. Querying the structure can be done using any references suitable.\n Now that all required details for the authentication, model and operations are covered, the next step would be making a couple of queries against the API.\n First API Interaction "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/series/",
"title": "Series",
"tags": [],
"description": "",
"content": "Arkivdel "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/",
"title": "Data Model",
"tags": [],
"description": "",
"content": "Chapter 3 Content Find out how to create and organize your content quickly and intuitively.\n"
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractrecord/basicrecord/",
"title": "Basic Record",
"tags": [],
"description": "",
"content": "Basisregistrering "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/general/firstcontact/",
"title": "First API Interaction",
"tags": [],
"description": "",
"content": "Execute First Query At this point, the integration developer should have the following details:\n client_id and client_secret, username and password, provided as part of the onboarding process Integration environment API HTTP endpoint Fonds ID (Arkiv) and Series ID (Arkivdel) Get Fonds Details Query any core Noark5 entity object in Documaster is done through the Query (POST /noark5/v1/query) operation. The operation allows selecting a single type of objects (or a set of different object, having the same base type).\nRetrieving the Fonds (Arkiv) details would require the following call to be made, where as input the already created Fonds ID (in this case 1088) is provided as a query parameter. Additionally an access token should have already beein aquired as part of the Authentication and Authorization process.\n Query Operation Data Model Overview HTTP parameters mapping Field Location Value Description Authorization Header Bearer {{accessToken}} access token aquired as part of the authentication call, prefixed with Bearer Content-Type Header value of application/json X-Documaster-Error-Response-Type Header value of application/json custom header indicating that any error should be reported in JSON format, rather than the standard text format $.type Body value of Arkiv the element defines the type of the entity the query is executed for, in this case it is Arkiv $.limit Body value of 1 maximum number of records the query should return $.query Body value of id = @fonds query written in the Documaster Noark5 API language, where @fondsID is a parameter supplied in $.parameters object $.parameters.@fondsID Body the parameter @fonds value to be used, in this case 1088, alredy existing Fonds ID defines the parameter value for @fondsID parameter of the query HTTP Java C# Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/query HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;type\u0026#34;: \u0026#34;Arkiv\u0026#34;, \u0026#34;limit\u0026#34;: 1, \u0026#34;query\u0026#34;: \u0026#34;id = @fondsID\u0026#34;, \u0026#34;parameters\u0026#34; : { \u0026#34;@fondsID\u0026#34; : \u0026#34;1088\u0026#34; } } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;hasMore\u0026#34;: false, \u0026#34;results\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;Arkiv\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1088\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;4\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;82281a12-3453-43d9-bca6-4ae0910bf5ec\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-29T12:54:32.303+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;Integration Fonds\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;API Created Fonds\u0026#34;, \u0026#34;arkivstatus\u0026#34;: \u0026#34;O\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34; }, \u0026#34;links\u0026#34;: {} } ] } The result of the query above returns the details of the Fonds (Arkiv) entity object that is already present. All the elements under $.results[].fields are the specific fields for the Fonds with their respective values. Details about the meaning of those fields can be found in Data Model/Core Entities/Fonds.\nGet Fonds Creator Now that the Fonds (Arkiv) details are retrieved, it would be important to see how relations between entity objects can be used for queries. As depicted on the diagram in Model and Operations Overview, each Fonds (Arkiv) should have a least one Fonds Creator (Arkivskaper), so the already existing Fonds with ID : 1088 should have a creator.\nQuerying for an object based on the objects it is linked to is done through the reference fields (fields prefixed with ref). Example queries how this is achived through the API follow.\nHTTP parameters mapping Only modified elements in the current request are shown, other headers/body elements remain the same\n Field Location Value Description $.type Body value of Arkivskaper the element defines the type of the entity the query is executed for, in this case it is Arkivskaper (Fonds Creator) $.query Body value of refArkiv.id = @fondsID query written in the Documaster Noark5 API language, where @fondsID is a parameter supplied in $.parameters object, containing the FondsID. The change with the previous query is that now the query uses refArkiv, refernece to the link between the Fonds (Arkiv) and the Fonds Creator (Arkivskaper), name as defined for the Fonds Creator (Arkivskaper) entity. refArkiv.id referes to the Fonds ID that is linked to the creator. HTTP Java C# Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/query HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;type\u0026#34;: \u0026#34;Arkivskaper\u0026#34;, \u0026#34;limit\u0026#34;: 5, \u0026#34;query\u0026#34;: \u0026#34;refArkiv.id = @fondsID\u0026#34;, \u0026#34;parameters\u0026#34; : { \u0026#34;@fondsID\u0026#34; : \u0026#34;1088\u0026#34; } } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;hasMore\u0026#34;: false, \u0026#34;results\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;Arkivskaper\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1089\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;93d0938f-e4bd-4fb2-9e31-2f41fe48ac9d\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-29T12:54:32.307+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;arkivskaperIdent\u0026#34;: \u0026#34;EXI\u0026#34;, \u0026#34;arkivskaperNavn\u0026#34;: \u0026#34;External Integrator\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refArkiv\u0026#34;: 1088 } } ] } Get Fonds Series Retrieving the Series (Arkivdel) linked to the Fonds (Arkiv) should be trivial, following the samples above. Entity type is Arkivdel and the relation from Series (Arkivdel) to Fonds (Arkiv) is again refArkiv. Details for this example are left out so it can be used as simple check point for basic query opertion usage knowledge.\n"
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/operations/core/upload/",
"title": "Upload",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/usage/perentity/casefile/",
"title": "Case File and Case Party",
"tags": [],
"description": "",
"content": "Creating Case File Case Files (Saksmappe) are created using transaction API, where in a single transaction the newly created case file must be linked to a single Series (Arkivdel), through reference Saksmappe::refArkivdel, and to one primary Class (Klasse), through reference Saksmappe::refPrimaerKlasse, part of the Classification System (Klassifikasjonssystem) linked to the series. Case File (Saksmappe) can be linked to more than one Class (Klasse) as secondary class, using the reference SaksMappe::refSekundaerKlasse. Additionally the example below is adding an External ID (EksternId), which is an identifier of the case file in an external system. ExternalID (EksternId) is not required to create a case file, but very useful if external identifiers are available, since the value can be used to search on it.\n transaction::save - new Case File (Saksmappe) transaction::link - link new case file to existing Series (Arkivdel) with id 688 transaction::link - link new case file to existing Class (Klasse) with id 681 as primary, through refPrimaerKlasse transaction::link - link new case file to existing Class (Klasse) with id 681 as secondary, through refSekundaerKlasse transaction::link - link new case file to existing Class (Klasse) with id 681 as secondary, through refSekundaerKlasse transaction::save - new ExternalID (EksternId) with external ID value of ISID:0000004573 transaction::link - link new externalID to newly created case file through refMappe reference field As a result of the transaction new Case File (Saksmappe) is created with id 1131.\nHTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/transaction HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;saksmappe-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;tittel\u0026#34;: \u0026#34;API Created Case File - 3\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Third API created Case File\u0026#34;, \u0026#34;administrativEnhet\u0026#34;: \u0026#34;AD1\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;saksmappe-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refArkivdel\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;688\u0026#34; }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;saksmappe-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refPrimaerKlasse\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;681\u0026#34; }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;saksmappe-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refSekundaerKlasse\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;1111\u0026#34; }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;saksmappe-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refSekundaerKlasse\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;1113\u0026#34; }, { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;EksternId\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;eksternId-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;eksterntSystem\u0026#34;: \u0026#34;Integrating System\u0026#34;, \u0026#34;eksternID\u0026#34;: \u0026#34;ISID:0000004573\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;EksternId\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;eksternId-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;saksmappe-temp-id-1\u0026#34; } ] } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;saksmappe-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1131\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;10\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;e8716b6e-3455-4148-870f-6435aa46cf5a\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-12-07T12:05:56.134+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;mappeIdent\u0026#34;: \u0026#34;2021/9\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Case File - 3\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Third API created Case File\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;saksaar\u0026#34;: 2021, \u0026#34;sakssekvensnummer\u0026#34;: 9, \u0026#34;saksdato\u0026#34;: \u0026#34;2021-12-07T12:05:56.149+0100\u0026#34;, \u0026#34;administrativEnhet\u0026#34;: \u0026#34;AD1\u0026#34;, \u0026#34;saksansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;saksansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;saksstatus\u0026#34;: \u0026#34;B\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refPrimaerKlasse\u0026#34;: 681, \u0026#34;refArkivdel\u0026#34;: 688 } }, \u0026#34;eksternId-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;EksternId\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1132\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;835e8ef5-7127-41dc-8a0c-09edcc0ea6c4\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-12-07T12:05:56.149+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;eksterntSystem\u0026#34;: \u0026#34;Integrating System\u0026#34;, \u0026#34;eksternID\u0026#34;: \u0026#34;ISID:0000004573\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refMappe\u0026#34;: 1131 } } } } Creating Case Party and adding it to a Case File Case Files (Saksmappe) can have multiple Case Party (Sakspart) entity objects linked to them. Case Party (Sakspart) represents a person related to the case file in a particular role.\n transaction::save - new Case Party (Sakspart) transaction::link - link new case party to existing Case File (Saksmappe) with id 1131 through refMappe reference field As a result of the transaction new Case Party (Saks[art) is created with id 1136 and associated with the Case File (Saksmappe).\nHTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/transaction HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Sakspart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;sakspart-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;sakspartNavn\u0026#34;: \u0026#34;Kari Nordmann\u0026#34;, \u0026#34;sakspartRolle\u0026#34;: \u0026#34;Handler\u0026#34;, \u0026#34;epostadresse\u0026#34;: \u0026#34;[email protected]\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Sakspart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;sakspart-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;1131\u0026#34; } ] } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;sakspart-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Sakspart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1136\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;37baa8e6-b993-4137-9a2a-791a5991f1d1\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-12-09T14:04:15.316+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;sakspartNavn\u0026#34;: \u0026#34;Kari Nordmann\u0026#34;, \u0026#34;sakspartRolle\u0026#34;: \u0026#34;Handler\u0026#34;, \u0026#34;epostadresse\u0026#34;: \u0026#34;[email protected]\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refMappe\u0026#34;: 1131 } } } } Query a Case File by ExternalID Retrieving a Case File (Saksmappe) that has a specific ExternalID (EksternId) is done using the refEksternId reference field of CaseFile (Saksmappe).\nHTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/query HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;limit\u0026#34;: 1, \u0026#34;query\u0026#34;: \u0026#34;refEksternId.eksternID = @externalID\u0026#34;, \u0026#34;parameters\u0026#34; : { \u0026#34;@externalID\u0026#34; : \u0026#34;ISID:0000004573\u0026#34; } } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;hasMore\u0026#34;: false, \u0026#34;results\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1131\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;10\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;e8716b6e-3455-4148-870f-6435aa46cf5a\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-12-07T12:05:56.134+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;mappeIdent\u0026#34;: \u0026#34;2021/9\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Case File - 3\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Third API created Case File\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;saksaar\u0026#34;: 2021, \u0026#34;sakssekvensnummer\u0026#34;: 9, \u0026#34;saksdato\u0026#34;: \u0026#34;2021-12-07\u0026#34;, \u0026#34;administrativEnhet\u0026#34;: \u0026#34;AD1\u0026#34;, \u0026#34;saksansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;saksansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;saksstatus\u0026#34;: \u0026#34;B\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refPrimaerKlasse\u0026#34;: 681, \u0026#34;refArkivdel\u0026#34;: 688 } } ] } Query a Case File by 2 Secondary Classes The query below is querying for a Case File (Saksmappe) linked to two distinct secondary classes (Klasse). The query uses joins to perform the filtering. Response is omitted since it is the same as the example from the previous example.\nHTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/query HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;limit\u0026#34;: 2, \u0026#34;query\u0026#34;: \u0026#34;#secClass1.id = @class1 \u0026amp;\u0026amp; #secClass2.id = @class2\u0026#34;, \u0026#34;parameters\u0026#34; : { \u0026#34;@class1\u0026#34; : \u0026#34;1111\u0026#34;, \u0026#34;@class2\u0026#34; : \u0026#34;1113\u0026#34; }, \u0026#34;joins\u0026#34;: { \u0026#34;#secClass1\u0026#34; : \u0026#34;refSekundaerKlasse\u0026#34;, \u0026#34;#secClass2\u0026#34; : \u0026#34;refSekundaerKlasse\u0026#34; }, \u0026#34;sortOrder\u0026#34; : [ { \u0026#34;field\u0026#34; : \u0026#34;mappeIdent\u0026#34;, \u0026#34;order\u0026#34; : \u0026#34;desc\u0026#34; } ] } "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/usage/perusecase/registryentryanddocument/",
"title": "Create Registry Entry and Document",
"tags": [],
"description": "",
"content": "Usecase Details Common usecase for an integrating system is to create a Registry Entry(Journalpost) and a single Document(Dokument) with a single DocumentVersion(Dokumentversjon) and an electronic document uploaded. The Registry Entry (Journalpost) is linked to an existing Case File (Saksmappe).\nAccomplishing this through the API is done following a set of steps outlined in the diagram below.\nAuthentication and Authorization (1, 2) Aquiring an OAuth2 access token is done through the configured Identity Provider (IDP) used by the customer. Details on how to get the access token, how it should be cached and renewed can be found in Authentication and Authorization section of the documentation.\nRetrieve existing Case File (3, 4, 5) Already created case files in the Documaster system can be found using the POST /query operation. Recommended case files query criteria would be the case year and sequence number (saksaar and sakssekvensnummer) or an externalID (through refExternId).\nExamples below retrieve a case with externalID : ISID:0000004572, case year : 2021 and sequence number : 6.\nHTTP Java Query Request by CaseYear and CaseSequenceNumber\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/query HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;limit\u0026#34;: 1, \u0026#34;query\u0026#34;: \u0026#34;saksaar = @caseYear \u0026amp;\u0026amp; sakssekvensnummer = @caseSequenceNumber\u0026#34;, \u0026#34;parameters\u0026#34; : { \u0026#34;@caseYear\u0026#34; : \u0026#34;2021\u0026#34;, \u0026#34;@caseSequenceNumber\u0026#34; : \u0026#34;6\u0026#34; } } Query Request by ExternalID\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/query HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;limit\u0026#34;: 1, \u0026#34;query\u0026#34;: \u0026#34;refEksternId.eksternID = @externalID\u0026#34;, \u0026#34;parameters\u0026#34; : { \u0026#34;@externalID\u0026#34; : \u0026#34;ISID:0000004572\u0026#34; } } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;hasMore\u0026#34;: false, \u0026#34;results\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;Saksmappe\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;981\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;31b474d1-9474-4139-b1e6-2d0ffb77b2e0\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-25T13:51:10.494+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;mappeIdent\u0026#34;: \u0026#34;2021/6\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Case File\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;First API created Case File\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;saksaar\u0026#34;: 2021, \u0026#34;sakssekvensnummer\u0026#34;: 6, \u0026#34;saksdato\u0026#34;: \u0026#34;2021-11-25\u0026#34;, \u0026#34;administrativEnhet\u0026#34;: \u0026#34;AD1\u0026#34;, \u0026#34;saksansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;saksansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;saksstatus\u0026#34;: \u0026#34;B\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refPrimaerKlasse\u0026#34;: 681, \u0026#34;refArkivdel\u0026#34;: 688 } } ] } Query by CaseYear and CaseSequenceNumber\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;saksaar = @caseYear \u0026amp;\u0026amp; sakssekvensnummer = @caseSequenceNumber\u0026#34;, 1) .addQueryParam(\u0026#34;@caseYear\u0026#34;, \u0026#34;2021\u0026#34;) .addQueryParam(\u0026#34;@caseSequenceNumber\u0026#34;, \u0026#34;6\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Query Request by ExternalID\n// client is an instance of NoarkClient QueryResponse\u0026lt;Saksmappe\u0026gt; queryResults = client.query(Saksmappe.class, \u0026#34;refEksternId.eksternID = @externalID\u0026#34;, 1) .addQueryParam(\u0026#34;@externalID\u0026#34;, \u0026#34;ISID:0000004572\u0026#34;) .execute(); if (!queryResults.getResults().isEmpty()) { Optional\u0026lt;Saksmappe\u0026gt; first = queryResults.getResults().stream().findFirst(); // ID of the first case file, assuming only one is returned String caseFileID = first.get().getId(); } Important detail to be retrieved from the response is the ID of the existing case file - $.results[0].id in this case equal to 981. Client SDKs faciliate the extraction of the ID from the response as shown in the examples.\nCreating new RegistryEntry and linked Correspondence Party (6, 7, 8) Creating a new registry entry is described in details in this example, here it is provided for completenes. Bear in mind that the retrieved CaseFile ID (Saksmappe) should be used to link the newly created RegistryEntry to it. This is done (in the case of the raw HTTP API) through the element $.actions[1].linkToId as can be seen below.\nHTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/transaction HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;981\u0026#34; }, { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;korrespondansepart-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;korrespondanseparttype\u0026#34;: \u0026#34;EA\u0026#34;, \u0026#34;korrespondansepartNavn\u0026#34;: \u0026#34;Correspondence Party Name\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;korrespondansepart-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refRegistrering\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34; } ] } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;journalpost-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;994\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;cf7eb80b-5c58-4418-b3e5-fb09c978e794\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-25T14:18:55.674+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;registreringsIdent\u0026#34;: \u0026#34;2021/9\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;registreringsDato\u0026#34;: \u0026#34;2021-11-25T14:18:55.714+0100\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;journalaar\u0026#34;: 2021, \u0026#34;journalsekvensnummer\u0026#34;: 9, \u0026#34;journalpostnummer\u0026#34;: 1, \u0026#34;journalansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;journalansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34;, \u0026#34;journalstatus\u0026#34;: \u0026#34;J\u0026#34;, \u0026#34;skjermKorrespondanseParterEInnsyn\u0026#34;: false }, \u0026#34;links\u0026#34;: { \u0026#34;refMappe\u0026#34;: 981 } }, \u0026#34;korrespondansepart-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;995\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;3\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;ff3ec7de-6451-4347-88e2-0b81de6f1b75\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-25T14:18:55.718+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;korrespondanseparttype\u0026#34;: \u0026#34;EA\u0026#34;, \u0026#34;korrespondansepartNavn\u0026#34;: \u0026#34;Correspondence Party Name\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refRegistrering\u0026#34;: 994 } } } } Upload an electronic document (9, 10, 11) Uploading a document is done using the POST /upload operation. The file content is streamed in the API request and as a result the API returns a new unique identifier of this electronic document. The document is deleted from Documaster Archive in case it is not linked for a certain period of time to a DocumentVersion (Documentverjion) and from there to a Document (Dokument).\nThe ID of the electronic document is not the same ID as the one of the Document (Dokument) entity objects. Document (Dokument) entity object is metadata describing the document, while the ID returned as a result of this operation identfies the actually uploaded document.\n HTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/upload HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Disposition: attachment; filename=\u0026#34;sample-document.pdf\u0026#34;; filename*=utf-8\u0026#39;\u0026#39;sample-document.pdf Content-Type: application/octet-stream ... binary file content ... Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;id\u0026#34;:\u0026#34;999\u0026#34; } ID of the electronic document is extracted from $.id of the response.\nCreating a Document and DocumentVersion and link them to RegistryEntry (12, 13) As a final set of steps to be executed as part of this use case, a Document (Dokument) and DocumentVersion (Dokumentversjion) should be created. The electronic document ID, created in the previous step is now used in the creation of the DocumentVersion(Dokumentversjion) through the field $.actions[?(@.action == 'save' \u0026amp;\u0026amp; @.type=='Dokumentversjon')].fields.referanseDokumentfil, which is a field of DocumentVersion.\nHTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/transaction HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Dokument\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;dokument-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;tittel\u0026#34;: \u0026#34;sample-document.pdf\u0026#34;, \u0026#34;tilknyttetRegistreringSom\u0026#34;: \u0026#34;V\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Dokument\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;dokument-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refRegistrering\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;994\u0026#34; }, { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Dokumentversjon\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;dokumentversjon-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;format\u0026#34;: \u0026#34;pdf\u0026#34;, \u0026#34;referanseDokumentfil\u0026#34;: \u0026#34;1079\u0026#34;, \u0026#34;variantformat\u0026#34;: \u0026#34;P\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Dokumentversjon\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;dokumentversjon-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refDokument\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;dokument-temp-id-1\u0026#34; } ] } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;dokument-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Dokument\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1081\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;7\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;8775e127-29ad-48de-a549-7a0c75ab0bd2\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-25T14:58:35.242+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;dokumentstatus\u0026#34;: \u0026#34;B\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;sample-document.pdf\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;tilknyttetRegistreringSom\u0026#34;: \u0026#34;V\u0026#34;, \u0026#34;dokumentnummer\u0026#34;: 2 }, \u0026#34;links\u0026#34;: { \u0026#34;refRegistrering\u0026#34;: 994 } }, \u0026#34;dokumentversjon-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Dokumentversjon\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;1082\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;5\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;f20796a3-3550-4c87-85dd-36bc18cc65f7\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-25T14:58:35.250+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;versjonsnummer\u0026#34;: 1, \u0026#34;variantformat\u0026#34;: \u0026#34;P\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;pdf\u0026#34;, \u0026#34;kryptertDokument\u0026#34;: false, \u0026#34;sjekksum\u0026#34;: \u0026#34;59844ce7572b1411445179c25e4182e328e43391d733782828277f22e340166b\u0026#34;, \u0026#34;sjekksumAlgoritme\u0026#34;: \u0026#34;SHA-256\u0026#34;, \u0026#34;filstoerrelse\u0026#34;: 3191, \u0026#34;filnavn\u0026#34;: \u0026#34;sample-document.pdf\u0026#34;, \u0026#34;referanseDokumentfil\u0026#34;: \u0026#34;1079\u0026#34;, \u0026#34;innholdstype\u0026#34;: \u0026#34;application/pdf\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refDokument\u0026#34;: 1081 } } } } "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/operations/core/download/",
"title": "Download",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/usage/",
"title": "Examples",
"tags": [],
"description": "",
"content": "Chapter 4 Content Find out how to create and organize your content quickly and intuitively.\n"
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/usage/perentity/",
"title": "Per Entity",
"tags": [],
"description": "",
"content": "Examples per entity "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/usage/perusecase/",
"title": "Per Usecase",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/usage/perentity/registryentry/",
"title": "Registry Entry",
"tags": [],
"description": "",
"content": "Creating Registry Entry Registry entries are created using transaction API, where in a single transaction the newly created registry entry should be linked to a case file (Saksmappe) or a basic folder (Mappe). Bear in mind that the registry entry can be under only one folder. Newly created registry entry requires at least one correspondence party (Korrespondansepart) to be created and associated with the registry entry. The link is done using transaction::link action following the guidelines to use newly created entry reference field to parent entry (Korrespondansepart::refRegistrering), rather than parent entry reference field (Journalpost::refKorrespondansepart). Take a look at the Fields section of this document for details about the mandatory/optional fields for registry entries.\nDocument (Dokument) entities are associated to Registry entries during documents creation. Examples how a document is created and associated to a registry entry can be found here.\n Correspondence Party Entity Document Entity Document Version Entity HTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/transaction HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refMappe\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;691\u0026#34; }, { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;korrespondansepart-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;korrespondanseparttype\u0026#34;: \u0026#34;EA\u0026#34;, \u0026#34;korrespondansepartNavn\u0026#34;: \u0026#34;Correspondence Party Name\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;korrespondansepart-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refRegistrering\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;journalpost-temp-id-1\u0026#34; } ] } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;journalpost-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;938\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;8\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;35926f91-96d2-40d7-961e-9ffb368673af\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.933+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;registreringsIdent\u0026#34;: \u0026#34;2021/5\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Registry Entry Description\u0026#34;, \u0026#34;registreringsDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.950+0100\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;journalaar\u0026#34;: 2021, \u0026#34;journalsekvensnummer\u0026#34;: 5, \u0026#34;journalpostnummer\u0026#34;: 5, \u0026#34;journalansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;journalansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34;, \u0026#34;journalstatus\u0026#34;: \u0026#34;J\u0026#34;, \u0026#34;skjermKorrespondanseParterEInnsyn\u0026#34;: false }, \u0026#34;links\u0026#34;: { \u0026#34;refMappe\u0026#34;: 691 } }, \u0026#34;korrespondansepart-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Korrespondansepart\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;939\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;3\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;3f7bad64-9560-45d2-82a5-4e5fb06a5c13\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.953+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;korrespondanseparttype\u0026#34;: \u0026#34;EA\u0026#34;, \u0026#34;korrespondansepartNavn\u0026#34;: \u0026#34;Correspondence Party Name\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refRegistrering\u0026#34;: 938 } } } } Update Registry Entry Updating a registry entry is done through transaction::save action in the same way it is used to create it, with the difference that the actual id of the registry entry should be used (returned in create call response in $.saved.{tempIDofRegistryEntry}.id). The example below show an update of the registry entry (chaning the description) and linking a new Address (Adresse).\nHTTP Request\nPOST https://v2-34-0.local.documaster.tech:8083/rms/api/public/noark5/v1/transaction HTTP/1.1 ... Authorization: Bearer {{accessTokenIntegrator}} Content-Type: application/json X-Documaster-Error-Response-Type: application/json { \u0026#34;actions\u0026#34;: [ { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;938\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;beskrivelse\u0026#34;: \u0026#34;Updated Registry Entry Description\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;save\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Adresse\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;adresse-temp-id-1\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;adresseKnr\u0026#34;: \u0026#34;0301\u0026#34;, \u0026#34;postnr\u0026#34;: \u0026#34;0301\u0026#34;, \u0026#34;poststed\u0026#34;: \u0026#34;Oslo\u0026#34;, \u0026#34;adressenavn\u0026#34;: \u0026#34;Rådhusplassen\u0026#34;, \u0026#34;nummer\u0026#34;: \u0026#34;1\u0026#34; } }, { \u0026#34;action\u0026#34;: \u0026#34;link\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Adresse\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;adresse-temp-id-1\u0026#34;, \u0026#34;ref\u0026#34;: \u0026#34;refRegistrering\u0026#34;, \u0026#34;linkToId\u0026#34;: \u0026#34;938\u0026#34; } ] } Response\nHTTP/1.1 200 OK Content-Type: application/json { \u0026#34;saved\u0026#34;: { \u0026#34;938\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Journalpost\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;938\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;9\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;35926f91-96d2-40d7-961e-9ffb368673af\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:14:05.933+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;registreringsIdent\u0026#34;: \u0026#34;2021/5\u0026#34;, \u0026#34;tittel\u0026#34;: \u0026#34;API Created Registry Entry\u0026#34;, \u0026#34;beskrivelse\u0026#34;: \u0026#34;Updated Registry Entry Description\u0026#34;, \u0026#34;registreringsDato\u0026#34;: \u0026#34;2021-11-24\u0026#34;, \u0026#34;dokumentmedium\u0026#34;: \u0026#34;E\u0026#34;, \u0026#34;journalaar\u0026#34;: 2021, \u0026#34;journalsekvensnummer\u0026#34;: 5, \u0026#34;journalpostnummer\u0026#34;: 5, \u0026#34;journalansvarlig\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;journalansvarligBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;journalposttype\u0026#34;: \u0026#34;U\u0026#34;, \u0026#34;journalstatus\u0026#34;: \u0026#34;J\u0026#34;, \u0026#34;skjermKorrespondanseParterEInnsyn\u0026#34;: false }, \u0026#34;links\u0026#34;: { \u0026#34;refMappe\u0026#34;: 691 } }, \u0026#34;adresse-temp-id-1\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Adresse\u0026#34;, \u0026#34;id\u0026#34;: \u0026#34;967\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;2\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;uuid\u0026#34;: \u0026#34;7276dd75-d4aa-4b0c-956c-0ae31ee233b0\u0026#34;, \u0026#34;opprettetDato\u0026#34;: \u0026#34;2021-11-24T14:38:49.625+0100\u0026#34;, \u0026#34;opprettetAv\u0026#34;: \u0026#34;External Integrator ACME\u0026#34;, \u0026#34;opprettetAvBrukerIdent\u0026#34;: \u0026#34;e6e6318e-fdcb-41cb-ae3a-1940f98ea153\u0026#34;, \u0026#34;adresseKnr\u0026#34;: \u0026#34;0301\u0026#34;, \u0026#34;postnr\u0026#34;: \u0026#34;0301\u0026#34;, \u0026#34;poststed\u0026#34;: \u0026#34;Oslo\u0026#34;, \u0026#34;adressenavn\u0026#34;: \u0026#34;Rådhusplassen\u0026#34;, \u0026#34;nummer\u0026#34;: \u0026#34;1\u0026#34; }, \u0026#34;links\u0026#34;: { \u0026#34;refRegistrering\u0026#34;: 938 } } } } "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/",
"title": "Core Entities",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractfolder/",
"title": "Folders",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractfolder/meetingfolder/",
"title": "Meeting Folder",
"tags": [],
"description": "",
"content": "Moetemappe "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractfolder/meetingfolder/meetingparticipant/",
"title": "Meeting Participant",
"tags": [],
"description": "",
"content": "Moetedeltaker "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractrecord/meetingrecord/",
"title": "Meeting Record",
"tags": [],
"description": "",
"content": "WIP "
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/model/entities/abstractrecord/",
"title": "Records",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/tags/documentation/",
"title": "documentation",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/tags/",
"title": "Tags",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/tags/tutorial/",
"title": "tutorial",
"tags": [],
"description": "",
"content": ""
},
{
"uri": "https://myakimov.github.io/documaster-api-docs/categories/",
"title": "Categories",
"tags": [],
"description": "",
"content": ""
}]