|
|
|
|
|
SHOWCASE |
|
|
|
|
|
|
|
|
Databinding .NET
Scheduling Controls
in context of
DBi's Warehouse Shipments
Scheduling Framework |
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
<VB.NET CODE>
'Module code to attach to the database and create the business rules and context
menu.
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")
'Business Rules
Public myBusinessRules As New dbiWSF.BusinessRulesAndSupport.BusinessRuleObjects(myWSFObjects)
'Create a context menu.
Public WithEvents myWSFContextMenu As New dbiWSF.ControlLibrary.dbiWSFObjectMenu(myWSFObjects)
End Module
<END VB.NET CODE>
Code to load the dbiWSF data and attach it to a dbiWSF Schedule
<VB.NET CODE>
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
<END VB.NET CODE>
|
|
|
|
|
|
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 sales AT dbi-tech.com
As always take care and have a great day!
|
|
|
|
|
|
|
|
|
|
|
|
all rights reserved | copyright ©
1996 - 2015 |
Terms of Use |
|
|
|
|
|
https://www.dbi-tech.com |
|
|
|
|