1. For the processors to influence which items are send to them, they have to be set to "Pull" items.
A "query" would be used to filter the items when pulling them off a list. If they are pulled from an upstream object this is done with the "Pull Requirement". If it evaluates to 'true' (a non-zero number), then the item can be pulled, if the result is 'false' (0) the item will not be pulled.
As such, to restrict the processor to items depending on the table you can use the value from the respective table cell as the pull requirement. The row is given by assigning a label to each processor denoting which row it belongs to. The column is the "ItemType" label on the item (note the offset of 1 for the column number, since the first column is the processor name)

The same expression could be used to query the items when pulling off a list. By adding an expression field to the list you can then use it in the query. Note that its the same expression as above - only the reference are adjusted (current -> puller, refers to the processor and item -> value to the item).


2. With the Pull option used as described in 1., the items would be distributed between the processors according to the constraints and enter the processor that is available first.
If you add the constraint to the "Send to Port" logic of the queue, the settings from 1. become redundant since the processor need not check anymore if they allowed to pull the item.
To do this you would have to write code that first finds all eligible port ranks and then choose one from those at random. Note that this does not work like the "First Available" logic above. An item might be send to a processor that is currently busy even if another eligible processor might be available.

For this code I changed the first column to contain the respective port numbers, so they can be used as the return value.
