Advertisment

Roll your own IPMS

author-image
PCQ Bureau
New Update

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).

Advertisment

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
Links:

http://dmoz.org/Computers/Software/Document_Management/ 
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.

Advertisment

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:



method=”POST” runat=”server”>



Upload File:

Advertisment




Doc title:





Author:





Keywords:










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


Try







            Fil =
filInputFile.PostedFile







            If ((Not Fil
Is Nothing) AndAlso _





(Fil.ContentLength > 0)) Then



            fOrigName =

Fil.FileName


            fName =
IO.GetFileNameWithoutExtension( _



fOrigName)



            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))

Fil.SaveAs(fNewPath)



End If


Catch Ex1 As Exception


Response.Write(Ex1.ToString())



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:



SELECT *



FROM


WHERE (       


            =
PROVIDED_ID_VALUE



) ORDER BY ;


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:





SELECT * FROM



WHERE (


            (
LIKE '%'+SUPPLIED_SEARCH_PHRASE+'%') OR



            (
LIKE '%'+SUPPLIED_SEARCH_PHRASE+'%') OR



            (
LIKE '%'+SUPPLIED_SEARCH_PHRASE+'%')



)


ORDER BY ;









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






Advertisment