REQUEST A DEMO

Improving Attachments in the Clarify Classic Client

A common issue with attachments in Clarify is getting the uploaded files to a common location.

 

By default, Clarify simply takes the filepath you give it (such as c:\temp\file.ext) and creates attachments records in the database with that filepath.

 

Obviously, no one else is going to be able to view an attachment that resides on a user’s C drive. So that default behavior stinks.

 

I’ve seen a number of attempts of solving this over the years. A couple common ones:

 

  • Create a shared drive (such a Z:\ or \\attachment_server\), and tell users to copy files there, and then attach them.
  • Add an FTP customization to the attachments form, so that files are automatically FTP-ed form the user’s machine to a common location.

 

I’m not really crazy about either of these solutions.  In the first, it requires users to remember to do something. In the second, you end up with FTP permission issues, and its often the case that files end up in one huge directory.

 

It’s better on the web

 

With web applications (such as Dovetail Agent, Agent Lite, and Mobile), we’ve solved this issue. The file is uploaded to the web server, and then from there we have full control over what to do. Typically we store it on a common share (such a Z:\ or \\attachment_server\), and dynamically built subdirectories to keep things organized.

 

For example, the directory structure would look like \\server\attachments\PartialCaseId\CaseId\file.ext, such as\\server\attachments\009xxx\009009\file.ext

 

Then, when we want to download those files, we can simply serve them up by HTTP (which I discussed in a previous post).

 

How can we use the web to upload/download attachments from Clarify?

 

Pretty simple. We use a web browser control on a form set to a URL that handles our file uploading and downloading.

 

This is the same technique I described previously in Improving Case History within the Clarify Classic Client.

 

So what might this look like?

 

For a quick example, I re-used the attachment page from Dovetail Agent. Here’s the Clarify attachment form (form 1006) with a browser control on it:

 

attachments

 

 

The ClearBasic code behind it:

Sub Form_Load() 
    Me.DoDefault

    Dim rec As Record 
    Set rec = App.GetContext 
    web.Navigate http://myserver/agent/workflow/clarify_attachment.asp?flag=1 & objid=” & rec.getField(“objid”) & “&type=” & rec.RecordType

End Sub

 

Pretty simple. Users can upload/download and delete file attachments. The files are automatically uploaded to the web server, and then can be moved to their final storage location. In my example, they’re stored on a server called tommy in a share named Attachments.

 

Roll your own

 

Now, if you’re not using Dovetail Agent, you might have to whip your own little web app to do this. But that’s pretty straight-forward for any web developer.

 

And it doesn’t matter if your web app is running on Windows, UNIX, or Linux. Your web app makes it easy for users to upload attachments – where you store them is up to you.

 

Keep in mind though that you still need to do the “Clarify stuff”, i.e. inserts/deletes from table_doc_inst and table_doc_path, and relating them to the proper entity (such as a case or subcase). This is where Clarify libraries such as the Dovetail SDK or Clarify CBOs come into play.

 

To the cloud!

 

Here’s another thought. What if all of these attachments were stored in the cloud, such as Amazon S3? Your web app could post/upload those files directly to your Amazon S3 account, and you could get out of the business of storing huge amounts of local file attachments. Hmmm……very interesting……

 

Summary

 

I think this is an interesting approach to improving a “legacy” application by incorporating contemporary technologies. And as legacy apps like the Clarify Client are phased out, we should be able to re-use much of the web-based components that we’ve built.

 

Rock on.