TeamSite objid

Could anyone explain how a TeamSite objid is generated? Are they like Microsoft GUIDs where part of the ID is based on the NIC ID in the server so each ID generated is totally unique?

I'm saving the objid of a DCR as an extended attribute that is later used as an ID when interfacing to a Siebel CRM application. I'm concerned about what might happen if/when I have to migrate to a different box. Is it possible / probable / unlikely that the new TS server would generate an objid already in use (generated by the previous TS server before the migration)?

THANKS in advance....

Find more posts tagged with

Comments

james1

> Could anyone explain how a TeamSite objid is generated?
> Are they like Microsoft GUIDs where part of the ID is based on
> the NIC ID in the server so each ID generated is totally unique?

Every object in a TeamSite backing store is issued an id, which I think is a 31-bit positive integer. I believe that id's are issued sequentially.

An objid, I believe, is the concatenation of three id's (in hexadecimal). For a file, I think the 3 id's are something like branch, area, and file.

> I'm saving the objid of a DCR as an extended attribute that is
> later used as an ID when interfacing to a Siebel CRM
> application. I'm concerned about what might happen if/when I
> have to migrate to a different box. Is it possible / probable /
> unlikely that the new TS server would generate an objid already
> in use (generated by the previous TS server before the
> migration)?

It is definitely possible that the 2nd server gives a file an objid that is given to some file on the 1st server.

If you're looking for a GUID for your DCR's that persists across TeamSite servers, then you may want to think about having an external process generate the GUID for you. It sounds like you already have an external process assigning the EA to the DCR, so this same external process could also generate the GUID as well.

-- James

--
James H Koh
Interwoven Engineering

Edited by james on 12/04/02 02:10 PM (server time).

james1

I should probably follow this up by saying: I don't think that there is any guarantee that a future version of TeamSite will always have the same system for creating objid's, and so my information may not be safe to rely on.

-- James

--
James H Koh
Interwoven Engineering

smigster

Thanks for the insight. Is there any way of nailing this down exactly (i.e., no "I think"s or "I believe"s)? I'd hate to make a potentially very expensive decision to rework my approach and update all my content EAs based on what someone THINKS instead of what someone KNOWS.

Adam Stoller

There has never been a stated policy regarding the use of object ids for anything but internal product purposes.

Any dependence on them remaining as they curerntly are, or being maintained when moved from server to server or even from backing store to backing store on the same server is completely unsupported.

No "I think's" necessary - it's an internal mechanism for which CLTs exist to deseminate information from. The CLTs are the API for the object id - the construct and/or contents of the object id are entirely open to change without prior notification being provided.

Sorry - but I think you have some work to do in re-implementing your process.

--fish
(Interwoven Senior Technical Consultant)