Joe Kaufman Bell Laboratories Inc Application Development Manager

Pierre,

What platform are you running on? That is, do you have access to the underlying database server for DocuWare?

On version 6.11, on premise, I can go into the SQL Server database and check the fields:

DWLASTACCESSDATETIME
DWLASTACCESSUSER

and see who last viewed a document. I just viewed an old document and it updated those fields to the current date/time and my username.

Those fields also appear to be accessible via Platform SDK API queries as well as URL Integration, though I am not sure how you could expose them on a regular search dialog. What you could do is add a field of your own that uses a "Predefined entry" of "Access date" and "Access user" (short or long name). Then you could search by access date and access user. I do not think there is any other way to expose those system entries on a standard Search dialog.

Good luck!

Thanks,
Joe Kaufman
 

Simon,

Don't worry about the late response -- you came through! I got this working!

I had previously noticed that the final URL (that displays in the browser once the document comes up) shows the query "in the clear". But any time I tried to use that URL with an unfound document, it displayed a very nasty system message I did not want users to see that (and I assumed the URL just wasn't working right). But when I switched out "Document" in the URL for "Result" (like in your example), it works to display a nice screen whether a document is found or not. In other words, instead of going directly for the document, it went for the Result List.

And by utilizing displayOneDoc=True in the URL I can make the viewer appear immediately, which is ultimately what I want (this integration works with one document at a time).

This is a much more straightforward integration once one figures out the escaped characters in the URL. And it turns out our ERP system displays the DocuWare viewer right inside its own frame (it is pseudo-browser-based), so it looks much more seamless and doesn;t fire up a new browser tab for every viewed document.

Thanks so much!

Joe Kaufman

Fabian,

I really cannot thank you enough for triggering this idea -- we now have integration working via an application that serves up integration functionality via command line programs! I don't when (if ever) I would have had that idea if not for your web service comment!

Have a great weekend!

Thanks,
Joe Kaufman

Fabian,

Thanks for the response and the web service idea. We aren't exactly equipped to start writing web services, so I was hoping for a different answer. But it is what it is. 

I actually already have a WinForms application that I write little command-line snippets for, so perhaps I could use that to pass parameters to and generate a URL to execute on the client side. Same idea as a web service, just an application service. So, I appreciate you sparking the idea for that!

Thanks,
Joe Kaufman

Hey all,

I am trying to integrate DocuWare with a new ERP system, and the new ERP system allows for  parameterized URLs to be built and summoned via right-click menu options.

I can get everything working by hard-coding the file cabinet guid, and I can grab query criteria from the context of whatever form I am on in the ERP tool. But the "q" parameter in DocuWare URLs is followed by the query that has been Base-64 encoded. The URL creation area in the ERP tool does not have any functionality with regards to encoding any part of the URL.

Is there a way to pass the "q" parameter "in the clear", that is, without any encoding? Is there a setting on the server that would allow the query string to be passed in the clear? Without this I do not know how I am going to get this working...

Thanks,
Joe Kaufman

Tobias,

Thanks for confirming! Much appreciated!

Joe Kaufman

Hey all,

Figured it out -- the file cabinet in question DID have Profiles in play, and apparently when you add a new field you have to explicitly grant the rights to that field per non-default Profile. I made sure the new field got added to our custom Profiles, and it shows up now. The new field automatically gets added to the default Profiles by the looks of it.

Thanks,
Joe Kaufman

Hey all,

I added a field (index) to a file cabinet yesterday and added it to all dialogs. Shows up fine for me.

I found out today a different user cannot see the new field. It just isn't there in the store, search, result, or index dialogs.

I have "owner" permissions on the file cabinet but have never seen a certain field be unavailable for some users and not others. WE have not done field-level lockdowns or anything like that, so I do not understand what is going on.

I cleared cache on the other user's workstation and all that -- no difference. What am I missing?

Thanks,
Joe Kaufman

Mark,

One more point of clarification -- my code does NOT create file cabinets. A FileCabinet object in C# is just a programmatic representation of an existing DocuWare file cabinet. I still had to create all the file cabinets by hand, saving off the XML used to create them as I went along (so I could more quickly create them when ready to go live).

My code just takes a document that is saved as a file, loads the dwcontrol file alongside it (as indexes), then uploads the file and applies indexes using the DocuWare API routines UploadDocument and EasyUploadSingleDocument (depending on document size). In fact, my code does not show the part where indexes are generated from the dwcontrol file -- that was a different routine. As long as you can load indexes into a DocuWare Document class (in code), you can use whatever indexing scheme you want.

C# can manipulate the Fortis COM object, too, I just already had the Foxpro code for that. So, you could, if you wanted, use a single C# program that does everything in one flow, one document at at time:
 

1. Find a the document in Fortis you want to migrate.
2. Save the document itself as a file to a known location.
3. Also save the indexes for the documents in memory (as variables in your program)
4. Establish a connection to DocuWare and get a FileCabinet object instanced, representing the destination for the document.
5. Upload the document and indexing information to DocuWare, assuming the indexes on the DocuWare cabinet match the indexes on the original DocuWare document.

If any of this helps you, I am glad! Good luck!

Thanks,
Joe Kaufman

 

James,

Thanks for weighing in. We have been installing Fujitsu scanners and things are going great. Good to know someone else is seeing issues with the Kodak scanners -- hope Kodak figures out the issue!

Thanks,
Joe Kaufman