one central search page

[tom.baeyens]

This topic is part of the web console feedback http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmConsoleFeedback

I would like one central search page that can be used to search for
* Process definitions
* Process instances
* Task instances

I think it would make sense to have this as one page cause various links could navigate to this page with prefilled criteria:
* process instances for a process definition
* task instances for a process instance
* task instances for a task
* task instances for a process definition

i think that would be a concept that people quickly start to grasp: if they click a link 'process instances' in a process definition page that they are navigated to the search results screen.

that also gives them easy ways of starting to tweak and change the search criteria to refine their search.

[kukeltje]

But I wold certainly not ditch the filtering at the top of the lists. Maybe they should be invisible at first and have an magnifying glass to open it. An 'advanced' button could take you to the generic search page with things on it like 'search processinstances with a variable y and value x'

[dmlloyd]

The problems I see with this are as follows:

* Having one single set of search criteria is more complicated than having separate searches. Initially I did do this. I tried to simplify it by having a select list where you'd select the type of search you wanted to do, and it would update the search criteria for the new search type, but this was much more complicated than the final search mechanism that i ended up with. By complicated, I mean complicated to implement AND confusing for the end-user.

* We will need to keep track of where the user came from so they can easily return. Again this is doable in a couple of ways, but I think an overriding priority is bookmarkable URLs for pages, and this might compromise that. A bookmarkable URL implies statelessness, which would be complicated if we must track where a user navigated from at run time. For example, if I went from the Process page to find Process Instances, I'd want a link back to that process page to be right at the top. But if I bookmarked that URL, now that URL should contain something that indicates that you navigated to that search results page from the Process page.

I think having a single search page is too confusing, unless you have an idea for how it can be laid out.

We could however do (for example) one search page per result type, or use tabs to separate searches. The latter is tougher (but possible) to bookmark though.

*

[jeffdelong]

I think there should be two search pages: one to support process management (processdefinitions and processInstances), one one to support task management (for taskInstances).

ProcessInstances: search criteria to include processdefinition, start date, status /state (i.e., active, completed, suspended)

TasksInstance: search criteria to include taskname, create date, start date, end date, status / state, processinstance, actorId, pooledActorId


Having said this I again raise the concern about performance. Is the database schema and gui architecture able to handle these types of queries when there are 20,000 processInstances and 100,000 taskInstances in the db, and the query results in 2000 hits?

[dmlloyd]

"jeffdelong" wrote:
Having said this I again raise the concern about performance. Is the database schema and gui architecture able to handle these types of queries when there are 20,000 processInstances and 100,000 taskInstances in the db, and the query results in 2000 hits?

In a word: Yes. :-) Well, subject to testing anyway.

Well, at least for the two types of data you've mentioned (process instances and task instances).

Process Definitions are a problem. If we had 100,000 processes each with 100 versions it would be slow (to get a list of the 100,000 processes, we can't use things like limit/offset because it's a grouping operation, meaning that the server would [in this contrived case] have to accumulate 10,000,000 rows before it could return even the first 10). I'd like to see this addressed at least for the new prototype as I've outlined in other posts.

The other queries (in the GUI) are designed right now to impose a hard limit of 100 pages, under the rationale that more than 100 pages is not useful to the user and that they should reduce the search. This number is configurable as well. The advantage to this approach is that the database does not need to be hit to fetch each page, which avoids a race condition where the result set changes between pages causing rows to appear to vanish (where in actuality they have simply moved from the page you are on to a prior page). The disadvantage is that the search can result in a fairly good-sized chunk of data coming from the database (though in my actual experience it takes more than about 5k rows to start slowing things down; after all, we're only displaying one page at a time, and in most cases the real bandwidth bottleneck is between the web server and the end user, not between the web server and the database).

At some point we should be able to add well-performing sorting to this model as well, assuming judicious use of indexes.

[tom.baeyens]

can i conclude that there is concensus to have 2 separate search pages: one for task instances and one for process instances ?

open questions:
* will both of these have a menu item ?
* will there be a process definition search as well ?
* if not, what will be the way to start a new process instance of a process definition ?

Maybe we should have following menu items: 'Tasks', 'Processes' (process definitions) and 'Executions' (process instances)

Just a suggestion:

Tasks: shows the user task list by default. I would put the search criteria form below the user task list. By default, the current actor criteria field is set to the authenticated user...

Processes: shows the list of processes. By default the list will filter out all processes that are not the highest version for a given process name. Also here below the list, we could have the search criteria that can be refined by the user.

Executions: shows the process instances sorted by start date descending by default. Also here i would put the dearch criteria form below the actual list.

On performance: I would not be bothered by performance now. The architecture is build for scalability. Fixing issues will be dealt with later. Functionality, navigation and ease of use are more important for now.

[bazoo]

Sounds good to me. One small point - personally I would prefer the menu item to be entitled "Instances" rather than "Executions". The word is slightly less technical and therefore more instantly understandable to the end user.

Regarding the two separate search pages. To keep navigation simple, how about having one menu item "Search" then two tabs, one "Tasks" another "Processes"?

Regarding starting a new process. To me that is an important operation, and deserves its own place in the main menu structure. Perhaps you would click the "Start process" menu item, which would result in a page listing all the process definitions available to be started. The user would then click a button "Start" next to the one they want. Just an idea.

Cheers

Matt

[dmlloyd]

Sounds OK... are you sure you want to use "Executions" though?

[jeffdelong]

I prefer ProcessInstances over Executions. Not only more understandable to the user, but consistent with the jBPM object model / API.

In general I would try not to re-invent terms if jBPM already has a good term for something. ProcessDefinitions and ProcessInstances are not only jBPM terms, but are pretty much "industry standard" (as much as there are standards in the BPM market).

[tom.baeyens]

Sounds OK... are you sure you want to use "Executions" though?

no. i'm not sure :-)

take whatever you think is best from all the suggestions in these threads.

[tom.baeyens]

forgot to add: jeff also makes good sense:

"jeff" wrote:
In general I would try not to re-invent terms if jBPM already has a good term for something. ProcessDefinitions and ProcessInstances are not only jBPM terms, but are pretty much "industry standard" (as much as there are standards in the BPM market).

[dmlloyd]

Ok, I'm going with three different search pages: Process, Process Instance, and Task.

[tom.baeyens]

Ok, I'm going with three different search pages: Process, Process Instance, and Task.

good conclusion.

the only thing i'm still in doubt about is wether all three search pages should show up as separate items in the (fixed) menu. currently, i'm inclined to go for 3 separate menu item links.