cancel
Showing results for 
Search instead for 
Did you mean: 

WF Purge Action Performance

Ken_Busby
Confirmed Champ
Confirmed Champ

I have a customer using virtual eforms extensively, 100s of thousands of documents.

We have a WF that processes some virtual eforms as part of a daily process.   The WF timer takes action on the form and when complete, executes the WF action PURGE DOCUMENT.

This timer was being executed under a v16 scheduler service successfully.   Upgrading to v18.0.1.69 has a serious issue.   Each form is taking 30-40 seconds to purge and the timer cannot keep up with the volume.   Diagnostics shows the SQL below being executing for EVERY PURGE operation.   This SQL is the bottleneck as it is returning the 100s of thousands of valid forms in the system.

I cannot fathom the usefulness of that statement for each purge operation.

I need to know if there is a specific setting somewhere that is causing this or if this has been fixed in a later build of 18.

Thanks.

(

@Paul Lloyd - Being a WF guru I am hoping you can weigh in on this.

)

 

    select itemnum from hsi.itemdatapage

                 where diskgroupnum=0 and logicalplatternum=0 and filepath=''

1 ACCEPTED ANSWER

Paul_Lloyd
Employee
Employee

@Ken Busby 

The query you referenced is inefficient (indeed it's unnecessary) if the document involved is a Virtual E-Form (no physical pages).

 

I was able to track down an SCR that identifies this issue and fixes it by eliminating the query if there are no physical pages. It looks like it was introduced in the initial builds of OnBase 18 and fixed in build 18.0.1.73. So unfortunately 18.0.1.69 does have the problem.

 

I suggest you contact your First Line of Support and request an upgrade to the latest OnBase 18.

You can reference SCR #324260

View answer in original post

2 REPLIES 2

Paul_Lloyd
Employee
Employee

@Ken Busby 

The query you referenced is inefficient (indeed it's unnecessary) if the document involved is a Virtual E-Form (no physical pages).

 

I was able to track down an SCR that identifies this issue and fixes it by eliminating the query if there are no physical pages. It looks like it was introduced in the initial builds of OnBase 18 and fixed in build 18.0.1.73. So unfortunately 18.0.1.69 does have the problem.

 

I suggest you contact your First Line of Support and request an upgrade to the latest OnBase 18.

You can reference SCR #324260

Thanks for confirming.