Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X
Hi all,
I currently working on a custom Re-Import parser for the I10.2 gateway.
During inspection of
I got a little confused about the ID handling.
There are 3 different "IDs" in the iif File schema
...
<mks:Children>
<mks:Item mksid="143127" id="3" prototype="CONTENT">
<mks:Field name="IssueId"/>
...
Name | Assumed meaning |
id | the temporary ID of the item node that is generated during the parsing process. ( more or less a enumerator ) |
mksid | obviously the integrity internal ID used for mapping with the server's values |
IssueID | maybe the same as the mksid ??? |
Can anybody help me clarifying this?
I'd like to know which one of these ID I can/must fill in my parser script with what values to get a working re-import.
Hello Matthias,
In which files did you see which of those IDs? I suspect that you are looking at a DSD, based on the tags listed.
In the context you gave, I believe that mksid is the Integrity internal ID, and id is the parser internal id. I'm not at the point of rolling my own parsers, yet, so I haven't played around with that very much.
I believe the tag <mks:Field name="IssueId"/> indicates that the parser expects the mapping template (e.g. <ClientInstall>/config/gateway/mappings/Sample_Requirement_Document_Import_Reimport.xml) to have a section that looks like the following: <link-field external="IssueId" field-type="id" /> as a sub-tag of the <map name="Document">
Regards,
Kael
Hi Kael,
the code snippet above is from the intermediate IIF file that is produced by the gateway in debug mode. It shows the result of a Word re-import based on the solution's sample parsers and templates.
My general problem was the reimport use-case where there is an item ID stored and read out in the word document and a "mapping" ID in Integrity.
I initially thought my parser had to find all ID's in the Word document and store them into either id position (attribute or field) in the iif-document.
Meanwhile I learned, that the re-import needs only the document's ID specified. There is no "direct" comparison based on the ID done in the gateway, but a (xml-)tree comparison between the currently generated IIF and the one stored in the document item during the last import (source-document.iif).
Knowing this I do not bother any more in my parser filling an node's ID correctly in what field or attribute so ever and it still works.
Nevertheless I'd like to know the concrete reason for this Field and attribute mixup so I can avoid future disturbances by simply removing the stuff that is not needed anyway.