Client Support
Showing results for 
Search instead for 
Do you mean 

TRIM 7.1.2 2017 - how to reduce the number of pending DCI transactions

Regular Advisor

TRIM 7.1.2 2017 - how to reduce the number of pending DCI transactions

Hi,

 

We've been having problems with the automatic DCI; When the record, marked as DCI'able, is collected by the DCI engine for processing (from TSEVNTDAT), BUT before it is actually processed, if that record has its attached document replaced - that is, the path to the document, as recorded in the DCI event, is no longer valid, that causes the DCI engine to get blocked by error and the only solution to that is to delete that entry from TSEVENTDAT.  Quarantening that record in TRIM doesn't seem to work and DCI simply ignores the quarantening flag in TSRECORD. 

 

 

As far as I know, the DCI engine works on batches of 100 transactions, so, before it gets to a particular transaction, the relevant record might have been changed (that is, the attached document replaced ).  

 

Is there a way how to reduce the number of transactions in the transactions batch for DCI, so that, whenever the entry for DCI is created in TSEVENTDAT, ISYS gets it processed immediately?

 

 

 

Thanks

Alex

4 REPLIES
HPE Expert

Re: TRIM 7.1.2 2017 - how to reduce the number of pending DCI transactions

Hi Alex,

 

You can reduce the size of the transaction file in the TES in the content index options, under the dataset:

 

The TRIMPending.bin file is used for bulk updating of DCI. It stores multiple updates so that more than one update can be committed to the index in one process. This is faster and more efficient than committing one update at a time.


The number of updates that are stored in the TRIMPending.bin file before it is committed to the index is controlled by a setting in the TRIM Enterprise Studio - DCI Properties. 'Number of transactions in the index update file'.


This value needs to be set based on the current processing requirements. For day-to-day processing, the value should be set to a lower value, between 1 to 200 depending on the frequency of document creation in TRIM. For re-indexing purposes, the value should be set much higher as a large number of documents will need to be processed from the store. For example a value from 1000 to 10000 is normal for a re-index.


When you are doing a complete re-index you would generally set the “Number of transactions in index update file” to a larger value, such as '10000':

**Any opinions expressed in this forum are my own personal opinion and should not be interpreted as an official statement on behalf of Hewlett Packard Enterprise**
Regular Advisor

Re: TRIM 7.1.2 2017 - how to reduce the number of pending DCI transactions

Hi Greg,

The value is set to 1, so, it should be processed immediately, as soon as an event is created in the table. I am seeing the different problem here, though. When multiple DCI events are created and ISYS begins processing them, 1 by 1, some of the documents may take long time to get indexed. If, in the meantime, the document, marked for DCI, is replaced - that is, it no longer exists in TRIM - and the DCI begins processing that event (which refers to a record with the replaced document), this causes the DCI to become blocked by errror , like this:

HP TRIM Workgroup Server running on user02.main.dva reported the following message:
Error : VA User: USER02 - Error processing event on database 'GA' for processor 'Content Indexing', event details: 10766101, boburi=10081703, storeid=001+00F+0E6B09KA1AZ.DOC, error details: Function request (Extract Document) for HP TRIM Workgroup Server 'localhost' failed. Cannot read the file '\\Atmp01\I$\EDMDATA3\VA\8\001\00F\0E6B09KA1AZ.DOC'. The system cannot find the file specified. (0x00000002).

Quarantening the record doesn't seem to help here... do you have any suggestions in this scenario?

Thanks
Alex
HPE Expert

Re: TRIM 7.1.2 2017 - how to reduce the number of pending DCI transactions

Couple of things that I would check:

 

Make sure that the DCI chains are located on the same server as the Event processor. If they are not you should move them on to the event server. The closer they are the faster they will process.

 

Make sure that the machine is spec'd well enough to handle the applications running on that machine along with the DCI processing.

 

Ensure that the event processor is running smoothly, any pending events will increase the frequency of that message.

 

I would think that is more likely that a slow event server might be causing the problem rather than the DCI transaction file.

**Any opinions expressed in this forum are my own personal opinion and should not be interpreted as an official statement on behalf of Hewlett Packard Enterprise**
Regular Advisor

Re: TRIM 7.1.2 2017 - how to reduce the number of pending DCI transactions

Machine 's got enough resources to run DCI et al. ISYS databases are located on the same machine as the Event server that serves the DCI.

We cannot reduce pending events, because, sometimes, there are bursts in uploading the documents into TRIM and DCI engine struggles to process them in time.

Every time teh ISYS gets blocked by error and cannot proceed, I check for any TRIMTrans.bin or TRIMPending.bin files and there is none of them.

I can see the following happening:
- when the document is replaced, the relevant DCI event doesn't get updated/removed;

- when I quarantine the record, that has the missing document (e.g., the document, that was replaced), DCI engine ignores isQuarantined flag when attempting to process the DCI events for that record.

Do you think it may be fixed somehow, (upgrading is out of question, unfortunately). ?

Regards
Alex
//Add this to "OnDomLoad" event