RepositoryInventoryManager implements all the methods of the InventoryManager interface. This InventoryManager broadcasts events when levels are at a configurable “critical” level and when it is notified of updated inventory.

RepositoryInventoryManager implements all the methods defined by the InventoryManager API. It is a thin wrapper around a repository that contains the inventory information. This allows a maximum amount of flexibility for potential third party integrators. Integrators can simply implement a repository containing the required properties for cooperation with the RepositoryInventoryManager. The Repository InventoryManager can then be configured to extract inventory manager information from the third party repository.

The initial implementation of the RepositoryInventoryManager uses the a SQL Repository to store inventory information. In the future, another repository can easily be swapped with the SQL Repository.

The RepositoryInventoryManager requires that the inventory items stored in the repository have certain attributes. All items must contain the following properties and types to represent information the RepositoryInventoryManager needs to store in the repository.

Note: The names of the properties are configurable in the RepositoryInventoryManager. This allows them to be internationalized, custom configured, etc.

The RepositoryInventoryManager implements the InventoryManager interface by using the configured properties listed above to extract data from a configured repository. For example, the queryStocklevel method is implemented by getting the item with the requested ID from the repository and reading the <stock level property> property.

Using the RepositoryInventoryManager to Implement the InventoryManager

The following section describes how the RepositoryInventoryManager implements the InventoryManager interface.

Every item in the inventory has an associated SKU (Stock Keeping Unit). Each SKU has three levels associated with it: stocklevel, backorderLevel, and preorderLevel. The behavior of each of these levels is similar. If someone makes a successful purchase call, stocklevel is decreased. If someone makes a successful backorder call, backorderLevel is decreased. If someone makes a successful preorder call, preorderLevel is decreased.

Every SKU also has an availabilityStatus. In most cases, the SKU will have an availabilityStatus of AVAILABILITY_STATUS_DERIVED. In some cases, it is strictly defined as AVAILABILITY_STATUS_IN_STOCK, AVAILABILITY_STATUS_OUT_OF_STOCK, AVAILABILIITY_STATUS_BACKORDERABLE, AVAILABILITY_STATUS_PREORDERABLE, or AVAILABILITY_STATUS_DISCONTINUED.

If it is derived, queryAvailabilityStatus calculates the value based on the three levels: stocklevel, backorderLevel, and preorderLevel.

If a purchase call fails for a particular SKU and queryAvailabilityStatus says the item is backorderable, then backorder should be called. Calling backorder decreases the backorderLevel. To ensure the level remains consistent after the SKU is available again, purchaseOffBackorder should be called in place of purchase. This not only decreases stocklevel, but it also increases the backorderLevel.

If a purchase call fails for a particular SKU and queryAvailabilityStatus says the item is preorderable, then preorder should be called. Calling preorder decreases the preorderLevel. To ensure the level remains consistent after the SKU is available again, purchaseOffPreorder should be called in place of purchase. This not only decreases stocklevel, but it also increases the preorderLevel.

If your system does not need backorder levels and preorder levels, then you do not need to call backorder, preorder, purchaseOffBackorder, or purchaseOffPreorder. The purchase call is enough.

The default value for an item’s stockLevel is –1. This value indicates that there is an infinite amount of stock. The default value for all other levels. (backorderLevel, preorderLevel, stockThreshold, backorderThreshold, and preorderThreshold) is 0.

If the fulfillment system attempts to purchase an item for a customer and the item is out of stock but BACKORDERABLE, then the fulfillment system can backorder the item. If the fulfillment system attempts to purchase an item for a customer and item is out of stock but PREORDERABLE, then the fulfillment system can preorder the item. Both these statuses mean that the whole order could be waiting for the item to be in stock. Therefore, it is important that the fulfillment system is notified when an item is in stock after being backordered, preordered, or even out of stock.

The UpdateInventory message indicates that new inventory is available for previously unavailable items. When the fulfillment system receives an UpdateInventory message, the fulfillment system knows that the items included in the message can be successfully purchased now. It is the responsibility of InventoryManager to send this message. The RepositoryInventoryManager sends the message when the inventoryWasUpdated method is called.

If a call is made to inventoryWasUpdated then an UpdateInventory message is constructed and sent out over the port specified in the updateInventoryPort property.

The UpdateInventory message has one property:

Refer to the Inventory JMS Messages chapter for more information on the JMS Messages

 
loading table of contents...