This is a brief overview of folder structures in enaio redline 4.0. We also describe how to migrate existing 3.3 structures to 4.0 structures.
...
The new folder structures look very similar to what you saw in previous version of enaio redline. However, you can now group objects in many more ways. You can also create sums, such as the value of invoices by month, or vacation leave taken by year. For more information, refer to the Structure Service API - Folder Structure API page.
Changes to the Schema
In version 4.0, there is still only one context folder per object type group, and there is no need to create additional folder object types.
New folder structures are configured in the context folder, in the 'Folder structure' view area. For more information about configuration possibilities, refer to the Structure Service API - Folder Structure API page.
The new enaio structure-service provides the client with a folder structure. For more information, refer to the online Help or the online developer documentation.
Changes to the Filing Locations
...
If the last release of enaio version 3.3 (2018-04-25) has not been installed, you must do this first. As always, check all release digests to make sure you don't skip any necessary steps.
...
- You must extend the document types by the relevant index data fields.
- You may need to create corresponding catalogs.
- The filing location relations for all document types must allow the creation of instances of the document type in the context folder.
- You may need to extend the document type forms with the new fields.
- You may need to modify scripts accordingly.
You must create an appropriate structure element definition for each context folder. For more information, refer to Structure Service API - Folder Structure API.
Note title Important Note If there are regular folder types in the schema that you would like to be context folders in version 4.0, and instances of them already exist, then the information stored in the elasticsearch database about all instances that are a child object of these folder-instances have to be extended by the context folder information. This is done by reindexing the corresponding objects. If new fields are added to the objects and they get enriched during the migration process using the Transformation API, this reindexing happens automatically. If not, you must start the reindexing manually, using the "Subsequent full text indexing" operation in enterprise-manager.
...
After all the object types have been modified and the schema activated on the server, you can execute the update to version 4.0.
After completing the update, also follow the steps in Additional Manual Steps for Updating to enaio redline 4.0.
| Info | ||
|---|---|---|
| ||
|
...
The following example updates all objects with the given IDs of the type 'mydocument' and sets the index data as given by the data object in JSON.
{ "query": { "expression" : ["ID1","ID2","ID3"], "type" : "mydocument" }, "data": { "stringstatefield": { "value" : "newvalue" }, "numbervaluefield": { "value" : 42 } } }Query object
The query expression supports a list of object IDs or a simple query using the same syntax as ResultService.getQueryResult. The type property must be set for the simple query. It is used as type for the ID list. For the ID list, you can set the type to sysobject.
...
Using the data object, you can describe one or more changes in the custom index data field. The fields are identified by the technical name of the field. For example, you would use this data object to change the value of the field 'name' to the fixed value 'Max'.
{ "data": { "name": { "value" : "Max" }, } }The data object supports the following properties.
...
The following JSON code example moves any object with a given ID to the location given by 'PARENTID'.
{ "query": { "expression" : ["ID1","ID2","ID3"], "type" : "mydocument" }, "moveto" : "PARENTID" }
Other possible move targets are the fixed root target and the context target. The context move target moves the object as a direct child of the context folder.
...
The following example shows the use of a parent reference and a query that uses a parent property.
{ "query": { "expression" : "personalfile.typefield=employee;statefield=active"], "type" : "document" }, "data": { "statefield": { "value" : "inactive" },
"stringfield": { "parentref" : "personalfile.anotherstringfield" } }, "moveto":"context", "options": { "breakonerror" : true } }Using this update json will lead to this result:
...
Example for delete by id:
{ "query": { "expression" : ["ID1","ID2","ID3"] } }The accepted json is the same as used in the update endpoint. But moveto and data properties will be ignored. Especially the query object is described in the update operation. See DmsBatchService.updateObjects.
...