Guidelines for processing large orders

You can review the information about the best practices and system design considerations that should be taken into account when you have to process orders or shipments that have a large number of order lines.

That number varies depending on many factors, such as order complexity. As a general guideline, we recommend that you consult Sterling Support if you have to process orders that have over 200 lines. These could, for example, be large, planned purchase orders in B2B associations.

Best practices

Customers have used numerous strategies to handle large orders. Some of these strategies are described here for your consideration. Their applicability will, however, depend on your business requirements:

Build a custom screen to view large orders.
You can develop a custom, HTML-based user interface to display the order in smaller sections.

For example, you can create a custom screen that calls the getOrderDetails API with a selective output template to display only the order header information (and not the order line information). This will significantly reduce the amount of data that is to be retrieved from the database, and the size of information to be displayed on the HTML screen. This HTML screen can have a button to allow the user to get a list of the order lines. When the user clicks this button, the getOrderLineList API is called to get a list of order lines. Again, through the use of the output template, you can control the amount of data retrieved and displayed. Finally, when the user clicks a specific line, the getOrderLineDetails API is called to get all the information relating to that line.

There are many variations to this technique. The actual implementation is dependent on your use case scenarios.
Break up large orders into smaller, but manageable orders.
Some customers have opted to break their large orders into smaller chunks for manageability. One approach is to develop a front end process to split the orders based on business rules, prior to the orders entering the Sterling Distributed Order Management application. The procurement analyst can use the Master Order field, for example, to find all the related orders.
Decouple heavy processing from the user interaction.
Decoupling long-running processes from user interaction can result in a faster response.

For example, let us assume that you have to receive a large shipment of serialized items on a single pallet. This could be, for example, a pallet of 10,000 gift cards, each having its own serial number. As part of the receipt process, each item is assigned to one serial number.

In this case, you may want to consider implementing custom screens to allow users to view the shipment, serial numbers, and a button to trigger the receipt and serial number registration in the background. This can be achieved by having a button, which, when clicked, will send a message to a background agent to process the receipt and serial numbers.

Thus, the user will be able to continue working when the receipt and serial number processing is being performed in the background.
Test the application with large orders.
Ensure that you include the largest anticipated orders into your testing. Plan the test with orders larger than your largest orders. For example, if you expect 1,000-line orders, test with orders containing 1,200 lines.

Other architectural considerations

The system design or architectural approaches described in this section typically yield sub-optimal performance when working with large orders:

Using the HTML-based Order Detail screen to display a large order.
As described earlier, the standard, product Order Detail screen retrieves both the order header and order line information. This approach is not optimum for large orders because the screen has to retrieve and display all the details of the order.
Displaying large amount of data across slow networks.
Customers who are connected to low-bandwidth connections (for example, 56 kbps modems) or high-latency connections (for example, connected through satellite links) should impose a constraint on the amount of data that is to be displayed.

A general industry rule is to keep the actual network payload to 50 KB. Customers who have to send a lot of data should compress the output stream. Devices such as F5 Big-IP load balancers have built-in compression that can reduce the payload by 80%. With compression, you can generate screens that are up to 250 KB in size because the resulting compressed screen will be about 50 KB.

In practice, you should, as mentioned earlier, understand your use case scenarios. Displaying the data in smaller chunks may be more appropriate because it is unlikely that you will need all the data from all the lines.
Test with representative conditions.
Your testing environment should reflect the actual production conditions. For example, as mentioned earlier, if users are located at remote locations on high-latency networks with low bandwidth connections, you should not test the user interfaces on fast, local area networks. You should, at a minimum, run tests from the actual remote locations. If this is not feasible, you should consider simulated WANs. For example, you can run your tests through Shunra Software Ltd. devices to assess the impact of slower networks.

Similarly, you should test the application with representative, production database sizes.
Performing too much processing per order line.
When retrieving and processing the list of order lines, be aware of the processing required for each order line. Although the processing required may be low for each line, the processing can be significant when there are many lines.

For example, assume that you want to calculate the cost of the items associated with each line. Further, assume that you need to call an external system to get the price, and the pricing call takes 200 milliseconds. If you have to display a list with 600 lines, the pricing calls could take 120 seconds. In some cases, it may be better to call the pricing engine once with 600 items, especially if the cost of the call represents the majority of the time. Alternatively, you can consider providing a button to allow the user to reprice the lines if repricing is needed.