Author |
Message
|
sshaker |
Posted: Thu May 22, 2003 2:02 pm Post subject: |
|
|
 Disciple
Joined: 20 Sep 2002 Posts: 185
|
hi john
Quote: |
I certainly hope you are not retrieving container values |
we are certainly need to use container vaues to sort.. but the question is how best we can utilize the available capabilities of workflow.. as u know we have little options.. we are trying to do 'little circus' outside the workflow and generate a unique key .. which can be used to sort.. thus avoiding complex sorting inside wf.. and even for that one field.. we need to push into description field and sort on that field..
Quote: |
A little Java app that serves up Workitems |
we are not sure about performance implications if we use a server.. any good or bad experiences on this approach?
regards
shaker _________________ shaker |
|
Back to top |
|
 |
jmac |
Posted: Thu May 22, 2003 2:07 pm Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
You need to try to do this without accessing the container for each of 25K workitems. I can not see anything GOOD from a scenario like this.
How much data do you have? Can you use the description? I am hesitant to say too much without knowing exactly what you are doing.
As to performance of the server, I have nothing to go on, but I can assure you it will be negligible compared to accessing the 25K workitems and then getting their containers, and then getting the member(s) you need. _________________ John McDonald
RETIRED |
|
Back to top |
|
 |
sshaker |
Posted: Thu May 22, 2003 2:18 pm Post subject: |
|
|
 Disciple
Joined: 20 Sep 2002 Posts: 185
|
hi john
our initial try is to do it without getting into containers..for that we need to generate a 'key' outside... and use that key to sort.. i can simply use that key in description..
if i try to push the sort condition into the description .. it is hell.. so many variables.. there are quite a few number of container fields .. which have to be used to arrive at a condition based on which the list has to be sorted.. bu putting allthose fields into description field will not help as it is not that plain to use the fields to sort.. hence, one key which is a representation of the condition ... is what we are trying to push into the description field.. lets hope we reach some conclusion
regards
shaker _________________ shaker |
|
Back to top |
|
 |
jmac |
Posted: Thu May 22, 2003 2:57 pm Post subject: |
|
|
 Jedi Knight
Joined: 27 Jun 2001 Posts: 3081 Location: EmeriCon, LLC
|
I can pretty much tell you that you will not get any kind of performance if you are going to do the following (This is what I understand based on this thread)
1. Retrieve 25K workitems
2. Loop thru each workitem and access container.
3. Access members for this container.
4. Sort the list
5. Serve a workitem.
Then you are going to do this each time a user wants a new workitem. IMHO this will not work. _________________ John McDonald
RETIRED |
|
Back to top |
|
 |
slnelson76 |
Posted: Tue May 27, 2003 12:20 pm Post subject: Okay what about this |
|
|
Novice
Joined: 02 Apr 2003 Posts: 13 Location: Iowa
|
Option 1 (I think someone already went over this)
Override the checkin command (ie x-checkinandgetnewitem) use the api's to perform the check-in as normal.
Retrieve an item from a list of items that have already been retrieved.
If it's the first time, or the list hasn't been created query for some work items. perform some logic on them.
Transfer the returned item to the current user.
Show the users current work items.
Effectively the item gets pushed out the user every time they check something in. But by caching 100 or so items you don't pay the price for the query.
Option 2. Have a UPES activity before the User activity that basically performs logic on the values in the container to produce a priority score. Higher number gets worked first etc.
Map this Score into the description field
Place that in the sort criteria for the worklist.
Put a threshold of 1 on the worklist. |
|
Back to top |
|
 |
|