Joe Kaufman Bell Laboratories Inc No longer there

Hey all,

We started a trial of Workflow today, and everything appears to have installed properly. I can create notifications in the web client and I see new Workflow-ey menu options when I right click on documents, etc.

I also created a Workflow with the Workflow Designer (desktop app). I then tested it and it appeared to run properly. I had two notifications that should have gone out, one as part of a task assignment and one as just an "email" event. It said those steps executed, but I never received emails. I tried just a straight notification as well and never got notified when I added documents or changed indexes where I had rules set up.

I bounded the Workflow Server service -- still no luck. I have yet to receive an email notification from either the Notifications set up in web client or notifications that are part of a workflow. Additionally, Saving changes to a Notification in the web client seems flaky. The Save button is always active, and if I close the tab and go back in it says I have the Notification locked. I don't know if notification preferences are not properly saving, emails are getting jammed up, or what. 

Is there a log I can check to see what might be going on with emails? Is there something additional I need to configure on the server for notifications to work? I just installed the LIC file -- that was it. Let me know if there is more I need to configure.

Thanks,

Joe Kaufman

Stephane,

As Phil says, URL Integration is how you use raw URLs to access DocuWare. If you want to use the Platform service, you need to use a request object, e.g. via the DocuWare packages in Visual Studio (C#) or the ServerXMLHTTP object that is part of the MSXML layer in Windows.

Here is a forum post about how I got the restful API working from Visual Foxpro:

https://www.docuware.com/forum/english-forums/docuware-help-technical-problems/using-platform-sdk-other-dev-tools

You can also use a tool like Postman to play around with POSTs and GETs against the platform SDK. I didn't even know abou tthat tool when I started all this, so my journey was a lot of trial and error and shooting in the dark.

Hope this helps,

Joe Kaufman

Lauren,

What does it do it you check the "Show scanner device dialog" in the scanner configuration? Does that allow you to change the advanced settings?

When I do that, I see advanced settings, and they appear to stay persistent between scan runs (at least if I leave the Desktop Scan app up).

Thanks,

Joe Kaufman

Seth,

If folks want to do more in-depth work with documents, just have them pull it down. Then everything is as fast as local access allows.

I do wish DW had a way to do a read-only pull down so you didn't have to worry about accidentally making changes, but using a high-powered local PDF editor can work pretty well.

What exactly are folks doing, paging through documents, that they need that to be faster? Could you employ full-text more to help people search better? When it comes down to it -- and I hate to sound like Steve Jobs -- but if people are wading through a lot of pages for some reason, they are probably "doing it wrong".

(Or I am probably not thinking of the busines need you clearly have.  *smile*)

Thanks,

Joe Kaufman

Seth,

I hope someone weighs in on this, as any optimizations would be good to hear about.

I also find the DocuWare viewer to be a bit slower, overall, than Fortis. Not to mention, the Fortis viewer allowed common page manipulations (adding, deleting, and moving pages) without needing to shell out to an editor. I do miss that.

But when taken as a whole, folks where I work are liking DocuWare more than Fortis (or at least no longer miss it). Here are some reasons in other areas that DW is more efficient overall:

• Searching is MUCH faster. No more kludgey query prompts that have to be run through every time one wants to modify the search.
• DocuWare remembers what queries and windows were up. Fortis always seemed to have trouble with that.
• Full text implementation in DW is a lot better than the extra pages of keywords Fortis would tack on to create a full-text specification.
• DocuWare's default scanning mode seems to do a LOT better than Fortis at contrast, etc. We had a lot of black-on-gray parts of documents that would not scan well in Fortis, and users were endlessly messing with scan configurations. All of that is behind us.
• The way Fortis did auto-ID scripts was really, really convoluted and flaky. I hated setting up new document types or doing any scan sheet modifications because working on Fortis in that regard was like working in a haze of, "Now where do I do that?" DW's Import Configurations aren't exactly child's play, but they feel a lot more straightforward to me (though auto-ID is still sort of stupid if you are scanning a mix of document types).

I'm not trying to sound like a DW salesperson, and as I said, I do think the DW viewer is slower. But taken as a whole, DW is leaps and bounds beyond Fortis. Perhaps framing it that way (using discussion points such as those above) to your end-users/clients would shift the paradigm a bit...

Thanks,
Joe Kaufman

Jerome,

If you are using C#, have you tried using the NuGet DocuWare API packages "DocuWarePlatformAPI"? More on that can be found here:

http://help.docuware.com/sdk/platform/html/66b2ed1e-2aef-452a-97cd-5014bbf0242b.htm

Using that package in .NET is by far the easiest way to utilize the RESTful API (Platform SDK).

Can you try that methodology and see if you can get connected and get a list of file cabinets back? That would mean you are up and running and just need to explore the DocuWare objects presented in the API package until you find how to do whatever you need doing.

Thanks,

Joe Kaufman

Sure, but not everyone has AutoIndex because it costs extra (we don't). I have not played with the Index Cleaner app, but will take a look...

Thanks,

Joe Kaufman

Changing an index on multiple documents is available in 6.11 as well.

I assumed there were too many documents to fit on one screen at a time (more than 100), meaning someone would still have to go screen by screen if there are thousands of documents with the incorrect field.

Utilizing the Platform SDK (even a query against SQL Server on the backend) would be an option as well.

Thanks,

Joe Kaufman

Josef,

Thanks for weighing in... If I ever need to remove a bunch of stamps I'll look into a hack like this, but my end users would have no idea how to do such an operation safely. For them, I'll stick with the print and replace methodology for a page with an erroneous stamp.

Thanks to everyone for all the responses!

Thanks,

Joe Kaufman

Tim,

I hadn't thought of that... You are right in that I wouldn't have to go whole hog on using Profiles, just set up a Profile to link to a Role where I needed it. I think I will give that a shot with the Accounting role and see how it works...

EDIT: It worked very well. In fact, the Functional Profile wizard asks about stamps specifically, so it is apparent that Profiles are the way to go in this case. I am still not sure why that is, but assume it has something to do with stamps being set up at the organizational level and being an important part of workflows.

Thanks,

Joe Kaufman