Pulling from a Queue vs Sorting the Queue

All,

This model was created to demonstrate to another group how to use pull logic to pull the lowest itemtype value from a queue and how that same task can be done by sorting the queue on entry.

The top group of objects uses pull logic to pull the flowitem in the queue with the lowest itemtype value (darkest color) first. The bottom group uses the on entry trigger of the queue to sort the flowitems as they enter so that the items with the lowest itemtype values are on the bottom (first).

The pull requirement code is fired for each item in the up stream object until the code returns TRUE. When searching for a low, high, or other value it is very easy to write inefficient code. The pull logic in the top processor was written to be efficient. It does this by only searching for the item with the lowest itemtype value during the execution for the first item. It then saves the rank of the lowest value item in a label on the processor. The remaining executions of the pull requirement code will only check to see if the rank of the item it is checking for is equal to that label value. This way you are not executing a search algoithm for each flowitem.

This seems to be a very common problem that people run into. The purpose of this model was to show two of the many different ways that this problem can be solved and to show how to write more efficient code in the pull requirement field.

Let me know if there are any questions or comments,
Brandon

Brandon this is an excellent example, and you always do such a nice job of organizing and documenting your example models.

There's two excellent points I think you make with this example:

1. Sorting the flowitems as they enter the upstream queue (as in the bottom of the two examples in your model) is going to be the most efficient because the OnEntry code of the queue which sorts the incoming flowitems is only executed once per flowitem that enters.
2. When you do use Pull logic (as in the top example) it's important to remember that not only the Pull From Port field is executed, but the Pull Requirement will be executed for EVERY released flowitem in the upstream queue until it evaluates as "true" with EVERY time the processor is ready to receive a new flowitem. Your idea to only search the queue once when the first flowitem in the queue gets evaluated and save the minimum itemtype value in a label of the processor for reference when the subsequent flowitems are evaluated is very good.

I think it would be a good idea to include your code as a standard picklist option in the next software release. I can think of a few more examples that might be useful.

1. Pulling the item with the minimum or maximum label/itemtype value out of multiple upstream queues.
2. Pulling the longest waiting item with a user specified label/itemtype value out of multiple upstream queues.

Cliff,

Here is a model that answers your questions below. This model has three sources and queues that feed one processor. The processor's job is to pull the item with the lowest item type. If there is more than one item with that itemtype then it is to take the one what has been waiting the longest.

The processor has some custom code on the Pull From Port and Pull Requirement fields. Please note that the Pull requirement could have been left at the default "Any Port" and the code to decide the port could have been done in the Pull Requirement field.

While this model isn't exactly like either of Cliff's examples it can be easily modified to do either. If someone would like to see either of them exactly or would like to see how all of the code in this model could have been done on the Pull Requirement field please let me know.

As always the code is commented like crazy and I appreciate any of your questions or comments,
Brandon

P.S. - This model was not included in the Zip file that had all of the other XT example models in another post.

sounds good to me