VIEW
The Warehouse Shipments Framework (dbiWSF) is an encompassing product from DBI. The origins of this framework product evolved from a databinding exercise in relation to Solutions Schedule for .NET and Studio Controls for .NET. One of the most frequent questions we receive is "which is the best method to bind the dbiSchedule control and the dbiDayView control to a database and what is the best structure for doing so?" Our initial response is typically focused on how one needs to use the controls. When using the scheduling controls there are three primary structures to envision - locations, contacts and tasks. Once a structure is in place, then the next task becomes how to attach appointments to those items.
When discussing the component use and databinding processes with our developer communities, it became clear that a 'one size fits all' type of approach wasn't going to provide the detail needed to answer the question, the concepts that would have been used in a one size fits all approach would have been just too generic.
Tapping into our own in-house expertise - our lead developer, on what became a new project team, had several years experience as a system administrator for a lumber yard and consequently several more years under his belt working for a software development team that had created a very intricate shipping and receiving application. Another one of our key staff members had previous experience as an analyst/lead developer on a fully integrated warehouse shipment and receiving system. Using this collection of in-house expertise we began crafting a unique solution, for the databinding and use question, based the concepts of Shipment Management. Our goal evolved into providing a framework based on the shipping and receiving concepts, that would ultimately speak to developers various coding and data management needs, all in context of Solutions Schedule for .NET and Studio Controls for .NET (dbiDayView).
As development of the framework advanced it became apparent that a developer would be able to quickly craft an Enterprise quality solution without having to go through a full application scope and definition process. We had to work through these detailed processes ourselves to certify the commercial product, so why not include it. No reason to make others re-invent the same wheel. Those processes are now packaged as part of the Framework.
We started out focusing on the databinding layer, after all it was the impetus for the project, and as we moved along it became really only one part of the whole Framework solution. A User Interface layer was also becoming a very important element. With DBI's industry proven UI design controls it was a natural fit to incorporate many of the components found in Studio Controls for .NET to make a complete User Interface Layer. Now, the answers to our opening question were coming together quite well; how to best databind two different scheduling controls. The Framework concept was working really well as a medium for delivering the solution.
Of course there were stumbling blocks along the way. From the beginning of the project the development team had a major pet peeve and that was being able to objectify the business rules that would give the Framework its real life application. The pet peeve turned into a diligent process of carefully scoping the methods that would generically apply the shipping and receiving business rules to the Frameworks' Warehouse Shipment objects. This careful deliberation now made it possible to call those rules from any UI or external application. The results were surprisingly simple, yet extremely powerful, flexible and reusable.
TERMINOLOGY
The dbi Warehouse Shipments Scheduling Framework (dbiWSF) is a source code product that ships with three separate .dll's affectionately referred to as layers. The core dbiWSF .dll contains the Databinding Layer and the actual dbiWSF Object Layer. The second tier is the Business Rules Layer. This layer encapsulates a collection of business rules that can be applied to any of the dbiWSF objects for any create/update/remove method called upon those objects. Finally the UI Layer which contains custom controls based on the Solutions Schedule for .NET and Studio Controls for .NET components; we've wrapped and surfaced generic events and methods against the custom controls. For those familiar with DBI component software products, an example of this wrapping is to take our specific events and apply them to the dbiWSF objects. So instead of a before timebar drop event for instance, we now surface a before shipment drop event. This way the same code blocks can be used regardless of the UI control being used. The before shipment move event is the same for a dbiScheduleTimeBar and a dbi appointment from the dbiDayView control. This concept can be further modeled to other controls including Silverlight List controls or ASP.Net controls.
The Warehouse Scheduling Framework utilizes several DBI components found in the Solutions Schedule for .NET Enterprise Edition and Studio Controls for .NET products.
APPLICATION DESIGN
A) The dbiWSF Object Layer and Databinding Layer
At the core of dbiWSF is the dbiWSFObject Layer. This layer is combined with the Databinding Layer to handle the loading and display of data. At it's core the dbiWSFObjects on change will automatically fire a corresponding database update (this can be disabled and processed as a batch for those who prefer that methodology). The layout of the objects can be encapsulated in the dbiWSFSchedule control.
The hierarchy follows as such:
dbiWSFMainObjects - a parent container object usually defined in a module or global variable
WarehouseObjects collection (1 to many)
LoadingDocks collection (1 to many) -> also a collection of accepted CargoTypes)
Shipments collection (0 to many)
OrderHeaders collection (0 to many) -> Point of Integration for POS/Shipping system
OrderDetails collection (0 to many) -> Point of Integration for POS/Shipping system
dbiWSFExceptions - a collection of exception objects which indicate when 1 to many LoadingDocks are unavailable (these show up as custom areas in dbiWSFSchedule (the beige area) and dbiWSFDayView) dbiWSFCargoTypes - a collection of different CargoTypes, these can be applied to LoadingDocks and OrderDetails
The objects as mentioned connect to the databinding layer. This code integrates the ADO.NET database calls to the objects themselves. The methods used to bind the data as well as examples in the UI layer detail how the database layer can be mapped to the objects thus allowing for two part database coding. Simply add a column to the table and a corresponding property to the dbiWSFObject and the two are synced. Using reflection, the default maintenance forms will automatically pick up the changes without the need to code specific UI controls to said property. In the simplest of terms, if I want to add an Address column to the database I add the column to the table and then I add the property to my LoadingDock object. The rest is handled by the controls. Here is a movie highlighting the concept.
The dbiWSF Product ships with both clean and demo versions of the databases. We include disconnected MSSQL database tables, Access databases and a .pdf with the database layouts for those using other database types. The source code has three levels of database design. The Standard database method basically loads the data as it is used in the object structure, this is easy to read but slow. The second method InMemory uses LINQ to Objects and For..Each loops to load the data first then map it to the objects. This is a very fast method but a bit more complex in the coding. Finally we provide a third method Custom which is empty template code for those using stored procedures, complex queries or non-ADO.NET data access (XML, ODBC). This gives developers the most flexible choice when working with other aspects of the dbiWSF product. For example, you can map your XML documents to the WSF objects, then rely on the reporting, business rules and UI layers as coded, but the developer will handle the file updates and CRUD operations.
Code to attach the dbiWSF objects to the AccessDatabase, create a business rules object and a context menu object.
Module modMain
Public myWSFObjects As New dbiWSF.FrameworkObjects.objWSFObjects(
dbiWSF.Databinding.ConnectionTypes.OLEDatabase, _
dbiWSF.Databinding.DataBindingMethods.InMemory, _
"Provider=Microsoft.ACE.OLEDB.12.0;Data Source = WSFOleDB.accdb")
Public myBusinessRules As New dbiWSF.BusinessRulesAndSupport.BusinessRuleObjects(
myWSFObjects)
Public WithEvents myWSFContextMenu As New dbiWSF.ControlLibrary.dbiWSFObjectMenu(
myWSFObjects)
End Module
Code to load the dbiWSF data and attach it to a dbiWSF Schedule
Try
'Code to load the data for the dbiWSF objects.
myWSFObjects.LoadAllData()
'Code to display the dbiWSFSchedule with dbiWSF objects in the date range provided.
Me.DbiWSFSchedule1.SetMainObjects(myWSFObjects, myBusinessRules, #1/2/2012#,
#1/7/2012#)
Catch ex As Exception
Those few lines of code above will load the data into the dbiWSF Objects and attach those objects to the dbiWSFSchedule control. That is all it takes to have a working warehouse application right out of the box. The databinding is taken care of, the context menu allows for the setting of properties, and the schedule control handles the moving and creation of new shipments, all the while running against the business rules and databinding.
B) The Business Rules Layer
One of the key goals for the dbiWSF was integrating a robust yet generic business rules model. As rapid application developers, the core of our programming is focused on the business rules imposed by an organization. These often end up coded in functions that are then called from multiple events, however as the events themselves often speak to unique return objects and e.arguments, the generic part often gets left by the wayside for getting the project out the door. We wanted to mitigate this effect and the effects of object definition changes. As such we came up with a library of functions and objects that can respond to the CRUD operations on our objects instead of specific event args (for example, we trigger a business rule for Shipment Changes whenever an existing shipment is modified). This approach allows us to code a business rule regardless of how that shipment detail changes, be it in dbiWSFSchedule, dbiWSFDayView, ListView, ComboBox or custom dialog. The same rule or rules apply regardless of what triggered the change. The creation and modification of the business rules are documented and templated in the source code as well as the help file that ships with the product. There is even a UI dialog that can be used out of the box or modified for different "levels" of control (ie: a manager can override a shipment being added to an exception area). Once again, we have a movie for that...
C) The User Interface Layer and Reporting
DBI has been a component vendor for quite a while now so we are intimately familiar with controls and working with those controls. While we spend an insane amount of time working on demos and documentation for the controls, sometimes the best ideas come from actually using our controls. We had that opportunity with the dbiWSF and some of the ideas for the latest revisions of Solutions Schedule for .NET Enterprise and Studio Controls for .NET (dbiDayView - a multicolumn appointment control and dbiList - a node based tree/list control) came from our in depth use of the controls in the dbiWSF. We went on to extend our controls to provide a generic UI implementation with the dbiWSF objects. There is minimal code involved in attaching the objects to the UI Layer, simply invoke a LoadData method passing the dbiWSFMainObject object (redundant I know, but naming conventions can lead to strange bedfellows) and the dbiWSF controls will apply the objects to the controls. We include a dbiWSFSchedule, dbiWSFDayView and a dbiWSFObjectMenu (custom context menu) along with a host of dialogs and supporting controls.
Also included in the UI layer is a heavily customized version of our dbiList control which has the ability to accept a custom Report object. This control wraps a very flexible report template which handles the "layout" duties while allowing the developer to add nodes to the report programmatically. This is essential a hybrid between banded report writers while allowing the developer to generate the report nodes in .NET code. Using LINQ against the pre-existing dbiWSF objects and reporting is a whole lot easier. Included in the source code are the templates and three pre-defined reports. As always there is a movie...
D) Warehouse Concepts and Integration
As mentioned previously, this isn't a trivial framework, we did our homework. One of the key concepts in the Shipments Scheduling world was the need for Loading Dock exceptions. These can be applied for a myriad of reasons (dock maintenance, lunch hours, staff issues, equipment breakdowns and cross docking). We actually scoped two separate needs here, one for one off issues (Jimmy drove his rig right through the bumpers) and one for recurring exceptions (there are no deliveries allowed between 12:00 noon and 1:00 pm every day). So we created objects for both. The exception class allows for a start/end time of the exception as well as a collection of loading docks to which this exception applies. If scheduling a power wash of docks 1 to 3 for 8:00am to 10:00 am, this is ideal. A recurring exception has a start and end time as well as a start and end date along with a frequency. This can allow a set of docks to be closed every day from 10:00 am to 11:00 am or every Tuesday and Thursday from June 1 to October 1 for company bbq's (mmmm BBQ). These objects appear on both the dbiWSFSchedule and dbiWSFDayView as CustomAreas, but are also embedded in the business rules layer so if the developer is using a straight dialog or other interface they will still be notified via the business rules class.
Another area of special note was breakout docks. This is where a shipment may need two dock locations to unload or to stage a shipment. We allow for up to two breakout docks per shipment, which means that said shipment will need two docks either to the left, the right, or split between the main dock. This is a property on the shipment and is also processed through the business rules layer.
We also invested in investigating the Cargo Types available and the layout of the docks in relation to those. For example certain docks are located in a freezer area, and some in the dry goods area. Each loading dock in the dbiWSF can be setup with a collection to allow certain cargo types. Each OrderDetail attached to an OrderHeader which is in turn attached to the Shipment, can have a specific cargo type. This means mixed loads will show up with the proper cargo types. As with most objects, there is a business rule applied to the creation and movement of the shipments which determines if the cargo types on a shipment match the cargo types accepted at the loading dock. As with all business rules these can be adjusted by level (if the boss wants to unload the beer in the main warehouse and dolly it into the cooler, who are we to say no). In the dbiWSF controls these are indicated by 16x16 icons. The ones that ship are default, we expect the developer to use their own depending on the Cargo Types defined by their customers.
Finally, we've surfaced a ton of events to allow for the integration of existing systems. We understand that developers will not want to recreate the wheel for CRM, POS and ERP systems, so we indicate where in the code those connections can be made. Each object has a GUID based key and has several key indicator fields used for tying in other systems. For example, each OrderHeader object has an external key that can be used to tie into a POS system for the order id or purchase order (this allows for inbound / outbound shipment control). The shipment itself has fields for shipping company ID and container ID (the system was primarily designed for trucking but can be used for container ships, trains and even has the ability to "move" loading docks for use in large scale shipping yards where a crane is the loading dock).
CONCLUSION
The dbiWSF is a sum of many hours of scope, design, implementation, testing and documentation. This is a brief synopsis of what is available in the package. For more information please visit our website and make sure to review the demonstration movies, design concepts and even a fully functional SmartClient Demo. If you have any questions at all or comments, please don't hesitate to contact info AT dbi-tech.com
As always take care and have a great day!
