Possible ways to use the automation API
Table of contents
Vertical storage lift
A vertical storage lift is a machine consisting of several internal locations, and some mechanism which can automatically transfer goods between these internal locations and some designated input/output areas. To model this in Ongoing WMS, you have three locations:
- Lift_In: represents the input area of the lift.
- Lift: represents all the internal locations inside the lift.
- Lift_Out: represents the output area of the lift.
Here is a possible workflow for placing goods in the lift:
- Operator physically places goods in the lift's input area.
- In Ongoing WMS, the operator moves the goods to the Lift_In location.
- In the background, the lift continuously polls GetArticleItemsByQuery with the filter OnlyGetArticleItemsInLocationsToBeHandled = true, looking for article items in the Lift_In location which have not yet been handled by the lift.
- When the lift realizes that there are article items in Lift_In, it immediately calls ArticleItemInLocationHandled to mark them as having been handled.
- The lift can now physically move them to its internal locations.
- After the physical move is done, the lift calls MoveArticleItem on all affected article items to move them to the Lift location in Ongoing WMS.
Retrieving goods from the lift works in a similar manner:
- When the operator prepares orders for picking, Ongoing WMS will allocate goods from the Lift location and automatically generate movement orders from Lift to Lift_Out.
- In the background, the lift continuously polls GetMovementArticleItemsByQuery with the filter OnlyGetMovementArticleItemsToBeHandled = true, looking for movement orders between these two locations which have not yet been handled.
- When it encounters such movement orders, the lift immediately calls MovementArticleItemHandled on the movement article item ids, to mark them as having been handled.
- The lift can now begin to move them physically to the output area.
- When the lift is done, it uses MoveArticleItem on all affected article items to move them to Lift_Out in Ongoing WMS. (Note that this call will also finish the movement orders at the same time. Thus there is no need for a separate call to finish to the movement article items.)
- The operator can then phyiscally pick the items and also mark them as picked in Ongoing WMS.
A conveyor belt is used to transport objects from one place to another. The conveyor belt may have the ability to move objects to different places depending on the object itself. For instance, in a warehouse you may wish to have the conveyor belt move all packages going to Sweden to one location, which all packages going to Norway should be moved to another location altogether.
One possible way of integrating a conveyor belt with Ongoing WMS, is the following:
- An operator picks an order in the warehouse and places the goods in a package.
- A label with the order number (or some other identifier) is affixed to the package.
- The operator places the package on a conveyor belt.
- The conveyor belt scans the package and makes a call to GetOrderArticleItemsByQuery.
- Using the information which Ongoing WMS returned to the conveyor belt, it can make an intelligent decision on where the package should be routed to (for instance based on country or post code).
Integrating with a transport system
Ongoing WMS provides integrations with many transport systems, but some customers choose to write their own integration. You can use the automation API to create an integration between Ongoing WMS and a transport system like this:
- Create an automation webhook which triggers every time an order reaches the status Sent.
- When the webhook is triggered, your webhook receiver will receive an OrderId.
- Your webhook process can use the API call GetOrdersByQuery to retrieve the order from Ongoing WMS.
- Since the webhook will be triggered for all orders, it may be necessary for your webhook process to decide whether to proceed with the order. As an example, your webhook process can use the Transporter field to determine if the order has the correct transporter.
- If your webhook process should not proceed, then you can simply stop processing.
- Otherwise, your webhook process makes the necessary transport bookings, by making API calls to some other system.
- Once the transport booking has been made, your webhook process can use the following API calls to send back information to Ongoing WMS:
- UploadOrderFile - can be used to attach one or more PDFs to an order.
- UpdateOrder - can be used to add a tracking link to an order.
- CreatePrintJob - can be used to print the above-mentioned PDFs.
- ReportOrderTransportStatusEvent - can be used to inform the warehouse of various events (such as "the order has been delivered to the end customer").