Video Screencast Help

Constructing Id property for enterprise vault API

Created: 01 May 2014 • Updated: 06 Jul 2014 | 4 comments
This issue has been solved. See solution.

I've been writing a bit of software in C# that works well to export and reconstruct archived public folder data into an Office 365 archive mailbox.  All has been fine except for when it gets to some items that have a shorter IdChecksumLow than 8 digits, because when you use the standard algorythem for constructing the "Id" property the API rejects it.

So an example of a normal working Id value when I construct it :-

201110209077076~201110200217000000~Z~10BEE9958432529AEFD2D18549126971

<IdChecksumHigh><IdChecksumLow>~<ArchivedDate>~Z~<IdTransaction>

The problem comes when the IdChecksumLow field in SQL has less than 8 characters, so I might get a value like this :-

2011111932894~201110211324000000~Z~9048F50297260117475642BEB632A091

Because the IdChecksumLow is 932894, 6 characters long.  If I pad the number either side with zeros so 00932894 or 93289400 it seems to work fine and goes on to retrieve the item.

However, what is the "correct" rule for constructing this Id string?  Should it be padded?  Should it have some extra values taken from another field?  Does it even matter?

I don't want to allow it to simply continue all the way with guess work incase it retrieved the wrong items into the wrong folders, a tip would be appreciated :)

Operating Systems:

Comments 4 CommentsJump to latest comment

neil.doody-gl's picture

After more digging and reading back over examples, actually the full savesetID isn't even required for the API.  I was playing around and realised it didn't care about any of the other values, then found an example where a user simply put in the IdTransaction column directly to the Id Parameter of the API object.

And it works fine, seems the API will accept several different forms for the Id Parameter, but it is pretty strict about the format if using a full savesetID string.  Still worth getting the question answered, if anyone knows regarding the shorter length IdChecksumLow...but if not, no biggy...I think I can just run it by using the IdTransaction parameter only, seems to be working sweet :)

Rob.Wilcox's picture

Glad you have it sorted, but as a coder-against-the-API you must be a STEP partner, right? So if you need to know the answers then there is a Symantec distribution list that you'll have acces to who should be able to help.

neil.doody-gl's picture

No, I'm not a step partner.  Just a mere freelancer with some knowledge in scripting / designing with c# :).

This of course makes it incredibly difficult to use the API without the documentation you get when you become a partner.

 

Anyhow, my tool has been running for hours now sucking public folder content out of enterprise vault and reconstructing it into a 365 archive mailbox.  So mission accomplished from here.

As per the original request, I would like to know the answer still if anyone can share..but no biggy.  Just one of those things that will play on my mind :).

neil.doody-gl's picture

Okay, I've got the answer...if you use the API to retrieve an item using simply the IdTransaction then the API will give you back the Id constructed as a full savesetId.

I wasn't far off in my guess, because all it does when an IdChecksumLow is less than 8 characters long is it pads the left with extra zeros.  So a live example, if you have a 7 digit checksum low like 4931809...it becomes 04931809 when created into a savesetID.  So the following saveset Id :-

20131124931809~201311200642580000~Z~412E2B50115D664842A779C44E15D991

Would become :-

201311204931809~201311200642580000~Z~412E2B50115D664842A779C44E15D991

I also made a little mistake in my first algorithm, it is infact the IdDateTime used not the ArchivedDate.

Anyhow, case closed / problem solved.  Hopefully if anyone else ever searches for this same question, they might find a useful answer here :).

 

 

Thanks

 

SOLUTION