Indexed Task Search - Business Data

, ,
1

Hi,

 I have upgraded my normal task search provider to an indexed search provider ([b]TaskInboxIndexedSearchContentProvider[/b]) as described here: [url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_sp2/Designer/8-2-SP1_BPM_Task_Development_Help.pdf[/url].

In the javadoc for ITaskSearchRecord it states:

And now I have 2 questions for which I have found [b]no clear answer[/b] in the documentation:
  • Can I include other business data in the Search Results besides what is defined for the indexes?
    The users are used to have about 25 configurable columns, but it is not practical for us to have 25 indexes.
    When the property “includeTaskData” is set to “true” it only refers to the indexed fields, not to the entire Task Data object
  • Is there a way to use other operators beside “equals” for the indexed search?

br,
Vlad

2

Hi,

I think that for problem 1 I have found a simple solution.
In the class corresponding to the results page (MyTaskInboxResultsDefaultviewView) you can fetch any business field you wish:

  
public String getMyBusinesField(){
	  String taskID = (String) resolveExpression("#{row.taskInfo.taskID}");
  
	  //you might have to provide the task type ID if you do not have a default constructor
	  MyTask task = new MyTask();
	  task.setTaskID(taskID);
	  String myBusinesField = task.getTaskData().getMyBusinessData().getDocumentDetails().getMyBusinesField();
	  return myBusinesField;
  }

The binding in the .view file:

#{MyTaskInboxResultsDefaultviewView.myBusinesField}

Besides the performance problem, does anybody see a reason why this approach is not a good practice?

br,
Vlad

3

The motivation for the indexed search is so that a query can handled entirely by the SQL server.

Task searches occur in 2 passes, first a query is executed against the database, then any search terms for non-indexed fields are evaluated on each task in the results of the first query. As you imagine, this can be quite inefficient, as each Task (and likely Task Data) would have to be loaded to evaluate the 2nd filter against.

With indexed queries, we duplicate some small piece of task data in the database and index it. This allows faster searches against this data using the first pass query, removing the need to iterate through tasks individually.

Your approach for displaying non-indexed fields is correct.

4

we had implemented indexed task search with around 27 business data fields fields. Don’t think it should be a issue

5

After introducing the indexing in the task search provider,
are you still getting the old task informantions which were created before the change?

6

yes, you will get it. To do that, go to task engine administration in MWS, click on your task type and click on ReIndex

7

Hi Ron,

Thank you for your answer.

If I understand right TaskInboxIndexedSearchContentProvider does the search exclusively on the indexed fields.
I was expecting that after the search base has been limited by the indexed search, then a search is also done on the Task Data. But your explanation unfortunately (for me) confirms the documentation (8-2-SP1_BPM_Task_Development_Help.pdf):

@mja4wm: Can you please tell me how long the indexing took in Production (there can be over 1 million tasks).
Does the indexing time increase directly proportional with the number of indexes?

@iman: No data is lost. During the indexing process the Task Data is replicated in the index table.
A useful video can be found here: http://techcommunity.softwareag.com/ecosystem/communities/protected/developer/webmethods/caf/demos/task-index-advanced-topics.html

I have seen that when using the “=” operator for indexed fields I can also search with “*” regex (but not with “?”) .
For example if the indexed field value is “subject 01” then search with:

  • “sub” - no matches
    “sub*” - all tasks that match the regex
    “subj*01” - all tasks that match the regex
    “sub?ect 01” - no matches

My question is if this is a feature or just a coincidence (I have not found it in the documentation).
There is the risk that I base my implementation on search with “*” and then some MWS “Fix” will remove this feature.

br,
Vlad