Scenarios for using segregation

The line size and the attribute based workload segregation scenarios are explained in this topic.

Segregation scenarios for OrderHeaderKey data type

Following examples demonstrate the order line size and order attribute based workload segregation.

Order line size based segregation
Consider a scenario when you get many very large orders along with regular and large orders. The very large order fulfillment requires higher processing capacity and time. Instead of running every order on higher capacity, you want to process very large orders separately with the higher capacity and continue the processing of other orders with the regular capacity.
  1. The rules that define large and very large order size have the following default values.
    • LARGE_ORDER_SIZE = 20
    • VERY_LARGE_ORDER_SIZE = 500

      Call the manageRule API to configure these rules. The size that is configured in the VERY_LARGE_ORDER_SIZE rule must always be greater than the size that is configured in the LARGE_ORDER_SIZE rule.

  2. Consider the following orders that are captured in Sterling™ Order Management System Software.
    OrderHeaderKey Order number Number of order lines
    ORDER_1 ORDER_1 150
    ORDER_2 ORDER_2 10
    ORDER_3 ORDER_3 500
    For the ORDER_1 to ORDER_3 orders, the following YFS_TASK_Q records are created for the SCHEDULE.0001 transaction to further process the order.
    TRANSACTION_KEY DATA_TYPE DATA_KEY FILTER_CRITERIA
    SCHEDULE.0001 OrderHeaderKey ORDER_1 Large
    SCHEDULE.0001 OrderHeaderKey ORDER_2  
    SCHEDULE.0001 OrderHeaderKey ORDER_3 VeryLarge

    The FILTER_CRITERIA column is populated based on the rules that define large and very large order size. For regular and small orders, the FILTER_CRITERIA value is set to null.

  3. Define multiple agent criteria for workload segregation with the following values for Task Queue Filter Criteria.
    Agent criteria ID Agent server Task Queue Filter Criteria
    SCHEDULE.0001.REG_LARGE ScheduleRegularandLargeOrders VOID, Large
    SCHEDULE. 0001.VERYLARGE ScheduleVeryLargeOrders VeryLarge
    Note: All the criteria that are defined for an agent must be mutually exclusive. No catch-all criteria must be defined, otherwise it can interfere the processing of jobs between servers. You must stop running all the criteria where Task Queue Filter Criteria is not defined when you use the Task Queue Filter Criteria parameter.

    VOID is a valid Task Queue Filter Criteria value irrespective of the segregation policy. It is used to match records with null value in the FILTER_CRITERIA column of the YFS_TASK_Q table.

  4. Start the agent servers that you configured in the previous step.
    • ScheduleRegularandLargeOrders - This server retrieves and processes the jobs from the YFS_TASK_Q table that matches TRANSACTION_KEY (SCHEDULE.0001), DATA_TYPE (OrderHeaderKey), and FILTER_CRITERIA (null or Large).

      ORDER_1 and ORDER_2 are processed by the ScheduleRegularandLargeOrders agent server as the FILTER_CRITERIA for ORDER_1 is Large and ORDER_2 is null.

    • ScheduleVeryLargeOrders - This server retrieves and processes the jobs from the YFS_TASK_Q table that matches TRANSACTION_KEY (SCHEDULE.0001), DATA_TYPE (OrderHeaderKey), and FILTER_CRITERIA (VeryLarge).

      ORDER_3 is processed by the ScheduleRegularandLargeOrders agent server as the FILTER_CRITERIA for ORDER_3 is VeryLarge.

    In the same example, if you want to process the three types of orders (regular, large, and very large) separately, then you can define the following multiple agent criteria:
    Agent criteria ID Agent server Task Queue Filter Criteria
    SCHEDULE. 0001.REGULAR ScheduleRegularOrders VOID
    SCHEDULE. 0001.LARGE ScheduleLargeOrders Large
    SCHEDULE. 0001.VERYLARGE ScheduleVeryLargeOrders VeryLarge
Order attribute based segregation

Consider a scenario where a business supports different fulfillment models including Buy Product Online and Pickup in Store (BOPIS), Ship from Store (SFS), and you want the BOPIS orders to be processed (schedule or release) on priority among other orders in a separate agent server.

To fulfill the business requirement, complete the following steps:
  1. Configure the following properties.
    Property name Property value
    yfs.taskqueue.segregation.order orderattribute
    yfs.taskqueue.segregation.order.orderattribute OrderType
  2. Set OrderType attribute of the order according to the fulfillment model while capturing the order. Consider the following orders.
    Order number Order type
    ORDER_1 SFS
    ORDER_2 SFS
    ORDER_3 SFS
    ... ...
    ORDER_49 SFS
    ORDER_50 BOPIS
    For ORDER_1 to ORDER_50 orders, the following YFS_TASK_Q records are created for the SCHEDULE.0001 transaction to further process the order.
    TRANSACTION_KEY DATA_TYPE DATA_KEY FILTER_CRITERIA
    SCHEDULE.0001 OrderHeaderKey ORDER_1 SFS
    SCHEDULE.0001 OrderHeaderKey ORDER_2 SFS
    SCHEDULE.0001 OrderHeaderKey ORDER_3 SFS
    … … … …
    SCHEDULE.0001 OrderHeaderKey ORDER_49 SFS
    SCHEDULE.0001 OrderHeaderKey ORDER_50 BOPIS

    The FILTER_CRITERIA column is populated based on the yfs.taskqueue.segregation.order and yfs.taskqueue.segregation.order.orderattribute properties. As OrderType attribute is configured for the order attribute based segregation, OrderType values of respective orders are populated in the YFS_TASK_Q records.

  3. Define the following multiple agent criteria for workload segregation.
    Agent criteria ID Agent server Task Queue Filter Criteria
    SCHEDULE.0001.BOPIS ScheduleBOPISOrders BOPIS
    SCHEDULE.0001.SFS ScheduleSFSOrders SFS
    SCHEDULE.0001.OTHERS ScheduleOtherOrders VOID
  4. Start the agent servers that you configured in the previous step.
    • ScheduleBOPISOrders - This server retrieves and processes jobs from the YFS_TASK_Q table that matches TRANSACTION_KEY (SCHEDULE.0001), DATA_TYPE (OrderHeaderKey), and FILTER_CRITERIA (BOPIS).

      ORDER_50 is processed by the ScheduleBOPISOrders agent server as FILTER_CRITERIA for the order is BOPIS.

    • ScheduleSFSOrders - This server retrieves and processes jobs from the YFS_TASK_Q table that matches TRANSACTION_KEY (SCHEDULE.0001), DATA_TYPE (OrderHeaderKey), and FILTER_CRITERIA (SFS).

      ORDER_1 to ORDER_49 are processed by the ScheduleSFSOrders agent server as FILTER_CRITERIA for the orders is SFS.

    • ScheduleOtherOrders - This server retrieves and processes the jobs from the YFS_TASK_Q table that matches TRANSACTION_KEY (SCHEDULE.0001), DATA_TYPE (OrderHeaderKey), and FILTER_CRITERIA (null).
      Note: The ScheduleOtherOrders server must be used to process all the other records where OrderType attribute is not set at Order Header.
  5. After the records are processed by schedule order agent servers, the following YFS_TASK_Q records are created for the RELEASE.0001 transaction to further process the order.
    TRANSACTION_KEY DATA_TYPE DATA_KEY FILTER_CRITERIA
    RELEASE.0001 OrderHeaderKey ORDER_1 SFS
    RELEASE.0001 OrderHeaderKey ORDER_50 BOPIS
    RELEASE.0001 OrderHeaderKey ORDER_2 SFS
    RELEASE.0001 OrderHeaderKey ORDER_3 SFS
    … … ... …
    RELEASE.0001 OrderHeaderKey ORDER_49 SFS

    As OrderType attribute is configured for the order attribute based segregation, the OrderType values of respective orders are populated in the YFS_TASK_Q records. You can define multiple agent criteria for RELEASE transaction for workload segregation based on the OrderType attribute, same as for the SCHEDULE transaction.