Topic
  • 6 replies
  • Latest Post - ‏2013-06-21T20:06:35Z by BillTidy
DOORSnoob
DOORSnoob
1 Post

Pinned topic Retaining Unique IDs when importing XML files

‏2013-04-18T13:35:05Z |

Hi,

I have created a set of requirements for a customer and I have provided them with the module via the RIF feature for their review. The IDs in the module I created are not sequential since I have deleted/inserted requirements throughout the module. The problem I'm having is that when the customer imports the XML file into their database, the module that they create has a sequential set of unique IDs that do not match the unique IDs I created.

I'm not sure if I'm missing something in creating the XML file or if the problem is at the customer end, when importing the XML file. But, basically I need the IDs in the module I provided to match those of the module that the customer creates when importing the data.

Any help on this would be very much appreciated.

Thanks.

Thomas

  • OurGuest
    OurGuest
    1 Post

    Re: Retaining Unique IDs when importing XML files

    ‏2013-04-22T13:31:42Z  

    IBM wants to make money, so they do have a better for of xml exchange but it costs about 4000 us dollars per year for a license.  Couldn't find link to it in the general forum because of the search function being out of service. But here is contact info for the product:

    Birgit Schoenfeld [birgit.schoenfeld@de.ibm.com]

  • Wolfgang Uhr
    Wolfgang Uhr
    6 Posts

    Re: Retaining Unique IDs when importing XML files

    ‏2013-05-03T08:22:04Z  

    Hi

    The problem of different ids in different modules is absolutely normal. If you export an object, the you have do add your id to the export file. The "other side" has to import the parameter as an attribtue like "orginalID". If they perform an export, they have to export this id too. In the home module you have to compare the "Absolute Number"-Attribute in your Module against the "originalID" in the reimport file.

    And be shure, that you also handle the module id in the same way, so that you can test it too. Otherwise it may be possible that you import your customer-a-data into the customer-b-database and this only will increase the bloddy preasure of some important people.

    Best regard

    Wolfgang

  • llandale
    llandale
    252 Posts

    Re: Retaining Unique IDs when importing XML files

    ‏2013-05-03T16:48:55Z  

    Hi

    The problem of different ids in different modules is absolutely normal. If you export an object, the you have do add your id to the export file. The "other side" has to import the parameter as an attribtue like "orginalID". If they perform an export, they have to export this id too. In the home module you have to compare the "Absolute Number"-Attribute in your Module against the "originalID" in the reimport file.

    And be shure, that you also handle the module id in the same way, so that you can test it too. Otherwise it may be possible that you import your customer-a-data into the customer-b-database and this only will increase the bloddy preasure of some important people.

    Best regard

    Wolfgang

    This is another reason to not use "Object Identifier" as the "Requirement ID".

  • BillTidy
    BillTidy
    18 Posts

    Re: Retaining Unique IDs when importing XML files

    ‏2013-06-20T09:22:16Z  
    • llandale
    • ‏2013-05-03T16:48:55Z

    This is another reason to not use "Object Identifier" as the "Requirement ID".

    Little bit late replay but...

    Not using Object Identifier (Abs nr) completely defeats the purpose of a tool like DOORS which uses (abs nr) this to guarantee uniqueness.

    RIF/ReqIF just supports (is supposed to) the functionality that your export in RIF/ReqIF format includes your Req ID. This is then imported into an attribute in the 'away' database as a foreign ID (and is usually hidden from normal user views). On resend back to the Home database, this ID is returned in the export RIF/ReqIF file. On import into the Home DB, this is the key used to determine whether an object exists and needs updating or (when the attribute is empty for a row) that a new object needs to be inserted into the Home db. The concept is easy and logical but the problem is that different tool vendors do not always implement the RIF/ReqIF functionality 'thoughtfully'.

  • llandale
    llandale
    252 Posts

    Re: Retaining Unique IDs when importing XML files

    ‏2013-06-21T18:53:33Z  
    • BillTidy
    • ‏2013-06-20T09:22:16Z

    Little bit late replay but...

    Not using Object Identifier (Abs nr) completely defeats the purpose of a tool like DOORS which uses (abs nr) this to guarantee uniqueness.

    RIF/ReqIF just supports (is supposed to) the functionality that your export in RIF/ReqIF format includes your Req ID. This is then imported into an attribute in the 'away' database as a foreign ID (and is usually hidden from normal user views). On resend back to the Home database, this ID is returned in the export RIF/ReqIF file. On import into the Home DB, this is the key used to determine whether an object exists and needs updating or (when the attribute is empty for a row) that a new object needs to be inserted into the Home db. The concept is easy and logical but the problem is that different tool vendors do not always implement the RIF/ReqIF functionality 'thoughtfully'.

    I'm suggesting a big distinction between "Object Identifier" and "Requirement Identier".  You certainly need a unique "Object Identifier" when you are copying or exporting/impotorting modules.

    If the thing you are representing in DOORS has a meaningful unique ID in the real world, then replacing that with object Id would be a disaster.

    • A Module of Students would use the "Student ID" not the "Object ID" as the key attribute
    • A Module represententing Mil-Standards would use "MilStnd ID" as the key
    • A Module representing "Licensed Vehicles" would use the VIN as key.

    Imagine the disaster if you consistently use refer to the above things using Object Identifier.

    Now "Requirement ID" generally has no external real-world value, but it often does.

    Even if it doesn't, this reference only makes sense for this module in this database.  Some other database could not realistically have a module representing these requirements since the ObjIDs therein do not match the original.

    If the original object somehow gets purged, then the "Requirement" is also gone.  If you use a separate "Requirement ID" you can simply create a new object.-

    -Louie

  • BillTidy
    BillTidy
    18 Posts

    Re: Retaining Unique IDs when importing XML files

    ‏2013-06-21T20:06:35Z  
    • llandale
    • ‏2013-06-21T18:53:33Z

    I'm suggesting a big distinction between "Object Identifier" and "Requirement Identier".  You certainly need a unique "Object Identifier" when you are copying or exporting/impotorting modules.

    If the thing you are representing in DOORS has a meaningful unique ID in the real world, then replacing that with object Id would be a disaster.

    • A Module of Students would use the "Student ID" not the "Object ID" as the key attribute
    • A Module represententing Mil-Standards would use "MilStnd ID" as the key
    • A Module representing "Licensed Vehicles" would use the VIN as key.

    Imagine the disaster if you consistently use refer to the above things using Object Identifier.

    Now "Requirement ID" generally has no external real-world value, but it often does.

    Even if it doesn't, this reference only makes sense for this module in this database.  Some other database could not realistically have a module representing these requirements since the ObjIDs therein do not match the original.

    If the original object somehow gets purged, then the "Requirement" is also gone.  If you use a separate "Requirement ID" you can simply create a new object.-

    -Louie

    Certainly true but "Student ID", "MilStnd ID" and VIN are foreign IDs for DOORS. I'm not suggesting replacing them but you will make your life a whole lot easier by pairing them with the unique DOORS ID as a foreign ID in a DOORS module.

    We have several tools integrated with DOORS (exchanging data in batch). Each of the other domains/tools has their own unique ID (Student ID, etc) but when exchanging data with DOORS you need to have the DOORS internal ID as part of the data exchange to manage that effectively (know which rows to update and which are new rows to be inserted into DOORS). Each interface has its own key-pairs, either the DOORS ID+Student ID or DOORS ID+MilStnd ID or DOORS ID+VIN, etc. By having the DOORS ID you can very easily detect that it is a new row or a row to update (new rows to insert have no DOORS ID). Having these keypairs also lets you easily update a single object from multiple data sources.

    Updated on 2013-06-21T20:11:12Z at 2013-06-21T20:11:12Z by BillTidy