Oracle FrontPorch DIVArchive Integration

DIVArchive Workflow Overview

Archive management module in Zoom allows the user to take assets on expensive & faster near-line storage and move them to a cheaper & slower secondary storage. The secondary storage could be a slow NAS/SAN, Direct Attached Disk or tape based system. Zoom allows flexibility in selecting the target storage for offline assets. The DIVArchive integration takes this to the next level by allowing users to move assets from Zoom database on near-line storage to a tape library system managed by DIVArchive. This integration is implemented using DIVArchive APIs and drop folders. The sections below describe how to configure DIVArchive integration with Zoom archive module.

Archive Workflow with DIVArchive

• User will select assets in Zoom, click archive menu option and all the selected assets (1 or more) will be automatically ingested in DIVArchive system.

  

• Each archived Zoom asset will have a unique Object Name in DIVA. That name would be the Zoom Asset ID.

Restore Workflow with DIVArchive

• User or administrator will search in Zoom to see which archived assets they are interested in restoring

  

• From Asset Browser, the user will select one or more the assets (for instance asset ID 23 in the above image) and send a restore petition to the Zoom server
• This will cause asset restore request from the Zoom Server to be sent automatically to DIVA using a Zoom restore hook configured on the Zoom server. If there are any issues the administrator can check the DIVArchive GUI for restore requests.
• Once DIVA restore requests finishes, it places the asset in a  Zoom hot folder
• Asset then gets restored automatically in Zoom
• Once an asset is restored successfully by the automation, the orange circle in Zoom will disappear indicating the asset is online.

Setting up DIVArchive Integration

The system administrator can follow the steps below to setup the DIVArchive integration:

1. Create a drop folder on the DIVArchive system to receive assets from Zoom, the configuration on DIVA side needs to allow Zoom to write an MDF file per Zoom asset. This is done via the dfm.conf file on DIVA. A sample is shown below, please consult your DIVA support engineer for more details. For instance, folder visible on DIVA side: c:\xfer-diva-share is writeable by DIVA and mounted as /mnt/xfer-diva-share/ on the Zoom server Linux machine is show in screenshots below.
   

   

2. Create a network shared hot folder into which DIVArchive can write to when it restores the assets using the DIVArchive manager. For instance /mnt/xfer-from-diva-to-zoom/. Ensure this network shared folder is writeable by DIVArchive and the Zoom system account running the Front Porch integration Perl automation script fp-zoom.pl (next step).
3. Download and copy the Front Porch integration Perl automation script fp-zoom.pl on a folder on the Zoom Server machine. For instance /home/evolphin/bin/fp-zoom.pl

   

4. Ensure the system user that will execute the script has read and permission. For example if the system user is “evolphin“, ensure that the to/from DIVA folders setup above are write-able by this system user.
5. Modify the constants in fp-zoom.pl for your environment:
   

   Constant Name	Description
   WIN_DIVA_MOUNT	The exact network share path that DIVA dfm needs in the generated MDF file in order to ingest assets. Consult your DIVA engineer.
   ZOOM_ADMIN_SRV	URL to the Zoom Web Management Service
   ZOOM_HOME	Folder where Zoom is installed
   ZOOM_USER	user name to run the restore operation, needs to be in a superadmin role
   ZOOM_PASSWD	password of the Zoom user above
   TO_DIVA	The mounted network share path on the Zoom server writable by the system user running the fp-zoom.pl script. This is the same drop folder configured on the DIVA system as WIN_DIVA_MOUNT above.
   FROM_DIVA	The mounted network share path on the Zoom server writable by the system user running the fp-zoom.pl script. DIVArchive manager will write into this folder on restore.

6. Double check the permissions by switching user to the system user that the script will be running as, for instance “evolphin“. Ensure you can write files into the From/To DIVA network share folders setup above using the user “evolphin” for instance.
7. Setup the Front Porch integration Perl automation script fp-zoom.pl to run periodically. For example, on a Linux system use a cronjob:

   

8. Specify the frequency at which the above script executes. For example the above screen shot specifies every minute which is typically useful during testing but too frequent in production. Specify a setting that does not cause the system to overload itself with folder scans running too frequently. Recommendation is no less than every 15 minutes.
9. Setup the Zoom restore pre-hook perl scripts that will communicate with the DIVAarchive server for restore request.
10. Once an asset is restored successfully by the automation, the orange circle in Zoom will disappear indicating the asset is online.
11. That’s all and of course do not forget to configure the Archive module in Zoom first!

Debugging Problems

1. The script will write to the system log. For instance, on a Linux system you will find the output from the script in the /var/log/messages file:

   

2. The log will show the assets that were archived or restored or errors that were encountered.
3. When the script writes to the DIVA dfm hot folder you will see similar file patterns  that will tell you if archiving script is writing to the folder:

   

   The numbered folder for e.g. “758..” above is a Zoom folder that contains the assets being archived to DIVA. The MDF file is always named as <zoom-asset-id>.mdf and contains the Object Name that DIVA will store the file under. You can open the file in a text editor to see what is Zoom generating.

   If it is indeed creating similar files and assets are not showing up in DIVA, the issue often is with the dfm config on DIVA side, write permissions for DIVA. Sometimes the MDF template in the fp-zoom.pl may need to be tweaked. For example in certain DIVA product versions, the template fields “sourceDestinationDIVAName=DFM” and  “sourceDestinationDIVAPath=<win-share>” in the generated MDF files are not needed. If that is the case edit the  fp-zoom.pl script and remove those lines from the MDF template variable:

   

4. When restoring from DIVA, you should see Zoom asset ID (file names) created under the Zoom numbered folder by DIVA restore as following:

   

   Once an asset is restored in Zoom, the From DIVA folder should delete that asset so that it is not occupying any space on the shared folder.