OnBase stores multiple copies of the data in blocks called volumes. Copy 1 is stored on magnetic media. This copy is uncommitted. It is a temporary space for data which has been brought into OnBase, but not yet committed. Copy 2 is also on magnetic media, but is the committed copy. This copy will contain all your OnBase data. Copy 3 is the backup copy. This copy is sent to CD, DVD, or an optical drive. As volumes are filled up, they will appear in the backup queue. Partially filled volumes will not appear in the backup queue. If a volume which is not full needs to be backed up, it can be promoted. This is covered in Disk Group Management in the OnBase Configuration portion of this document. When volumes appear in the backup queue, they need to be backed up.

Platter Management is accessed in the Admin menu of the client. Select Platter Management. 

The platter management window shows the status of the OnBase disk groups, the volumes available to be backed up, and volumes available to be deleted.

Backing Up Data

Data is backed up to CD, DVD, or optical platters. Select Platter Management from the Admin menu. This will open the following window. In this example “Data File Storage” is the name of the disk group.

1.  Click on Backup Queue to see disk groups which have volumes to backup.

2.  Double click the disk group (Data File Storage, in this example) to display volumes available to backup to optical.

3.  Highlight the volume to you wish to backup.

• Each volume displayed will have three numbers separated by dashes associated with it. The first and third numbers will stay the same. The middle number will increase sequentially. In this example, the volume name is Data File Storage: 101-3-2

4.  Left click on a volume to highlight it and then right-click the volume to bring up a menu.

5.  Select the Write to Disk option.

• Although you may be backing up to CD-R, most customers will still use the Write to Disk option for CD-R, DVD, or Optical Platters.

6.  The following window will appear, prompting you for the path of the disk. Place a formatted disk in the drive. (See section on formatting disks for information on how to format the disk prior to writing backup.)

7.   In the field where NOT CREATED appears, type the letter of the drive and the name of the volume.

• For Example, if your CD Rom drive letter is F, and the volume is Data File Storage 101-3-2, the path which needs to be entered is F:\Data File Storage 101-3-2

8.  Click OK.

9.  A window will appear with a blue status bar. A CD will take 15-40 minutes to write. An optical platter can take an hour or two, depending on the size. The status will move to right, indicating the percentage completed. When the entire disk is written, the system will indicate this. The disk can be ejected and labeled.

1. While the backup is writing, no other activities can be accessed in OnBase. Please remember this and plan accordingly.
2. After a platter has been successfully backed up, it no longer appears in the backup queue. It may now appear in the delete queue, where it should be removed.

Deleting Excess Volumes

When the number of volumes written exceeds the minimum which were configured, the volumes need to be deleted. This does not remove the data from the system. OnBase is designed in most cases to write three copies. The first copy is a temporary copy which needs to be removed after the backup (third) copy is written.

If volumes in Copy 1 are not deleted, the maximum will be reached and no further input of documents will be able to occur. This error will display as follows.

To delete volumes for Copy 1 follow the following steps.

1. From OnBase client select the Admin menu>platter management.  The platter management window will appear.

2.  Click on Delete Queue on the left side of the window.

             A.  This will display the disk groups with volumes available to delete on the right    side. 

              B.  Double click on the disk group to display the volumes available to delete.

3.  Click on the volume to highlight it, and the right click to bring up a menu.

4.  Select Delete to delete the copy of the volume

         A.  You will be prompted to Anaylze the volume

         B. Select Yes

5.  The following window will appear.  Analyzing the volume compares two copies to ensure they are identical.  The location of the 2^nd (primary copy) or 3^rd(backup copy) must be selected to be able to analyze.

1. Select Created Platter to compare the deleted copy to the backup platter.  This works best if the delete happens immediately following the writing of a backup platter.  Select the platter name and click Analyze.
2. Select Path to compare the deleted copy to the primary copy (copy 2) on magnetic media.  Browse to the onbase.id file which correlates to the volume you are trying to delete.

                      A.  Typically, this will be similar to the following.

\\computername\driveletter\MTM\OnBase\OBDG\DataFileStorage\Copy2\Onbase.id

                      B.  Select Analyze

6.  You will receive two or three prompts confirming deletion.  Select Yes and the copy is deleted.

Hyland Resources:  11.0 Platter Management MRG

OnBase stores keyword type objects in the hsi.keydatatype relational table where each object is assigned a unique number. All subsequent references to that keyword type elsewhere in the database refer to its keytypenum value rather than its name, which is why you can rename a keyword type in Config and see the new name take effect immediately everywhere it is used. The keyword number, displayed in the upper right corner of the Keyword Type Configuration screen in Config, doesn’t change. You can also see this methodology reflected in the name of the individual keyword’s keyitem data table in the database, which is named according to the keyword type’s keytypenum.

If you remove a keyword type from a document type, it will no longer display on existing or new documents and no new values for that keyword can be entered on that document type. However, any existing values on documents already in the system are retained in the database so that, if you decide to re-add the keyword type later, the data previously entered is displayed again.

If you need to change the keyword type’s data type, say, from a numeric(20) to an alphanumeric(20), OnBase will update the keyword type object in the hsi.keydatatype table and the data type of the keyword value column in the corresponding hsi.keyitem table in the database. It will attempt to convert the indexed keyword data from the old column format, though going from a numeric(20) to an alphanumeric(9) would result in a potential loss of data for obvious reasons. Once the conversion is complete, OnBase will ask if you want to retain or delete the old table. Hyland recommends retaining it for reporting purposes. We also recommend not making this type of change lightly because of the impact it has on the database and the potential loss of data.

If you decide to delete a keyword type entirely from Config, OnBase will delete the keyword type object entry from the hsi.keydatatype table and the references to it on the document types where it was used. The hsi.keyitem table is retained, so you still have a last ditch opportunity to reclaim the data if, for example, you accidentally deleted the wrong keyword. The OnBase ties to a deleted keyword type are cut permanently, however, which means that restoring those values requires the creation of a new keyword type and re-indexing the documents involved based on the information you pull from the previous hsi.keyitem table, so proceed with caution. Just as a reminder, modifying any OnBase tables directly invalidates your warranty.

Whenever you make changes to a keyword type, review any e-forms, scripts, custom queries, and foldering configurations that reference it to ensure continuity. If your e-form or script references a keyword type by name that has been renamed or removed, it will need to be updated. Likewise, if the data type changes. If a custom query or foldering configuration references a keyword type that no longer applies to the document type, you may need to configure an alternate keyword type to achieve the intended results. If a deleted keyword type was used in any processes or Workflow life cycles, they will have to be re-evaluated.

It is absolutely because of you that we have been able to do the work we do and win this award. We are rich in the quality of our customers. Thank you for being so amazing.

The Temporary Parse Path…

• location is set in Client | User | Workstation Options | Startup.
• TempParsePath location is set in onbase32.ini (onbase.ini prior to 8.2) for AutoFill preprocessing.
• requires Read, Write, and Delete permissions to create and delete files.
• should be on the local processing machine.
• must be of sufficient size to hold the largest file that will be processed.

Hyland References:  11.0 AutoFill Keyword Sets, Client, COLD/ERM, Document Import Processor, and PDF Input Filter MRGs

Hyland Software has identified an issue where Notes may be deleted from all documents within an OnBase system during a batch purge.

ALL of the following circumstances must apply to your business in order for this issue to occur:

• You are Running Any of OnBase Versions/Builds Listed Below:
  • 10.0.0.501 through 10.0.1.623
  • 11.0.0.501 through 11.0.1.583
  • 11.1.0.x (Beta)
• Your business process includes adding Notes to documents stored in OnBase
• Your business process involves any form of batch processing (COLD, DIP, Document Imaging, etc.)
• Your batch processing has “process tuning” enabled

Description of Issue

Hyland Software has discovered a serious issue where, during a batch purge process, non-Staple based notes may be deleted from all documents stored in OnBase, regardless of whether the documents have any relationship to the purged batch. Staple based notes that are not affected by this issue are the default Note Types of ‘Staple’ and ‘Back Staple’. Notes configured for any other Note Type have the potential of being deleted. Therefore, we strongly suggest that you continue to the Naviant Recommendation section below.

The magnitude of this issue is dependent upon how frequently batches are being processed and subsequently purged with an affected build of OnBase, and by the use of Notes. The impact on the OnBase installation will result in Notes being unintentionally deleted from all documents. In situations where a database backup is not available for recovering the notes, this data loss can be significant.

Determining Impact

Does your business meet all of the circumstances in the “Nature of Alert” outlined above? If so, then you will need to work with Naviant to determine if your OnBase solution is affected and any subsequent repairs are required. Determining whether notes have been deleted from your system is relatively easy since this defect results in a mass deletion of notes.

Naviant Recommendation

Hyland Software and Naviant strongly recommend an OnBase upgrade to one of the builds listed below to ensure this issue does not result in any additional loss of data. This is strongly recommended whether or not you have encountered this issue.

OnBase Versions & Builds that have been fixed include:

• 10.0.1.624 and higher
• 11.0.1.584 and higher
• 11.1.0 (Beta)

Please review the “Nature of Alert” outlined above, and if you meet all of the circumstances or just have clarifying questions, you will need to contact Naviant Support directly at support@naviant-inc.com or 800.686.8789.

UPDATE:  To clarify the above conditions, process tuning is used by batch processing whether you adjust the default settings or not. The only affect it has is on how many documents could potentially be affected if the issue were to occur. The event that causes an itemnum of ’0′ to be added to the database when all of the above conditions apply is the loss of network connectivity during batch processing. If a batch containing a document with an itemnum of ’0′ is then purged, all Notes in the system are deleted.

*OnBase Network Security links with sAMAccountName by default. Additional information about AD Name Attributes can be found here.

**OnBase passwords can be manually set to as few as 1 character or as many as 50 in Config.

Additional Considerations

The following symbols are special characters in LDAP and cannot be used in AD user or group names:  / \ [ ] : ; , | = + * ? < > “ @

SQL

SQL is the language used to query the OnBase database. SQL statements can be used to retrieve data for custom queries, autofill keyword sets, or be embedded within the code types below as part of a larger set of tasks. As always, use SELECT statements only. Any changes made to the data or structures in the OnBase database via SQL statements will render your warranty void.

HTML, JavaScript

E-Forms are written in HTML. JavaScript can be included.

VB Script

VB Script can be executed in the Classic Client, with Disconnected Scanning, via Script Hooks, and in Workflow. Scripts function best in Workflow when executed by timers. To get the best error handling, we highly recommend always using the Workflow rules for running scripts instead of the actions.

VB Script is required for actions such as the “Run Script” functionality in the Classic Client. When using the Web Client or Unity Client, all scripting should be done in the Unity API in either C++/C# or VB.Net.

C++/C#

The OnBase Core is based on the .Net framework. Though .Net is compatible with many programming languages, C++/C# and VB are the only two that Hyland officially supports. The OnBase Unity API should be your first choice whenever possible. If Unity does not include the functionality you need, VB Script is the next best option, after reporting the deficiency to Hyland so they can look into adding it to a future version of Unity.

Preprocessors can be used to reformat data before a DIP, COLD, or Autofill import process runs. Hyland recommends that preprocessors be compiled C++/C# executables because VB Script often has trouble with the return value.

External Programs

The OnBase Unity API Toolkit provides the ability to write your own programs that interact with OnBase documents, data, and workflows. Any .Net framework language can be used, though C++/C# and VB are the most common.

First of all, what does going digital mean for library materials?  For most people it is presenting material in a new, usually more “User Friendly” manner.  It starts with making them easier to “find” (locate), easier to distribute, easier to make available to patrons, less stress on the Library staff and going from “analog” to “digital”.  Once the decision to go digital has been made there are questions that need to be answered:

• What media formats do we have now?
• How do we want to make the information available?
• Who is going to be responsible for that media?
• Can we afford this at this time?
• What is best for our patrons and our staff?

Rare Books and Bound Material

These can be digitized just like documents, by scanning and then saving to a form of media. Just as with anything else there are pros and cons to doing to digitizing your books and bound materials.

The Pro’s are as follows:

• Saves the lives of the books
• Multiple users have access to the “information”
• Can be sent as email attachments without first having to make a paper print, then scan the paper print
• Can be searched via OCR software for faster retrieval

And the Con’s are:

• Have to go through the “transformation process”
• Deciding on where the information will reside until needed
• Deciding to do the work In-house versus a Service Bureau
• In-house means getting hardware and software and peoplepower and lots and lots of time
• Service Bureaus means having the items out of house for a time, but project may be more cost-effective and done sooner

Once the decision is made to digitize; the users then must decide on the media of storage they will use.  CD’s and DVD’s can store lots of volume in a relatively small space, duplicates are readily available, user-friendly and relatively inexpensive, but they are also unstable, not meant for long-term storage, easily stolen or misplaced, should be re-burned every 5 years or so and will the drives and technology be there in 5, 10 or 15 years to “read” them? Electronic storage is the other option and it too has advantages and disadvantages.  Its advantages are that it is easy to locate with correct software, can allow multiple users to access simultaneously, storage relatively inexpensive, can send info without making print first (or at all!) and nothing’s “lost” or “misplaced”.  As with everything there are also disadvantages, but this just has one…BACKUP the Data.  Backing up the data is very important and also testing the backups to make sure they are good. 

Now we need to get the materials converted from paper to a digital format.   To begin scanning these materials an input device, retrieval software and storage are required.  The options for input devices are an overhead book scanners, flat-bed scanners or “book” type copiers/scanners.  Each of these has its own list of benefits and detriments, so we will start with the over-head book scanners.

Benefits

• Large size scanning area (@ 17” by 24”)
• Color available
• Face-up scanning
• Removes the curve (clean, flat scans)
• Goes deep into the spine
• Saves on bindings
• Can be used for document scanning
• Outstanding quality of scans
• Inter-Library Loans

Detriments

• Relatively expensive
• Relatively slow
• More ideal for University and College Libraries as opposed to Public Libraries

***Idea:  Lease the unit as opposed to outright purchase.

Flat-bed Scanners

Benefits

• Easy to use
• Can be the most inexpensive option
• Color available

Detriments

• Do not protect bindings
• Do not allow for curvature
• Do not go way into spine
• Not very fast

“Book” type Scanners

Benefits

• Multiple Use devices

Detriments

• Bindings not protected
• “Hang off” problem
• Not a huge scanning area

Now that you have scanned images from your books and other bound materials, you need to be able to access those images. This is accomplished with software that is designed for that purpose.  Here are a few options for you to choose from: Single workstation retrieval application, Enterprise Content Management solution or online subscription service.

I hope this has provided you with some very valuable information that will help you to make the decision on whether to digitize your rare books or bound materials.

If you need to convert the information from bound materials or rare books to another medium, go electronic. It makes lookups easier and more patrons can access the information faster.

Just remember to BACK IT UP!

Naviant will be upgrading our network systems the week of January 23rd 2012. If you experience any interruption in service and are unable to reach us during normal business hours, please call our emergency support line at 608.395.1778.

First, determine whether or not there are any scripts being triggered by each timer. If so, are they written in Classic mode (Sub Main35) or Core mode (Function Main)? If a script is written in both, then you’re in luck and you can use the Core based monitoring service. Otherwise, timers running scripts written in Classic mode need to be monitored by a Classic client. (If resources permit, we would recommend rewriting the script instead.) Either way, if you have a task that runs a script on the Client side and the timer is manually executed, the Client side script is not executed in the Core based client.

Next, examine how many timers you have overall and how often they need to execute. Attention should be paid to spreading them out so that they execute at different times and just often enough to satisfy the requirements of the task. The more timers a server is monitoring and the greater the frequency that each timer executes, the larger the drain on the server’s resources. If you have timers configured to execute every few minutes all day long, consider using System Work instead.

If one server doesn’t have enough resources to efficiently monitor all of the timers, the work can be assigned across multiple servers. This is especially true when working with Classic mode due to its single-threaded nature. It is worth noting that even if you have some timers that have to run in Classic mode, you can assign the rest of them to run in Core mode for best results. You can also run one Classic timer service and one Core based timer service on the same machine simultaneously without risking collisions, as long as each timer is only assigned to one service.

Classic Timers

Applying the –WFSRVR,C switch to the Classic client activates the User | Workstation Options | Workflow Server Queues tab, where machines can be configured to monitor and execute timers automatically. The ,C suppresses the execution process, so timers aren’t triggered accidentally during configuration. This tab is only available if you are licensed for Workflow and have Workflow Administrative Processing Privileges product rights. Once the timers have been assigned, apply the –WFSRVR switch to the client or Windows service on the target machine to activate the timers.

As mentioned above, running Workflow timers through an open client or a manually configured Windows service (Config | Utils | Windows Services) is a single-threaded process. In other words, a set of timers assigned to a machine will execute one at a time, even if they are configured in Workflow to run simultaneously. Depending on how the timers are configured and how heavy the document traffic is flowing through them, this can result in a timer never getting a chance to execute. The Workflow System Monitor window in the Classic client allows you to review the status of assigned timers, which is updated every 5 seconds. This list is maintained outside of the client session, allowing it to resume where it left off if the client is closed. Multiple Classic clients can be configured to monitor different timers to simulate multi-threading, but each Classic client has to run on a different machine or collisions can occur as the clients fight for dominance over a given timer.

Unless your timers include scripts written in Classic mode, this timer service method is not recommended when Core mode is available.

Core Timers

Beginning with version 9.0, Hyland added the Core Workflow Timer Service with a dedicated administrative interface for more effective timer management. The Timer Service Administration utility allows you to assign, monitor, and troubleshoot timers in greater detail than with the Classic method. As a true, multi-threaded service, it allows multiple timers to execute simultaneously on the same machine. Login credentials can also be encrypted, if desired, and though the Workflow Timer Service will check for the existence of a client license, it does not consume one.

Timers without scripts or with Core based scripts should be executed with the Workflow Timer Service.

Hyland Resources: 8.2 – 11.0 Workflow MRGs, 11.0 Workflow Timer Service MRG