Custom Reporting, Customer Management and Content Management System Software (CMS)
Development for a Bluetooth Marketing and Advertising company
Software Development for a Bluetooth Marketing and Advertising Company - Technical
Case Study
A high profile Bluetooth marketing and advertising company, which for confidential
reasons must remain anonymous, offers a specialised advertising solution for large
to medium high street corporate companies including banks. Via a dedicated Bluetooth
server, messages and images are transmitted from the store (e.g. Sony Centre) to
people's Bluetooth enabled mobile devices as they travel past the participating
store.
The dedicated Bluetooth servers are specifically manufactured for the company concerned
and operate with a "cut-down" version of the Linux operating system. The server
is then located within the store so as to be able to transmit the Bluetooth signal
to mobile devices.
The Requirement / CMS (Content Management System) / CRMS (Customer Relationship
Management System)
Our client, a Bluetooth marketing and advertising company, required a solution that
would enable the log files that are generated by the Bluetooth servers to be transferred
from the Bluetooth servers to their centrally located server, and then for the information
contained within the log files to be transferred to a web server where clients could
log into and view the results of their marketing campaign generated by their Bluetooth
server. A CMS (Content Management System) / CRMS (Customer Relationship Management
System) hybrid was also required that would enable our client to set-up their clients,
manage the stores / sites that have Bluetooth servers and manage users and their
access to the information generated from the Bluetooth servers.
The Approach / Project Specification Development
Analysis was conducted and a specification produced detailing exactly what would
be delivered and the technologies involved in delivering the system.
Three distinct development areas were identified:
- Transferring the logs files from the Linux Bluetooth Server on the central server
- Transfer the log files from the Central Server to the Database Server
- Web Site which was broken down into two area's
-
- The Client Front end
- The CMS/CRMS hybrid software system to allow our client to control the website and
Users.
I. The Linux Bluetooth Server
Due to the nature of the connectivity at certain locations of the servers, it was
necessary for the Bluetooth server to initiate and open a connection and upload
the log files to the Central server. Each log file was compressed and the name of
the file was actually the MD5 checksum of the uncompressed file.
In order to complete the task a BASH script was written that would transfer the
log file via ftp to a specific location on the Central Server.
II. Central Server / Database server
An application was developed using
.Net Visual Basic, that queried the database
server and returned a list of the Serial numbers that uniquely identified each Bluetooth
Server.
The application then checked to ensure that each Bluetooth server had a folder on
the central server where the log files are to be placed. If the folder did not exist
it was created ready to accept log files.
Once the check had been made and all the folders that will receive the log files
are created, the application then searches through each folder and checks its contents.
If a file is found, the file name was then stored by the program as the file name
contained the MD5 sum check value. The application then uncompressed the log file,
which was tared and zipped. An MD5 check sum was performed on the uncompressed log
file to ensure the integrity of the file transfer. The resulting MD5 sum check was
then stored in the MD5 folder.
If the calculated MD5 sum check matches that of the filename, the files are then
parsed into the database server. If the check sum does not match the log files are
deleted, and await retransmitting of the log file.
III. Web Server / Database Server
There are two sections to the Website; the client side where clients can log in
and view the results of their bluetooth marketing campaign.
The Second side is the Hybrid Content Management System Software (CMS) / Customer
Relationship Management System (CRMS), this enables our client to set up their client
base, set the locations of the server, enter the server serial numbers, login details
etc.
Client Side Reporting
The client side of the web site is the software system developed to allow clients
to analyse the data (log files) in a concise and visually friendly manner.
Summary Report; When a user logs into the client side of the site a list of Bluetooth
sites the user has access to is made available, and the past 7 days results shown.
The user then has the ability to choose which sites they wish to analyse data for.
There are two distinct ways in which the data is displayed.
The first is a line chart, which shows varying information such as the number of
successful messages received by mobile devices, the number of unsuccessful messages
(messages that were transmitted but the Bluetooth mobile device refused to accept).
The report can be run to display any 24 hour period. The graph's X axis is displayed
in hourly increments from midnight to midnight. This enables the user to view an
hour by hour account of the data.
Alternatively the report can be run for a period larger that 24 hrs, in this instance
the graphs X axis is then incremented by days. This enables the user to view a day
by day account of the data for any given period.
Also provided is a more conventional matrix view of the data also on a 24 hour or
day by day analysis. The matrix shows exact figures and helps support the graph
information.
Database design and database implementation: By designing the correct database structure it would ensure that data was not only
accessed and stored efficiently, but also that it was scalable.
The SQL Server database was designed to conform to good Relational Database Management
Techniques. Data stored within the database was normalised to the 3rd form.
Scalable Database design: In using the relationship techniques enabled the database to be designed in such
a manner that at a later date the database could be extended without having to change
the existing database structure (scalable).
Database Performance: Normalising the data held within the database would ensure that duplicate information
was not stored within the database thus ensuring the database performance will be
enhanced.
Hybrid CMS/CRMS
Due to the nature of the company's client base, a user and Bluetooth site hierarchy
was required. Analysis of the user base and physical locations of the servers were
undertaken and the following was implemented.
Three different types of user were required:
Head office User: The Head office user logs into client side of the website to enable the user to
view the results from the advertising Bluetooth campaign log files. The head office
user, can view any of the sites that belong to their organisation, enabling for
Total, Regional, and individual site reporting. The user is able to check on any
of the site locations for each of the Bluetooth servers, enabling the Head office
User to get an overall picture of how the Bluetooth servers are performing with
regard to sending out advertising messages.
Regional User: When a user is set up all of the regions that have been set for that client are
available to choose from. One or more regions can be selected to assign to the user.
When the region(s) have been selected, the User will then have access to all of
the sites that are within the regions selected. This model enables Regional Managers
etc, to have access to all of the sites information.
Site User: A Site user has access only to the site(s) that user has been assigned to. A site
user can be assigned to one or more site, however, this type of user can only view
the sites that have been allocated to them.
Regions were identified as being very important within the context of this project,
and so the following approach was taken.
An area of the CMS software system was dedicated to entering towns and cities. This
enabled the system to use a standard set of cities throughout the whole of the system,
ensuring integrity of the system and data was maintained (normalised form).
Once all of the necessary towns and cities were entered, it is then possible to
set up regions. At any point new towns or cities can be added into the system, which
then enables them to be used within the region section of the CMS software system.
Each region is set up on a client by client basis, although each client could have
multiple regions if so desired.
The purpose of setting up each region on a client by client basis is due to the
nature of Companies. Every company general defines regions that are important to
their organisation. However, the way in which regions are described can vary greatly
from organisation to organisation. Therefore company regions are defined. Different
companies will often have the same naming structure for the regions, however each
company may include different towns and cities within that region. An example is
shown below.
An example of two Clients, Client A and Client B
Client A Scenario
|
Region to be created:
|
Midlands
|
|
Towns/Cities to include:
|
Birmingham
|
|
|
Wolverhampton
|
|
|
Solihull
|
|
|
Shrewsbury
|
Client B Scenario
|
Region to be created:
|
Midlands
|
|
Towns/Cities to include:
|
Birmingham
|
|
|
Solihull
|
|
|
Oxford
|
As can be seen from the two scenario's both client A and B have created a region
Midlands, however how they describe (included cities) the regions are very different.
Client A excludes Oxford, this may because the have no retail unit within Oxford,
whereas client B has retail units operating in Oxford, but not Wolverhampton and
Shrewsbury.
With this level of control, each Client can maintain their regions without having
to fit a predefined model. This is very important when reporting, and setting up
Bluetooth sites.
Setting Up Bluetooth Sites
Each Bluetooth site needs to be set up within the software system to enable the
log file information to be stored correctly within the SQL Server database. A Bluetooth
site is the physical location of where the server is actual operating from.
Each Bluetooth server is uniquely identified by a serial number (see the above diagram).
The serial number for each site must be entered into the system, along with a location
(town/city).
Once the serial number has been entered the application as described above will
then generate the folder structure on our client's central server, the location
of where the log files are transferred too.
On selecting the location for the server, the system then checks to see if the city
belongs to a region, if this is the case the Region is then displayed for this server.
The user entering the server details can then see which Regional users will have
access to the log file data.
Technologies Involved in the Project
IIS 7 running .NET Framework version 2.0
- SQL Server 2005
- Database Design
- Standard Relational Database techniques were used, to aid in the design of the database.
The relationships of the database were all normalised to the 3rd form, as this is
sufficient for a web based database. First normal form was not used on the web based
project as this can often lead to issues accessing the data through the relationships.
However, as internet connect speeds increase this will cease to be the case.
ASP.NET using:
Visual Basic .NET: Was the primary programming language used to develop the bespoke software system.
Code Behind: The code behind methodology was used extensively throughout the project. Using this
methodology helped separate the functionality of the site from the design. This
enhanced the project as it enabled both web designers and web developers to work
on the same parts of the system without causing change conflicts.
Classes: Where appropriate classes were developed to keep the bespoke software system more
manageable, and hide functionality that web developers do not need to be concerned
with. Each class was designed to contain the "business logic" of the system. Once
again this aided in keeping the project manageable and less cluttered, but it also
had the added advantage of being able to make modifications within the class and
the changes would immediately filter through the system.
Event Driven: Unlike past Web technologies ASP.NET
is completely event driven; full advantage was taken of this fact, and many procedures
and functions were created within the system and reused throughout.
Once again this made the project more manageable, but also helped to keep the development
of the project structured.
Master Pages: Master Pages were used within the CMS to enable a consistent interface for the user.
The advantage to this is that with regard to the framework of the system if a change
is required, it is more manageable as the modification only need to take place in
once and the change then filters through the rest of the software system.
JavaScript: User validation and the HTML editor was developed extensively using JavaScript. This approach had two advantages:
- Server load The load on the server was reduced,
due to the fact validation was done client side, and the web server, would only
be contacted to serve pages.
- Enabled the validation throughout the system to be consistent.
GDI+ (Graphic Device Interface Plus)
As part of the .NET framework all
of windows native graphics system is exposed via API's (Application Programming
Interface) to allow access to graphical functions.
All graph data is produced using the GDI+ graphics API. Each graph produced is displayed
as a gif image to enable users to save the image locally and use it for reporting
back to other members of the organisation.