Roll your own IPMS

Decoding Intel's Processor Nomenclature

Demystifying AMD Athlons

D-Link DPH-70L IP Phone

The Cell Broadband Engine 

Intellectual property in your enterprise exists at many different levels in a variety of forms. Right from traditional document based IP to that on paper and someone's e-mail and address book, it is all IP and you have a need to make it available to those who need it and manage it (including protecting and archiving it). We have previously examined what IP, in its various forms and means, can do for you and what you should do for it (Document Management, pg 57, May 2005; Managing your Intellectual Property, pg 100, May 2006).

In this multi-part series, we shall zero-in on the specific components of a full-fledged IP management solution-viz its document management, address book, messaging and collaboration, search and retrieval and creating online portals for your users to access the wealth of this information. In each of the parts of this series, we shall examine each section in detail and create that part of the application, slowly building it to the fully operational IPMS. Our minimum platform for this development will be ASP.NET 1.0 using VB.NET and SQL Server 2000.

Direct Hit!
Applies to: CTOs/CIOs
USP: Go behind the scenes on how IP management systems work and get started on rolling your own application for the same
Google keywords: IP management software –address

You can very easily extend functionality and maybe simplify areas like authentication using the ASP.NET 2.0 platform instead, but we leave that to your developer to design and implement. Each of our applications is being designed as independent elements with the ability to work together at the end.

In our DMS
The first part of our IPMS is its DMS (Document Management System). This DMS has three basic facilities: the interface to submit a file into the system, along with attributes about that object; the ability to search these attributes and present the results on query; and a check-in/check-out mechanism to keep track of different versions of a particular file. Our version control module also has the side-effect of making sure there are no duplicate copies of a file in the system.

File insertion
This is a basic file-upload process that needs little explanation to the developer. Our interface consists of a basic form that accepts a file (HTML File Upload component), and presents a few fields to be filled up that provide attributes about the file to our DMS. Our current search engine cannot peek inside documents for now (we shall add that capability in a later part), so these attributes along with the filename will serve as the indexing parameters. If you so require, you can very easily extend our sample to allow the user to insert customized attributes. The ASP.NET HTML definition is very simple and is what follows:

Upload File:

Doc title:



Our code for this (the OnClick handler for btnSubmit) does two things: it accepts the uploaded file and saves it safely to disk and stores the attributes for the file into our database. Now, even here, several checks are done-for example, the file must exist, be of an acceptable length and type and so on. Similarly, before writing to the database, the input attributes are validated and encoded to prevent (inadvertent) SQL-injection attacks. The process is atomized with Try-Catch blocks, rolling back previous actions if something is wrong. The file-test code would look something like this:

Dim Fil as HttpPostedFile
Dim fName, fExtn, fOrigName, fNewPath As String
            Fil = filInputFile.PostedFile
            If ((Not Fil Is Nothing) AndAlso _
                        (Fil.ContentLength > 0)) Then
            fOrigName = Fil.FileName
            fName = IO.GetFileNameWithoutExtension( _
            fExtn = IO.GetFileExtension(fOrigName)
            ' Here you would verify file type is OK, else:
            ' Throw New Exception(“Invalid File Type”)
            ' Generate a unique filename and store it into fName
            fName = Now.ToString(“yyyyMMddHHmmss”)
            fNewPath = IO.Path.Combine(FILE_STORE_FOLDER, _
                        (fName & fExtn))
End If
Catch Ex1 As Exception
End Try

Fields in DMS_Asset table:
Column name Type  Size
ID int identity
ParentID int  
DocID int  
FileUniqueName varchar 14
CreatedOn smalldatetime  
LastAccessed smalldatetime  
LastModified smalldatetime  
DocTitle varchar 80
Author varchar 80
Keywords varchar 80
SavedByUser varchar 16
CheckedOutByUser varchar 16

The database angle
You could probably have more fields to perform other tasks that are not in our scope at the moment. For example, where in the storage (what server, etc) and what status (checked in, archival, etc) is the file in. For efficient indexing, you could setup ID as your primary key and set the table to be indexed on ID, ParentID and FileUniqueName. Except for the ParentID and DocID fields, the rest are self explanatory. ParentID will be used for chaining versions of a document. The first version will have a ParentID of 0, and subsequent versions will contain the ID value of the previous version of that document. The DocID column is used for storing the ID of the first version, with the first version's DocID and ID having the same values. This will make retrieving the entire version chain of that asset easy with a single SQL query that is easily implemented as a stored procedure. The version chain (oldest to newest order) is retrieved by an SQL query as below:

FROM [DMS_FileAsset]
WHERE (       
            [DocID] = PROVIDED_ID_VALUE

Version management
Whenever a file stored using our DMS is accessed by a user and downloaded, it is 'checked out' in that user's name. After changes when the file is re-presented to the system, the old copy is checked back in, but a new database entry is generated for the new file and the file itself is stored with a different unique name on the storage. You could at this point of time, have the original details copied over from the previous version for the database. Some fields (like keywords) may be amended when a new version is created. At this time, our version management system is sufficient. We can extend it later using a much more comprehensive CVS if required, but that is not a part of our current goal.

Adding search
For our purposes, a simplistic search form will suffice. It can simply require inputs of one of the several fields we have captured earlier-with or without asking the user which of them he wishes to search with. Then the data is sent to the database via an SQL query (stored procedure) and the resultant list is processed, transformed into HTML and displayed to the user as a neat list. The very basic form of such an SQL query would be as:

            ([DocTitle] LIKE '%'+SUPPLIED_SEARCH_PHRASE+'%') OR
            ([Author] LIKE '%'+SUPPLIED_SEARCH_PHRASE+'%') OR
            ([Keywords] LIKE '%'+SUPPLIED_SEARCH_PHRASE+'%')

What we have at this point is the basic DMS. In the next part, we shall look at centralizing address book (contact) management information, along with adding more elements to what is normally stored in an address book to make it more useful to the person searching for information.

That system will also be extensible so that when we make our collaboration application a stage later, we can utilize our own address book there. And, if you have an LDAP server around, keep it ready for some action soon.

Sujay V Sarma

  • Follow PCQuest on
  • become a fan on
  • Stay updated via
  • RSS


Notify me of follow-up comments via e-mail address

Post Comment

Survey Box

Now that Microsoft has finally discontinued support for Windows XP, which OS are you likely to upgrade to?

Send this article by email