Transcript Extending PHP beyond the Traditional Web Site

Extending PHP beyond the
Traditional Web Site
Chris Gruber
3.30.06
Sybase Confidential Propriety.
Agenda
“Extending” - Criteria and Meaning
The Distributed Architecture
CRM Application Study
General Observations
Next Steps
2
Traditional PHP Websites
Data is separate from other corporate sources
Lack of distributed architectures
 Lack of data driven desktop or remote Web sites
By “Extending” I am referring to broadening your
PHP application to include the above
3
Terminology
Consolidated Server
Traditional PHP Clients
Master – to – Master/ Update Anywhere
Information Flow
Occasionally Connected
Mobile Servers (Personal)
4
Remote Server (Workgroup)
Deployment Scenarios
Solutions Packages
Workgroup/Server
Workgroup/Server
 Global/Remote Operations
 Branch Offices
 Franchises
Solution packages
…
 Point of sale
 Linux Appliances

Kiosks
Remote office
 Store management
 Inventory control
 Backoffice systems
Mobile
 Traveling sales
 Field service worker
 Inspector
Remote office
Mobile
5
Agenda
“Extending” - Criteria and Meaning
The Distributed Architecture
CRM Application Study
General Observations
Next Steps
6
Distributed Architecture: Advantages
Low bandwidth challenges removed from user
experience
 Application operates of the local CPU speed
Can accommodate advanced techniques like AJAX
as data/logic is local
Application/Solution is always available
7
Distributed Architecture: Advantages
Alleviate database locking and contention on
traditional system
Alleviate web server contention
Leverage client processing power
Lower connectivity costs
By having offline/remote support with PHP, you
introduce redundancy
8
Distributed Architecture Challenges
Secure transmission between remote location and
central location
Master to master / bi-birectional information flow
between remote server and traditional server
Is latency an issue for the application?
9
Distributed Architecture Challenges
Network connectivity to traditional systems may
vary
 DSL,T1, Wireless, Dial-up etc.
Local datastore sizes may range from 10MB to
100GB or beyond
Maintain application feature set in remote
environment
Application versioning
10
Potential Distributed Challenges
Remote platform may vary (Windows/Linux)
 Workgroup solution may require a Linux solution
 End-User may want Windows
Ability keep common code base between
traditional system and remote system
Integration with corporate systems required
11
Bottom Line
 This approach provides an additional means to improve
usability and performance to users
 Commercially Differentiating
 For both consultants and commercial product offerings
 Your application has new markets with this approach
 May be the only way to provide solution for these customers
 Examples:
 Mobile Offices (Sales Force/Logistics/Service)
 Home Offices where remote dial-up is painfully slow and unusable
12
Agenda
“Extending” - Criteria and Meaning
The Distributed Architecture
CRM Application Study
General Observations
Next Steps
13
Case Study porting SugarCRM
What is SugarCRM?
 Customer Relationship Management tool ranging in features
from customer service to marketing programs
What is CRM?
 Application manages customer relationship activities, tasks,
appointments, bug reports, marketing campaigns,
opportunities, forecasts, contact information etc.
 CRM applications are used by Sales team many of which are
customer facing
14
Why extend this application?
Field Sales rely on customer data to be successful
 Customer visits tend to exclude connectivity
 Capture of the data at customer site reduces data entry errors
 Sales team can schedule more calls in a day as the office is
on their laptop (application is always available)
Marketing representatives attending tradeshows,
seminars, etc
 Capture leads
 Not all events have internet
15
Introduction to Synchronization
CRM Requirements
Sub-setting data relevant to individual
 Ownership/Assignment of data
 Data partitioning
 What happens to data when no longer required or is re-assigned?
 Logical deletes
What happens when updates occur at different sites?
 Conflict detection and resolution
 Database key generation unique across all databases deployed
How does the system identify changes/deltas to send to other
sites?
16
Case Study
We will review application code, schema,
synchronization
Comments are based on SugarCRM, the open
source version
 SugarCRM Professional (or others) may not reflect what is
being discussed today.
17
Case Study: The Code
Application code great for
structuring logic into
classes
 Maintainable
 Classes can interfere with
dashboard
 Focus on class for each item of
data rather than whole page
which contained contacts,
activities, calendar, tasks …
many different object types
 Query intensive
18
Case Study: The Code
PHP applications are interpreted
 Human readable
 Configuration files may store interesting information
 Protect these configuration files
 Consolidated website may also be compromised by remote
exposure
19
Case Study: The Database Schema
General
 Create database on install
 No foreign keys
Schema conducive to distributed architecture
 Use of GUIDs (application generated)
 Application code portable amongst databases
 Alternatives: primary key pools, global autoincrement
 Use of date_modified column
 Concept of ownership of records: assigned_user_id
 Existence of “Deleted” column useful for logical deletes
20
Migrating SugarCRM
SQL: Data Manipulation Language
 Applications class which did data modification (UPDATE,
INSERT, DELETE) did not really have to be changed
 Keywords used once and easily worked (RELEASE used in
nested transactions)
 Ambiguous queries allowed by MySQL
 Functions such as CONCAT, DATE_FORMAT
 Created user defined functions in SQL Anywhere
mysql_function() to sqlanywhere_function()
 http://www.ianywhere.com/whitepapers/migrating_mysql_asa9.html
21
Case Study: The Synchronization
SugarCRM Professional has an offline client
 Synchronization is invoked via Link on the Dashboard
 Client sets one of two conflict rules with an option to prompt
user
User driving when synchronization occurs
 Beneficial when network connectivity is not always available
 Scheduling synchronization would be valuable
Seamless synchronization is highly desirable
22
Case Study: The Synchronization
Data Transmission between remote server and consolidated server
 SugarCRM PHP client call to another web server
 Ideally it should be a secure protocol (HTTPS)
 Implementation – protocol likely chatty if the code relies on the PHP object
classes
Alternative
 Implementing an optimized synchronization solution
 Get all changes, send these changes in one transmission, commit changes
Offline client is using PHP classes on the server, the client
application is very tightly coupled with server application for the
purposes of synchronization
 Loosening the relationship may be more supportable regarding application
updates
23
Agenda
“Extending” - Criteria and Meaning
The Distributed Architecture
CRM Application Study
General Observations
Next Steps
24
Additional Observations
Ease of Deployment
 File Copy of application and database
 Application Updates
 Support for multiple versioning is advantageous
 Pilot roll-out versus full roll-out
Support
 Accessing the data remotely
 SugarCRM and (most PHP applications) are websites which
alleviates this particular issue
25
Observations on Synchronization
Data Partitioning
 Consolidated data may not fit on laptop
 Increase performance as there is less data on client to process
Conflict Resolution
 Should be seamless to user and controlled via business rules
 Contacting administrator to resolve conflicts is often not an option
PHP Synchronizing Data
 Wireless synchronization issues (pay per byte)
 The more chatty the transmission, the more expensive
 Data Compression requires additional effort
 Encryption additionally needs to be setup between servers
26
Observations on Flexibility
Flexibility of integration
 Heterogeneous databases between remote and consolidated server
Flexibility to describe synchronization types
 Download-only, upload-only, snapshot vs deltas, priority
synchronization, different schemas
Consolidated Table1
Consolidated Table2
Merging
Less Data in Remote Table
27
Observations on Security
Security features
 Database file encryption support
 Client/Server encryption if web server is not the same machine
as database server for workgroup environments
 Auditing
 Encryption/Decryption functions (passwords)
28
Observations on Ease-of-Use
Technology conducive to ease-of-use requires the
following
 Self-tuning, self-managing
 Auto-recovery
 Can automate basic administration efforts like simple backup
Reactive to your users’ environment
 Memory, data on the machine will change
Quick and seamless install for the end user
29
Nice to Have when Deploying PHP
Personal servers will likely be deployed on
Windows PHP
 Pre-Built Binaries for both Windows and Linux
Installation that does not require administrative
rights
Deployment tools
 Documentation, InstallShield templates/modules, silent install
30
Agenda
“Extending” - Criteria and Meaning
The Distributed Architecture
CRM Application Study
General Observations
Next Steps
31
Next Steps
Review options for Mobile/Remote databases
 SQL Anywhere Studio Developer Edition is free
 http://www.ianywhere.com/downloads/
On Demand Getting Started with SQL Anywhere webcasts
 http://www.ianywhere.com/products/presentations.html#sql_anywhere
PHP source, documentation and the latest PHP binaries
 http://www.ianywhere.com/php
 New PHP 5.1.2 binaries
32
Summary
Distributed Architecture has challenges but has
upside
 Application availability
 Performance/Responsiveness
 Reduce costs (connectivity, hardware)
 Potentially New Markets
 Competitively Differentiating
33
Questions?
Chris Gruber
iAnywhere Solutions
[email protected]
34