Joe Kaufman Bell Laboratories Inc No longer there

David,

I think we come at things from a very different perspective here. Our installation isn't something assembled by end users and resellers/consultants who, no offense, may or may not have a full understanding of proper data modelling. That is not the case for us. We have developed document types that are fairly well normalized. We do not mash a lot of different document types into one file cabinet and then separate them by a "document type" index. To me, that defeats the whole purpose of separate file cabinets and breaks almost all rules of proper normalization. If you need to add a "document type" index to your file cabinet, as Steve Jobs might say, "You're doing it wrong."

There is another reason for not mashing unalike documents into one file cabinet -- parent/child relationships. What if one document type occurs multiple times as it links to a parent document type and you want to make a linkage for it? You can't do that if everything is all in one file cabinet (at least I don't think you can, and if you could it would get real ugly, real fast). That's just another reason for normalization.

Whether or not a document is "unalike" another is, of course, the whole question here. It is the foundation of all data modelling, deciding what should be considered a separate data entity. If two documents share 90% of indexes, then yeah, perhaps we do some sparse indexing on that and have holes in some documents and different holes in others. In such cases we would not use a generic trigger. But if I have a file cabinet that is as specific as "HR - Wage Tax Register" and those documents are unique, then the workflows I build against that file cabinet are going to be very simple because the documents are already inherently distinct.

As far as how documents get into the system, that is highly regimented for us as well: we use scan sheets and tend to do almost everything "after the fact". We don't scan in a purchase order as soon as it is printed and then later attached the AP invoice and check to it. The invoice and PO data all go in together, and then the check goes in later and links back to the AP invoice via automated processes written behind the scenes. I see all the sales videos for DocuWare where people scan in a sales order, then the pick tickets, then the packing list, then the BOL, then the invoice, then the payment record -- and I have no idea how folks can trust that they have all the data they need in the right spot. If something doesn't index properly, who verifies that? If someone goes in six months later and cannot find the invoice, how is that handled?

We wait until the sales order is closed, slap a scan sheet on all materials for the order (sometimes 100+ pages) and scan that into our sales order/AR file cabinet. Then, our folks go page by page and make sure everything scanned in correctly. It doesn't stop there. We then run a homegrown application that matches indexes in DocuWare to systems whence the documents came from to see if we have any documents with improper indexes as well as detecting when something in our systems has no scanned materials on record in DocuWare. Consider that Auto-Index on steroids, since it can work against our Foxpro data (Auto-Index cannot work for that -- I know it cannot because there is no reliable ODBC driver for the latest Foxpro DBF file format).

I know that all sounds burdensome (and it is), but it has been in place for years (in Fortis before DocuWare) and at this point I cannot fathom trusting any other methodology to know we for sure have documentation for all of our important processes readable and stored. If we didn't do that? If we used DW printer, and Connect to Outlook, and intelligent indexing and just threw documents all over the place into DocuWare? I can't say I would trust that because our users don't check logs etc. and they ignore error warnings (or just don't see them). We had TWO MONTHS were our production folks were scanning in documents and it was erroring out every time because their destination was set to "Inbox" instead of "Auto Identification" and they didn't have an Inbox. Those documents never got into DocuWare because they were not checking that the documents made it like they were supposed to. We were just lucky we still had the hard-copies back that far (and I have since given them an Inbox and told them they need to check). They had not been checking the scan log and left the scan unattended so missed the popup stating the job had failed (might be nice to show a counter with failed jobs over the little button that displays history – not that they would have noticed that, either…).

Anyway, that is a very long-winded way of saying I think we implement things a bit differently than most people because we have always done things from an on-site, custom programming mindset. Our file cabinets are all carefully designed and normalized to the best of our business-process knowledge. We still have some cabinets we set up a bit funkily, but it all works. And we can always set up a DocID > 0 trigger to get all new documents, so it is no big deal. I just want to make sure folks understand there is definitely a reasonable rationale behind the desire for a generic "everything" trigger, and it doesn't complicate workflows because we have already designed those complications away via (what I consider) proper file cabinet structuring.

Thanks,
Joe Kaufman
 

Phil,

I see your point, but we almost never use one file cabinet for documents as disparate as AP and AR -- an AP invoice (puchase order) is going to probably have different fields than an AR invoice (sales order), for example. We like to keep our structures as refined as possible, so we segment our document types a great deal even when some index fields overlap.

I guess what I am asking for is that the condition requirement be eased for when you are in "new document" mode (only). In essence, that would give you three basic scenarios:

1. All new documents.
2. New documents meeting some condition(s).
3. Index changes meeting some condition(s).

All without needing to dummy up an "everything" condition like "Doc ID > 0". Luckily, exposing the system fields makes it very easy to create a catch-all condition.

Your point is also very valid in the event, for example, an already-reviewed document gets stored. In that sense, a no-condition trigger could be found to be a bit overzealous, and the user should probably be warned if they create a new-only, no-condition Start. Then again, a quick COndition at the start of the flow to route a document to the End if it is already found to be completed would handle the situation.

At least I am not crazy in having to make these always-on conditions, and I understand why it is easier for Workflow to just enforce at least one condition to make sure the user knows what they are getting themselves into...

Thanks,

Joe Kaufman

Hey all,

Quick question about Workflow Designer... I find myself starting most workflows by having them trigger when any new document is added to a file cabinet. But even when just asking for all new documents to kick off a flow, one has to put a condition in before the "Start" can be saved.

So, I find myself doing things like making a condition that says Doc ID > 0, or some other condition that will always be true.

Why can't we just have the Start trigger be storage of a new document, period? It seems odd to have to make up a tautological condition just to start the workflow. I want it to simply start and I will apply Conditions and Tasks from there.

Am I mising something or not wrapping my head around the "right" way to be doing this? What conditions do other people use on triggers to simply statt the work flow for all new documents?

Thanks,

Joe Kaufman

Neal,

When you say "seeing improvement" do you mean the number correctly read has just increased a bit or now works all the time? How many bar codes are on a sheet? I know you read that other thread, but have you increased "ExpectedNoBarcodes" to 99 in the VintaSoft config file? I highly recommend that. Because we didn't just "see improvement" -- we have not had a single barcode read fail on any documents for about 5 months now. We are talking hundreds of thousands of barcodes across thousands of documents and several auto-ID Import Configurations. Some of our scan sheets have 19 bar codes on them, and I am monitoring all manually changed indexes -- there have been none for months.

Once you get barcoding working with the right codes installed and ExpectedNoBarcodes = 99 you should be be bulletproof at 300 dpi. If not, then something else might still be going on, such as erratic placement of the barcodes (meaning you need to spread things out and make read-out areas as large -- but still distinct -- as possible).

Thanks,

Joe Kaufman

I hope that works! Do let us know if so. Folks using a lot of barcodes are not all that plentiful on these boards.  *smile*  We live and die by scan sheets for about 99% of documents we scan in.

Thanks,

Joe Kaufman

Neal,

Can you read those barcodes with a barcode scanner? Just a normal scanner like RedLaser on an iPhone? I printed the codes and they looked clear enough, but I could not read the codes with my iPhone nor with a Motorola industrial handheld computer w/ scanner.

I have attached Code 39 barcodes for the values you attached, and the barcodes do not look the same upon visual inspection. Some parts are similar, but it looks like your codes are missing beginning and end markers. I am no barcode expert, but think something is getting truncated on the barcode fields. Compare what I have attached to what you list, and you will see my codes have extra stuff at the start and end. My barcodes are readable by my handheld scanner and by my iPhone (RedLaser).

If you can't read the barcodes with a scanner, then DocuWare will not be able to scan them in either. I think this is a starts/end issue which barcodes are finicky about (and I wish I knew more about it to help...).

Thanks,

Joe Kaufman

https://www.docuware.com/sites/default/files/forums-images/189566.jpg

https://www.docuware.com/sites/default/files/forums-images/s86500.jpg

Some sort of downstream caching/blockage makes sense to me, as even with just the Task Manager Notifications I created via the web client, changes to those notification texts would not kick in right away -- always some lag. It looks like whenever we do lots of configuration changes or additions we might want to consider bouncing all services, bouncing IIS, or just rebooting the server off-hours.

I am sure there are issues with things being "stuck", as this morning I could not make the error logs grow, then 20 minutes later I saw a bunch of errors from 20 minutes back. It takes a while for "stuckness" to work through. The errors ranged from SMTP errors (before I had properly assigned the SMTP connection) to issues about published versions of Workflows being out of sync or not being found.

Thanks again for everyone's help! We can now run Workflow through its paces to see if we need the whole thing or can get by with just Task Manager. That decision will also be based on price, obviously, as Workflow Manager is dang nifty...

Thanks,

Joe Kaufman

I am not sure what happened, but after bouncing services one more time and then just not doing anything with Workflow for an hour, I removed all workflows, built a basic email workflow -- and it worked! I added an Assign To and a Task action and more notifications went out and a Task was created.

So, it looks like things are working, and ther are no recent errors in the Workflow Engine error log.

Thanks to everyone for their help -- just wish I knew what made this start working...

Thanks,

Joe Kaufman

Thanks, Christopher.

I didn't have the SMTP connection selected for the Workflow Engine connection, but now I do (and I bounced the Workflow services as well as the Notifications service). I cannot mess with IIS or the server further than that because we are up and live during the day (I assume messing with IIS will cause people to get dropped).

I have not applied any hotfixes and do not even know how to do that. So if that is required I will need support to help with that and show me how it is done.

I have gotten some errors to appear in the error log for Workflow Engine, completely cryptic ones of the type:

ServerContext::ctor: AcceptSecurityContext failed. Error Code = 2148074248 > The token supplied to the function is invalid

I will go ahead and open a support ticket.

Thanks,

Joe Kaufman

Hey all,

Thanks for all the help so far -- a little progress is being made.

I installed Workflow Engine last night and it installed perfectly and was running right away, green light in the Control Panel. Still no "Tasks" button at the top of the web client. Bounced every DocuWare Service. Still no Tasks. Rebooted the whole server. Finally "Tasks" show up.

I did not see anything new in the Admin tool about turning Workflow on, so if there is something I need to do there I have no idea what it is. And folks have mentioned "testing" connections -- how do I do that? I do not see any buttons or menu options to test connections when I have connections highlighted. A database connection now exists for "Workflow Engine", and the "dwworkflowengine" database exists in SQL Server and has some Workflow data in there (the meta-data defining the workflows).

I unpublished and deleted all the workflows I had previously created. I have tried simple emailing, assigning, and tasks in the flow, everything tests fine, and yet no notifications are sent out and no tasks appear in the web client even though everything is being assigned and sent to me. I checked logs, and there are some timestamps from last night when I tried a few things, but I cannot make any new log activity appear in the logs this morning. It is like nothing is happening at all.

Straight notifications (configured in the web client config) continue to work, so the notification server is working property in terms of SMTP, etc.

So, I suppose I have to start a support ticket? Any other ideas? I got "Tasks" to show up, but that is about it...

Thanks,
Joe Kaufman