Export Problem

Export Problem

Postby ericvolkelbarno » Tue Jun 28, 2016 10:39 am

Since we have upgraded to Kofax Capture 10.2.0.0.0.491 we have been experiencing severe Export problems. We Export to IBM Content Manager Enterprise vs 8.4.3. The release script we have is several years old, and we have been told that there are no plans to upgrade it.

What happens is that Export crashes repeatedly... usually just as it is closing a batch. The problem is so bad that a co-worker has actually written a program which just runs according to a clock, and checks every so often if Export has crashed, and if it has, it restarts it. Some days Export might crash 30 to 40 times... other days not so bad.

We have been told that the export connector is not verified to run on the server os (2012), but we are experiencing the same exact failure on Windows 7, which is supported, so I do not believe it is the server os level that is the problem.

The crashes often leave orphan records in the BatchDocumetnPartialRel table, and there are many errors in the Application Event Viewer log such as follows:

Faulting application name: Release.exe, version: 10.2.491.0, time stamp: 0x54e6339e
Faulting module name: clr.dll, version: 4.0.30319.18444, time stamp: 0x52717e84


All of that is bad enough, but now we have discovered that any new batch classes created on the new system are experiencing a new Export problem, (all of the other bcs had been imported from the old system during the upgrade)... the Export fails with the following message:


Export Error: Script #1 (IBM DB2 Content Manager Enterprise 8.3) [-2147417848 Method '~' of object '~' failed]


Usually such batches can be forced through by processing them directly from batch manager, but we cannot ask our end users to push through every batch.

I created a new batch from scratch this morning, with minimal index fields, and no Validation script, and it received the same error. I changed the export to be a simple image/text file export, and it worked fine... so I am pretty sure the problem is with the Content Manager export connector.

Has anybody experienced these types of problems with Export?

Thank you very much,

eric volkel-barno
ericvolkelbarno
Participant
 
Posts: 41
Joined: Wed Mar 07, 2007 6:28 am

Re: Export Problem

Postby russell@centuryc.com » Wed Jun 29, 2016 12:05 pm

ericvolkelbarno wrote:Kofax Capture 10.2.0.0.0.491

Is there a reason you've upgraded to that version? All those zeros say "bleeding edge" to me.


ericvolkelbarno wrote:The release script we have is several years old, and we have been told that there are no plans to upgrade it.

Which is not the same as "unsupported". I think you'll have to push the support people to fix the problem if you're going to remain at this version of Kofax.

Export scripts can be a bit tricky as they involve the connection to both the back end server (IBM) and Kofax. But from what you've described, it sounds like a problem on the Kofax side. I'd suggest escalating pressure on Kofax.

The one area I can think of is what are you using for the Kofax database? The built-in one or your own? You may want to switch to the built-in one and NOT save batches in the database. If nothing else, just to reduce the number of variables. I personally have had bad experiences with trying to save batches in SQL. That was way back in version 7, but I'm not really seen a good case for trying again - at least not while everything is on a local LAN.

Another place to look - is there any possibility this is a network problem? It doesn't sound like it since it only seems to affect Export, but Kofax can be the proverbial "canary in a coal mine" when it comes to problems with bad switch ports and the like. It's dependence on the network is only matched by VOIP.
Russell
russell@centuryc.com
Participant
 
Posts: 3374
Joined: Wed May 17, 2006 12:53 pm
Location: USA

Re: Export Problem

Postby ericvolkelbarno » Thu Jun 30, 2016 5:12 am

Hello Russell,

Thanks for your reply.

We hadn't upgraded in awhile, and just decided to go with the latest version... not sure, there might be service or fix packs out now.

We are using SQL Server Enterprise for the Kofax db; having a fairly large system, using the built in db doesn't seem practical.

We are attempting to use every avenue available to us in seeking a solution, and I was just hoping that somebody in the forums would say, ah yes, we had that exact same problem, and here is how we solved it... anybody?

Thanks again,

eric volkel-barno
ericvolkelbarno
Participant
 
Posts: 41
Joined: Wed Mar 07, 2007 6:28 am

Re: Export Problem

Postby ericvolkelbarno » Tue Jul 05, 2016 7:32 am

Good morning,

Did figure out the problem with the weird tilde error message... when the new batch classes were initially created the "Release working directory" was set to a user's (mine) local folder. Obviously, when a different workstation is performing the release, upon which I did not log in, it will not have rights to my folder... not sure why the system automatically put in my folder... don't know if this is a new 10.2 behaviour or something else I did incorrectly.

Still haven't figured out why Export is continually crashing, which still is happening daily.

Thanks,

eric volkel-barno
ericvolkelbarno
Participant
 
Posts: 41
Joined: Wed Mar 07, 2007 6:28 am

Re: Export Problem

Postby russell@centuryc.com » Mon Jul 18, 2016 4:52 pm

ericvolkelbarno wrote:We hadn't upgraded in awhile, and just decided to go with the latest version... not sure, there might be service or fix packs out now.


As a matter of fact, there's 5 fix packs and a service pack out. (Which includes support for Windows 10!) You might want to apply that service pack.

Now, as long as you're looking at release folders - keep in mind that using mapped drives is a bad idea. They can become unmapped and are not supported when you run Export as a service. So I'd change all mapped references to a UNC.
Russell
russell@centuryc.com
Participant
 
Posts: 3374
Joined: Wed May 17, 2006 12:53 pm
Location: USA

Re: Export Problem

Postby ericvolkelbarno » Tue Jul 19, 2016 5:29 am

Good morning,

To begin, thank you very much for your responses.

In my opinion the most important thing in your email concerns the "Release working directory," and I want to enquiry about it first.
We really haven't paid attention to this setting before the problem just recently discovered. The Export script defaults this setting to the local c drive of the machine performing the Export operation.

Is it better to have the Release Working Directory set to a server folder, or to the local hard drive of whatever machine is performing Export (which may be a client, or a server)?

----------------------------

We have been looking at the service pack... one thing I find interesting in the SP's notes is that vs. 10.2 saw an increase in db activity... I wonder if this increase led to any particular type of errors?

One thing we have realized is that unattended batches left open in a Kofax module, or just an unattended Kofax module left open on a person's workstation, tends to lose session connection viability, which, we think, is putting these particular machines into an unstable state and may be contributing to the problem.

When we first converted to 10.2 we tried the new user "time-out" setting in 10.2, but quickly learned that, at least in our environment, this setting did not work correctly... the time out was kicking people off even when they were in the middle of processing Kofax batches in Kofax modules. So we backed out that setting change and haven't used it since. I am wondering if there are some problem with the Kofax code operating the time out feature that is interfering with our database communications, (or perhaps versa, maybe db communications is interfering with the time-out code?).

Again, thank you very much for your helpful ideas and suggestions,

eric volkel-barno
ericvolkelbarno
Participant
 
Posts: 41
Joined: Wed Mar 07, 2007 6:28 am

Re: Export Problem

Postby russell@centuryc.com » Tue Jul 19, 2016 12:21 pm

Let me go back to this one:
ericvolkelbarno wrote:We are using SQL Server Enterprise for the Kofax db; having a fairly large system, using the built in db doesn't seem practical.


Define "large". In my mind, there's only a few reasons to go to your own database:

  • You want to have access to the database.
  • You want to store your batches in the database. (For example, you're running Capture over a slow link and not using ACIS.)
  • You want to back up the database using "normal" enterprise level backup tools.
  • The default SQL password doesn't meet the enterprise requirements.
  • You want to keep user stats for a longer period of time and will exceed the 2GB limit.

I've tried storing batches in the database and it failed - miserably. I'm not sure as I have enough to gain to try it again.

By default (batches not in the database), all that's in the database is what you see in batch manager. The actual index and page-level information is stored in the Access MDB files. The built-in SQL Express is just to coordinate the actions of the different stations. Such as what's available for processing and who gets to do it. (In Capture 5 and before, it was a MDB file - but it tended to corrupt a few times a year, so Kofax switched to SQL Express. By default, the details of the batch itself - things that are NOT "multi-access" are still in MDB files. Which seems to work just fine on a fast network.)

By adding your own database, you're creating another variable that could be causing problems.

Now, I do run a pretty big operation, and yes, I do run SQL (not the built-in), but I'm also free of Enterprise requirements that might impose some non-compatible requirements on me.


ericvolkelbarno wrote:Good morning,Is it better to have the Release Working Directory set to a server folder, or to the local hard drive of whatever machine is performing Export (which may be a client, or a server)?

OK, by "Release Working Directory", I assume this is a script where the file is written to a temporary spot before it gets handed off to the API that loads it into the back end. While a UNC to a network location should be fine (note my prior caution against a mapped drive), it might be preferable to have it save to the local drive. This will reduce network traffic. It will also reduce the number of anti-virus software that may dig it's hands into it. However, that location is going to have to be available for every machine that runs the Export.
Russell
russell@centuryc.com
Participant
 
Posts: 3374
Joined: Wed May 17, 2006 12:53 pm
Location: USA

Re: Export Problem

Postby ericvolkelbarno » Tue Jul 19, 2016 12:52 pm

Hi,
Large system:

• We have had over 200 active users in the last 90 days (many more are listed in the Users table)
• 78 groups
• 87 (with some test bcs) batch classes
• Kofax installed on approximately 200 computers
• 25 remote stand-alone workstations from Rockford IL to Marion IL
• Large clusters of clients in multiple locations in Chicago and Springfield
• Five main dedicated imaging server, along with other data source/repository servers

I really don't know what constitutes a large system in order to make a good comparison, but, to me, on most days, feels fairly large.

I am not sure what you mean by storing the batches in the db... the tiff images are stored as files on a main server; only the metadata, and system data are stored in a sql server enterprise db.

We have developed extensive Crystal Reports from the data in the db because, (I haven't looked at recent versions of Kofax Reports), we needed to break user statistics out according to groups, and that didn't seem available, (plus the Kofax reports always seemed so slow).

Plus I have used my access to the db in order to trouble shoot problems and also track batches through the system after they have been deleted.

Plus, it has been necessary to use the db for audit purposes, (one of my main disappointments is that there doesn't seem to be any audit history for admin level staff making changes in the Administration module).

Plus, we do have fail over in case one of the servers fail.

I am going to do some testing with the unc path... this is a setting inside the Kofax to IBM Content Manager Release Script.

I have watched the tiff images being created and deleted in the temp folder... it seems like a pretty instantaneous action. But I wonder if it isn't creating more traffic since the tiffs are actually stored on the main server... so the tiffs must be copied to the Export station (either server or client) and then exported to CM.

One of the things we have found is that there are leftover images in the Temp folder that should not be there, and we are assuming that happens when Export is crashing.

Thanks for your input. Sometimes I feel at a disadvantage, because most of what I know has just been through hard scrabble and research.

Please have a pleasant afternoon,

eric volkel-barno
ericvolkelbarno
Participant
 
Posts: 41
Joined: Wed Mar 07, 2007 6:28 am

Re: Export Problem

Postby russell@centuryc.com » Tue Jul 19, 2016 1:14 pm

ericvolkelbarno wrote:I am not sure what you mean by storing the batches in the db... the tiff images are stored as files on a main server; only the metadata, and system data are stored in a sql server enterprise db.


Fire up "dbutil". At the bottom of the main page is "Store batches in SQL Server" checked? If it is NOT checked, then the page/document level metadata will be stored in MDB files found in AscentSV\BatchDB. All that will be in the SQL database will be batch level information and history. Checking that box moves the MDB files into SQL.

You have a good case for keeping yours separate because you want to be able to dig into some of the information. But it does put more responsibility on your to configure the database properly.

==================

I'm not sure if it still does it, but at one time I've seen Kofax uses a very inefficient method to create multi-page tiff files. It appears to work like this:
  • Copy page 1 from temp to release
  • Copy from release (page 1), add page 2, write back to release
  • Copy from release (page 1 and 2), add page 3, write back to release
  • Copy from release (page 1, 2 and 3), add page 4, write back to release
  • etc.
IOW, it's using a simple "append one page" routine and doing it for the number of pages in the document.

So if release is on a network drive, that's a lot of traffic if you're writing 100+ page documents. That's why it might be better to do that on a local drive. Again, I'm not sure if it's still doing that, but it sure seems to go slow if you've got large documents.

This also makes Kofax a "canary in a coal mine" when it comes to network issues. You can end up with corrupt TIFF files if it's at all glitchy.

As for the handoff between Kofax and IBM. That depends on how it works - does the server fetch the completed image or does the workstation serve it up? I suspect it's the latter since otherwise the server would have to have rights to the stored location. In that case, local storage would reduce the network traffic.
Russell
russell@centuryc.com
Participant
 
Posts: 3374
Joined: Wed May 17, 2006 12:53 pm
Location: USA

Re: Export Problem

Postby ericvolkelbarno » Wed Jul 20, 2016 5:35 am

Good morning,

Thanks for explaining the checkmark in dbutil for "Store batches in SQL Server." It is checkmarked.

I did a little testing this morning, trying to find if Kofax "builds" a multi page tiff in the Release directory. Was difficult grabbing a tiff because the operation happens so quickly (even with 100+ page documents). It does build the tiff inside the Temp folder one at a time (apparently). At the point I was able grabbed a tiff that was associated with a 141 page document, the tiff only had 9 pages in it.

Now, whether the tiff is being sent back and forth between the station and server between each page addition would need the involvement of our network people to watch the traffic.

We do have two servers dedicated to Release... I am thinking of maybe putting a unc to a folder on one of the servers to be the Release working directory.

Thank you,
eric
ericvolkelbarno
Participant
 
Posts: 41
Joined: Wed Mar 07, 2007 6:28 am

Re: Export Problem

Postby russell@centuryc.com » Wed Jul 20, 2016 12:12 pm

ericvolkelbarno wrote:We do have two servers dedicated to Release... I am thinking of maybe putting a unc to a folder on one of the servers to be the Release working directory.


Or, you could just set it to "C:\Temp". Just as along as all machines doing release have that directory with rights to it, no problem. That would cut down the network traffic.

I've never tried anything fancy like "%Temp%", that that might work as well.
Russell
russell@centuryc.com
Participant
 
Posts: 3374
Joined: Wed May 17, 2006 12:53 pm
Location: USA


Return to Kofax Capture General Discussion

Who is online

Users browsing this forum: No registered users and 3 guests

cron