The Back Orders tab is where you define List properties associated with back orders. To get to the Fields tab of a List, double-click on the desired List in the Toolbox. Then select the Back Orders tab.
This tab has the following properties:
Back Order Queue Strategy
The Back Order Queue Strategy defines how back orders will be prioritized for a given value. When a value is pushed onto the List, outstanding back orders are processed for that value in the order defined by this queue strategy. It should be an SQL ORDER BY statement that references at least one puller-dependent field. This is because the back order queue strategy is used to prioritize back orders against a single entry. An ORDER BY statement that gets data only associated with the entry value would consequently have the same result value for all back orders, and would thus be unable to properly prioritize the back orders.
A few examples:
ORDER BY Puller.priority DESC - This will prioritize the pullers who have
the "priority" label with the highest value.
ORDER BY pullerPriority DESC - This example is essentially the same as the
previous example, except that here you would need to explicitly add a dynamic
puller-dependent expression field named pullerPriority, and give it the expression:
puller.priority. This expression tells FlexSim to check the value of a label
named "priority" on the puller.
ORDER BY distance ASC - This example will prioritize the back orders with
the lowest distance value, which usually defines a distance between the value and the
When defining a back order queue strategy, you can also store label values on back
orders, and then use a special
BackOrder keyword in the SQL ORDER BY clause.
This allows you to define queue strategies that depend on specific values of back orders. To
do this, you first need to store values in back order labels. The following code stores a
label named "priority" on a pull result's back order with a value of 4.
List list = List("List1");
List.PullResult result = list.pull("", 1, 1);
result.backOrder.priority = 4;
Once you have stored label values on back orders, you can access them in the back order queue strategy:
ORDER BY BackOrder.priority DESC
Generally this is not needed since you can store labels on the puller object, and then access them in the back order queue strategy. However, storing and accessing labels on back orders can be useful if the same puller object may have multiple pull requests at the same time, and you want to distinguish between them in the queue strategy.
Unique Pullers Only
Check this box to disallow multiple back orders with the same puller. If this is checked and a pull request is made with the same puller as an existing back order, then that pull request will replace the previous pull request.
Allow Multiple Pushes Before Back Order Fulfillment
If this box is checked, the list will wait effectively zero seconds after a push before processing back orders for the pushed value(s). This means that if multiple values are pushed onto the list at the same simulation time, all those values will get on the list before back orders are fulfilled.
This setting is useful in several cases. First, if you are pulling from the list with an ORDER BY clause in your pull query, then you will likely want to allow all values onto the list before evaluating the query, so it can consider all values pushed, instead of just pulling as soon as the first one gets on. Second, if you are pulling from the list with a required number less than the requested number, then allowing multiple pushed values onto the list before fulfilling the back orders can get you closer to your requested number.
To allow multiple pushes, the list creates an event in effectively zero time after a value is pushed to the list to process back orders. This is "effectively" zero time because the event is not created at exactly the same time as the time the value is pushed. Rather, the event's time will be incremented by the smallest amount representable by a double precision floating point value. This means that all events created at the exact same time as the original push will be executed before the back order fulfillment event, even if those events are created after the original value is pushed. And while the back order fulfillment time is not exactly the same as the push time, it is effectively the same.
When this box is checked, the listpush() command will always return null. In other words, since back orders are no longer fulfilled synchronously with pushes, they will never be fulfilled in time for the listpush() command to return a valid value telling who pulled the pushed value.
Reevaluate All Values On Pushes
By default, back orders on the list will only evaluate new values that are pushed to the list. Check this box to cause all values (those already on the list and those being pushed to the list) to be evaluated for every back order whenever a new value is pushed to the list. This can be important if there are dynamic fields that may change and cause a value already on the list to be pulled when another value is pushed onto the list.
Sort Back Orders Before Evaluating Entries
This setting determines how back orders will be sorted when they are reevaluated for all entries on the list. The default is not checked. Here the list will iterate through each entry on the list, sort back orders associated with that specific entry, then match the highest priority back order to that entry. Alternately, when this box is checked, the list will sort the back orders once, then iterate through each back order and fulfill that back order based on its pull query.
Back Order Reevaluation Events
This pane lets you define when back orders should be reevaluated. This is usually only
needed if in your pull request you have a WHERE clause whose result may change while the
back order is active. For example, consider the following query:
WHERE queueSize <= 5. If the pull request is made at a point when queueSize is
greater than 5, then you may want to reevaluate that pull request when queueSize becomes
less than 5. FlexSim doesn't automatically know when this condition may change, so you need
to define events that will trigger reevaluation.
To add a reevaluation event, click on the button, and choose an event to add. Then choose the Event Type you want to listen for.
There are several categories of reevaluation events, as follows:
- Puller Event - A puller event is an event that happens on the puller. Here the puller must be an object (not a number or string). When a back order is created, the List will listen for the defined event on the puller object, and when the event fires, the back order will be reprocessed for all values in the list.
- Value Event - A value event is an event that happens on the value, i.e. the primary value of an entry. Here the value must be an object (not a number or string). When the value is pushed to the List, the List will listen for the defined event on the value object, and when the event fires, all back orders will be reprocessed for that entry.
- Global Event - A global event is some event that is not associated with either values or back orders. The List will listen for this event and will reprocess all back orders whenever the event happens.
- Time Interval - A timer interval event will cause the List to repeatedly reevaluate back orders at a set time interval. When the first back order is added, the List starts the timer loop and reevaluates back orders after the given time elapses. The timer loop ends when the back order queue is emptied.