1 DokumentNavet package content and structure
- 1.1 Package XML content
2 External Domain configuration
3 Importing process
- 3.1 Correct Object Structure for Import in Tree
- 3.2 Uploading package
- 3.3 Import process
4 Matching Objects Example
- 4.1 DocumentNavet import to change class of matched object

DokumentNavet package content and structure

Package for upload to HDC have to be a .zip file.

This .zip file should have top folder of any name and inside all files for import like TIF and TAF's (raster files) and XML files (configuration files).

Package XML content

<?xml version="1.0" encoding="utf-8"?>
    <HDocDatabase>
        <LogDocs>
            <LogDoc ID="" ExternalId="d423f317-01d7-4953-a6b1-cca1f105cad2" Status="add" DocType="VENTILATION">
                <DocAttr Name="hd_docname" Value="V57.1-002" />
                <DocAttr Name="hd_docfilename" Value="V57-1-002.dwg" />
                <DocAttr Name="hd_docdescr" Value="ENTRÉPLAN 0tr, LUFTBEHANDLING " />
                <DocAttr Name="hd_docrevdescr" Value="" />
                <DocAttr Name="hd_docdate" Value="2009-01-16" />
                <DocAttr Name="hd_docrevdate" Value="2012-04-19" />
                <DocAttr Name="hd_scale_id" Value="1:100" />
                <DocAttr Name="hd_consname" Value="" />
                <DocAttr Name="hd_projnr" Value="" />
                <DocAttr Name="hd_doccustom1" Value="" />
                <DocAttr Name="hd_doccustom2" Value="" />
                <DocAttr Name="hd_doccustom3" Value="" />
                <DocAttr Name="hd_doccustom4" Value="A1" />
                <DocAttr Name="document_type_id" Value="Ventilation" />
                <PhysDoc AttachFrom="V57-1-002-V57-1-011.tif" Status="add" />
            </LogDoc>
        </LogDocs>
        <Links>
            <ObjDocLinks>
                <Link Status="add">
                <LogDoc ID="" />
                <DBObject Type="hdv_h1_prop">
                    <ObjectAttr Name="fi2prop_name" Value="2394 - Dragarbrunn 20:2" />
                    <DBObject Type="hdv_h1_struct">
                        <ObjectAttr Name="fi2struct_name" Value="01" />
                        <DBObject Type="hdv_h1_floor">
                            <ObjectAttr Name="fi2spsys_name" Value="01" />
                        </DBObject>
                    </DBObject>
                </DBObject>
                </Link>
            </ObjDocLinks>
        </Links>
    </HDocDatabase>

Please note the header and provided ID

^{<LogDoc ID="" ExternalId="d423f317-01d7-4953-a6b1-cca1f105cad2" Status="add" DocType="VENTILATION">}

^{ExternalId will be returned in the import report so that each document can be identified in the external system.}

This is unusual change in basic rule, where we store only one external ID.

For DocNavet purposes, we have:

External document ID + HyperDoc ID that is passed from DokNavet
If HyperDoc ID is not passed, a new document is created

In that case, HyperDoc ID is already an external ID, but if DokNavet does not have HyperDoc ID stored yet, we need additional "external ID" so that we are able to match the document data sent back from HyperDoc once it was added. After update, we will send back both External and HyperDoc ID (as EID ID - see external domain configuration and TOBIS section).

Note: Normally, we would receive "external object" with its ID. We would register that ID as external and recognize it with future requests. Since we needed support for legacy documents exported to HyperDoc Classic, this "double ID" solution was added.

Documents matching logic:

If ID is present in source XML and object with such ID is found in target database then this object is updated.
If ID is present in source XML but there is no such object in target database new object is created with ID from XML.
if ID is not present in XML then new object is created with random ID.

External Domain configuration

Importing process

Correct Object Structure for Import in Tree

Before importing make sure you have correct object structure visible in a Tree view Tesslet.

This import will import only documents.

Structure must be prepared based on information provided in xml files. Matching for hierarchy is done in non case-sensitive matter.
But imported documents are matched case sensitive.

Below, screen presenting correct structure for sample Dokumentnavet package.

Uploading package

Import process

Choosing correct Perspective in which Objects structure is ready) is crucial for this import to perform.

Matching Objects Example

Looking at the sample import package, we can see the following linking path:

F101 -> B -> 20

HDC requires, that the first object is unique. We will look for object of indicated class and value F101.

Coresponding structure should be present in HDC database:

For Fastighet, we indicate field prop_fullname as our target field with (label Popularnamn) – Match OK
F101 -> B -> 20

For Bygnad, we indicate field: struct_custom1 -> label Nummer

F101 -> B -> 20

Match for object B would FAIL in that case.

Other object should be matched in similar way. Please note, that HDC will take a source field indicated in the package, look for mapping as configured for given domain, and at the end try to match object by specified field.

DocumentNavet import to change class of matched object

New import option Convert class of objects matched by Guid Field for DocumentNavet type of import has been added.

When used, if imported document is matched by Guid Field (present already in database) and it's class is different in incoming package (than in actual state of database) then document class will change along with any other update.
Both document subclasses must be added in External Domain configuration.

After conversion it will still be same object (same hdid) but with different class after import.

HyperDoc (HDC) Manual

DokumentNavet data import