Frank,
The Status property is more properly associated with archive lifecycle management; that is, it reflects the multiple states in which an archive may be intentionally placed by an administrative workflow. You would expect to see STS_UNAVAILABLE when an archive has been marked for deletion, or marked as full by an Archive Usage Limit. You should see STS_TEMPORARILY_UNAVAILABLE if the archive is closed after a Move Archive, if you query while the archive is still being created, or if the Storage Queue is full.
Further, if all the EV services are stopped, you should not even be reaching the point where you query the Status, because your IArchive::Get method call will fail ("Enterprise Vault is not running").
(If you are querying the Status without first running Get, well then you won't get an exception but you're always going to see STS_AVAILABLE because the EV_STG_API_STATUS enum defaults to its 0 value on every new instance of an IArchive object, until you run Get and pull all the actual archive details from the database.)
The Status property also isn't updated in real time; if you Get on an IArchive while its Status is STS_AVAILABLE, then mark the archive for deletion, then call Status again, it will continue to say STS_AVAILABLE (until you do another Get). It's a snapshot of how the archive looked at the time you called Get. This makes it good for things like defining targets and job queues ("Is this archive a suitable target for insertions?") but not so good for checking before every single IItem::Insert call ("Is this archive ready to receive an item right at this moment?").
Hope that helps!
--Chris
Chris,
IArchive::Get is being called before every check to IArchive::Status. When the services were down, the call to Get was still succeeding. Insert attempts, however, failed with the EV is not running error.
These calls are not being made before every insert, there is a seperate background process triggered every X number of seconds that keeps track of whether or not the archive is available (using both the the returned status and the whether or not the Get succeeded or failed).
Is there a better way to determine whether an archive is available for inserts?
Frank,
In my experience, the call to Get will fail if all the services are down. If the Directory Service is up but Storage is down, then Get succeeds while Insert still fails. I'm testing this in a single-EV-server environment though; maybe if you have multiple servers and one has all the services down, the EV API is smart enough to contact a running Directory Service on a different machine because they're interchangeable, whereas the Storage Services are not.
I don't think the approach you're taking really tests whether the archive is ready to receive an Insert right now. As I described before, the Status property is more about whether the archive has been placed in one of a few known EV workflow states where it cannot receive items; it doesn't cover unexpected or temporary technical interruptions like service stoppages or network outages.
I think the best way to test for the specific fail condition you're seeing is just to run a periodic test in your background process that returns whether the Storage Service on the relevant computer is running or stopped. Unfortunately, the EV CM API doesn't seem to have any kind of "test whether an Insert would succeed right now" functionality.
--Chris
Would it be possible to use the IItems interface to attempt to retrieve only the properties of a single item (hopefully that will trigger a call into the storage service)? I wrote some quick test code and it seems like IItems::Get is failing with "EV not running" even though the services are running.
IContentManagementAPI3 api = new ContentManagementAPI(); IItems items = (IItems)api.Items; items.ArchiveId = ArchiveId; items.Maximum = 1; items.Get(); // Exception here IItem item = (IItem)items.GetEnumerator().Current; item.Get((int)EV_STG_API_ITEM_DETAIL.DETAIL_LEVEL_ITEM_PROPERTIES);
If we were to query the actual services themselves, then we would need permissions to every server in the environment that hosts an EV archive. That could be a bit of a challenge in large environments.
It looks like the failure to retrieve items is actually due to my test environment.
