Submitted by Syd Nicholson on Fri, 12/15/2006 - 00:00
Forums
IceBreak

I have a client that needs some document management processing.

The requirement is as follows:

A web page contains selected information regarding 'jobs of work' that have been recieved from my client's customers. The left side of the page lists the 'jobs', which, when selected display details in an IFRAME on the right of the page. The IFRAME has tabs, which, when clicked allow differing functions to be performed -(eg. change job, display job, search for job, add new job, etc.). One these tabs must list all documents for the selected 'job'

The documents involved are stored in the IFS where each 'job' has it's own folder. Documents can be of many types (scanned in, word docs, pdf, saved e-mail attachments, minutes of meetings, etc). All of the documents in the job folder need to be listed inside the IFRAME when the documents tab is selected. Currently there are approx 27,000 job folders - increasing every day.

To make things a little more complicated - when the document is clicked it must be downloaded to the desktop into the appropriate windows program. The document could be one of many different possible file types.

I know the later step (opening the document) can be achieved using Apache to list the contents of a directory. This is not ideal as I do need to add some document security (IceBreak exit program?).

I believe that IceBreak Inspire includes many of the features required to handle documents. Would I be correct in this assumption, and if so how would you recommend I tailor this software to suit my clients needs?

Many thanks
Syd

itp --- I am an IceBreak end user - not part of the development team and I am working on an IceBreak project for a client of mine.

I have posted questions in this forum in the hope that that not only I, but other users can gain befenit from the replies. I have also posted some source code for the same reason. I always thought that that was the purpose of this forum.

Syd

Hi Syd,


 Originally Posted by Syd Nicholson: 
"itp --- I am an IceBreak end user - not part of the development team and I am working on an IceBreak project for a client of mine.

I have posted questions in this forum in the hope that that not only I, but other users can gain befenit from the replies. I have also posted some source code for the same reason. I always thought that that was the purpose of this forum."

I believe that - just for future reference - you should have posted this as a follow-up to this thread 

Best regards,

John Foldager
www.izone.dk
www.icebreakforum.org

Hi Syd;


 Originally Posted by Syd Nicholson: 
"I believe that IceBreak Inspire includes many of the features required to handle documents. Would I be correct in this assumption, and if so how would you recommend I tailor this software to suit my clients needs?"


The source code to "Inspire" is shipped along with the product,so you can be "inspired" to make your own applications base on that.

The "check.asp" is what you are looking for - this is the "pre-recource exit program" that allows user to see public Queies, even not logged on.

The directory listing, will be made more efficient if you make a "directory save" exit program and the maintain a correlated db/2 table so you afterwards can make SQL queries. Ofcause it is a matter of choice.

If you need a directory list sample - I can provide you with one ...

Regards

Niels Liisberg

Thanks Niels,

Yes - the check.asp is the obvious approach for controlling security access to the URL, providing of course, that I use IceBreak instead of Apache to deliver the directory list.

I like the idea of a 'Directory Exit Program'.  This client already uses my Fortress/400 software and already has an exit program handling read/writes to directories on the system. It would be a simple addition to maintain a list of directories and documents created inside specific folders.

The problem with this exit program is that it records the fact that an attempt was made to create a folder/document but does not confirm that the attempt was sucessful. If the file is large, it could be several seconds (even minutes) after the create/update request before the file is actually available. Do you know of any exits/triggers that activate after an IFS action is complete?

If I use use IceBreak to deliver this directory list - how do I ensure that the file is 'downloaded' to the appropriate application. I don't want the file to open in the browser. I know I can use mime types to open an object in the browser, but, in this case, I want to do the opposite - open the object in it's own application, or save it to disk. Some files may be quite large - greater than 2MB.

Thanks
Syd

 Originally Posted by Syd Nicholson: 
"Do you know of any exits/triggers that activate after an IFS action is complete?"

Here I'm a little blank - I cant see why the normal API-exit is not enough


 Originally Posted by Syd Nicholson: 
"I don't want the file to open in the browser. I know I can use mime types to open an object in the browser, but, in this case, I want to do the opposite"

Just thinking loud - Try with a content type that does not exist: "Application/download" - I don't know if that is bullet proof....
 

Niels

Thanks Niels,

The normal exit point API is triggered when an attempt is made to change the contents of a directory (eg. add a document). It gives no indication of whether the document was successfully added. There could be several reasons why the addition of the document could fail. If the exit program wrote a record to the DB, but the document did not create successfully then we would have a record in the DB, but no document in the IFS.

There is also a delay between the exit program triggering and the document being created. The system will not start the transfer of the document until the exit program has completed execution. So - when the exit program has finished, the document transfer still has not started, the document does not yet exist.

After the exit program has completed, the document transfer starts, and assuming the transfer completes OK the document will then be available for use. Depending upon the size of the document and the transfer rate it can take several seconds, or even minutes, before the document becomes usable. I don't know of any way to easily determine whether the document transfers sucessfully or not. The only process I can think of is a submitted job with a DLYJOB that checks every few seconds to determine if the document exists and if so then updates the DB. Not very elegant.

The same problem exists if documents are deleted or moved. I don't know of an API that triggers an event when an IFS change has been completed. There is only an exit point for network requests.

I have considered IFS journalling. This would be fine for documents and directories that exist on the system, but, how does one journal directories or documents that do not yet exist and are still to be created.

The appache approach of a directory list is very simple - although not sufficiently secure - it does have many advantages.

Perhaps trying to maintain a separate database of IFS contents, and keep this up-to-date with changes to the IFS isn't such a good idea after all. I could just use the 'C' api's to list the directory contents and this will display whatever happens to be in the chosen directory - no need to worry about exit programs! An excellent job for AJAX.

Incidently, does IceBreak still have the 2MB download limit - this could be important?

Regards
Syd

 Originally Posted by Syd Nicholson: 
"I could just use the 'C' api's to list the directory contents and this will display whatever happens to be in the chosen directory - no need to worry about exit programs! An excellent job for AJAX."

Yes - If you don't know how - I can send you an example.


 Originally Posted by Syd Nicholson: 
"Incidently, does IceBreak still have the 2MB download limit - this could be important?"

No we changed the implementation to teraspaces - however, large buffers tends to slow down the system... so use it with causion

Niels

Thanks Niels,

No problem with the 'C' apis - I am well used to these. I have all the prototypes for them predefined already.

Not many files will be greater that 2MB so this should not be a problem.

Looks like I have a decision on which way to go with this part of the development.

Thanks once again
Syd