Software Development for a Bluetooth Marketing and Advertising Company - Technical
Case Study
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.
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.
User Hierachy
Three different types of user were required:
i. 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.ii. 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.iii. 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.
IV. 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.
V. 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:
1. 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.
- 2. 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.
Find out more about our Web Application Bespoke Software Development
- Custom website application development; complex database design,
web application examples
- Web 2.0 application development for london based INMYVAULT™ with diary, photo and document upload and storage, online journal developed in .Net and SQL server 2005
- Application Development in
Birmingham, London and UK, specialising in .Net, ASP.Net, Database
SQL 2000, ASP, Linux, Microsoft
Access
- SO LONDON Publishing CMS and Website Design case study
- Bespoke Web
Development Software Programming - So London Publishing -
complex interactive SQL Server database driven website and bespoke
CMS in .Net
- Custom Reporting, Customer Management and Content Management
System Software (CMS) Development in .Net Framework for a Bluetooth Marketing and Advertising Company
|
