In addition to being able to connect to a DIVArchive system, you can use the DIVArchive API to connect to an Oracle DIVAnet system (see Appendix A for Oracle DIVArchive options and licensing information). This functionality enables applications to access content across multiple DIVArchive systems, possibly in different geographical locations. DIVAnet enables the content in each system to be retrieved and stored as if the DIVArchive sites together were one large archival system.
This chapter includes the following information:
DIVAnet provides a unified view of archived content across multiple, distributed DIVArchive systems. It facilitates the moving of content among DIVArchive sites, and from customer source and destination servers and disk. The purpose is for disaster recovery, content distribution, access control, performance, and content availability.
DIVAnet synchronizes asset information from each DIVArchive site, so that users always have an up-to-date inventory of where content is. DIVAnet uses this information to choose the best site for various requests, for example restores and copies. DIVAnet also provides access rules to limit the operations that users are permitted to perform.
DIVAnet 2.2 is compatible with DIVArchive 7.6 Linux-based installations. DIVAnet 2.2 also runs on Windows-based systems. However, it is not backward compatible to releases before DIVArchive 7.3.1. You must use either DIVAnet 2.0 or Legacy DIVAnet when running DIVArchive releases earlier than DIVArchive 7.3.1.
The Legacy Oracle DIVAnet is still available for connecting DIVArchive systems with different software release levels, and releases before DIVArchive 7.3.1.
If you are operating a DIVArchive release earlier than 7.3.1, refer to the Oracle DIVAnet Installation, Configuration, and Operations Guide in the Oracle DIVAnet documentation library, or the appropriate Legacy DIVAnet documentation in the Oracle DIVArchive Legacy library (for DIVArchive releases 6.5 and 7.2).
See Appendix A for Oracle DIVArchive options and licensing information.
DIVAnet has partial support for the full DIVArchive API command set. Refer to the appropriate DIVAnet documentation for a complete list of supported API commands. DIVAnet will support client connections from DIVArchive API clients release 7.6 and earlier. New parameters or features added to the API after release 7.5 are not supported by Legacy DIVAnet. In general, a released DIVAnet can connect to newer releases of DIVArchive, and sometimes also can connect to older releases. This ability varies based on the specific release of DIVAnet.
Invoking DIVArchive API calls to a DIVAnet server is largely the same as invoking calls to DIVArchive. However, there are some differences. DIVAnet sometimes accepts additional information by using common DIVArchive API parameters in a slightly a different way.
For example, you can use the DIVAnet Copy command (CopyToGroup) to copy content from one DIVArchive system to another. DIVAnet needs to know, at a minimum, what the target DIVArchive site is. This information can be provided in multiple ways, for example you can prefix the target_sitename to the media provided in the call (for example, sitename2_mytapegroup). Refer to the appropriate DIVAnet documentation for more information on specifying DIVAnet-specific information in DIVArchive API calls.
A DIVAnet system sometimes returns API information that is slightly different than you would typically see in a DIVArchive system. For example, the DIVAnet getObjectInfo() call returns information about an archived object across all DIVArchive sites. To distinguish which site is which, the source site name is prefixed to the media of each archived object instance returned in the call. For example, an object on sitename2 that is stored on mytapegroup would have a media value of sitename2_mytapegroup.
Another example of a slight difference is the object instance ID. DIVArchive has a unique instance ID for each instance of an archived object (starting at zero and incrementing by one for each new instance). However, this value is not unique across DIVArchive sites. DIVAnet applies a simple algorithm to the instance ID to make it unique across sites (but not across objects). The unique DIVAnet instance IDs for an object can be queried by making a DIVAnet getObjectInfo() call.
The Request ID returned by each DIVAnet request does not necessarily correspond to a DIVArchive Request ID. Refer to the appropriate DIVAnet documentation for more information.
DIVAnet will return DIVA_ERR_ACCESS_DENIED if a user or connection does not have permission to perform a particular action. DIVArchive does not return this code. DIVAnet can possibly refuse an API connection altogether because of configured permissions. DIVArchive will accept the connection if it hasn't run out of available connections. There are cases where DIVAnet will choose to acknowledge a request with DIVA_OK and then subsequently return an error (for example, an Invalid Media error). DIVArchive will simply reject the request with the DIVA_ERR_INVALID_PARAMETER error.
The GetObjectDetailsList() command retrieves a list of objects from each site. DIVAnet retrieves the object information directly from each DIVArchive system, one site at a time, in a round-robin fashion. It returns one batch per site to the initiator. The initiator must keep calling GetObjectDetailsList() with the same query parameters - passing all received list position data as input to the next call.
If an object is returned in one batch, the initiator can possibly receive the same object again in the next batch (for the second site). This makes GetObjectDetailsList() different from GetObjectInfo(), which returns information from all sites in one call.
The query parameters and time ranges queried in each batch are specific to each site. It is possible that if Site1 contains many objects in a given query (and Site2 does not). The batches from Site2 that are near the end of the calling sequence might be completely empty.
Keep calling GetObjectDetailsList(), ignoring empty batches until the call returns either a status of DIVA_WARN_NO_MORE_OBJECTS or an error. All DIVArchive sites in the DIVAnet network must be online for GetObjectDetailsList() to succeed. If, for any reason, an error is returned before the list has been fully returned the entire calling sequence must be repeated.
Other details of the DIVArchive GetObjectDetailsList() call remain in effect for the DIVAnet release. For example, while the batches returned are ordered by time, the order of entries within each batch is not guaranteed. Although duplicate objects will not appear within a batch, the same object may appear in the next batch - the likelihood of this occurrence increases when you use the MODIFIED_SINCE parameter.
If an object has been deleted and subsequently re-added, GetObjectDetailsList() will return one record for every time this has occurred for the entire period that DIVArchive retains the records.
To continuously monitor DIVAnet for new objects and instances, you can continue to call GetObjectDetailsList() even after it has returned a status of DIVA_WARN_NO_MORE_OBJECTS. To do this you must provide the exact same query information (passing all received list position data into the next call) to get any new updates since you last called it. If an error occurs, you must use the exact same list position that was received on the last successful call.
Refer to the appropriate DIVAnet documentation for more information on specific DIVArchive API calls.