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.
|
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:
method=”POST” runat=”server”>
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