Extending PHP beyond the Traditional Web Site Chris Gruber Sybase Confidential Propriety. 2 Agenda Extending - Criteria and Meaning The Distributed Architecture CRM Application Study General Observations Next Steps 3 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 4 Terminology Traditional PHP Clients Consolidated Server Remote Server (Workgroup) Mobile Servers (Personal) Master to Master/ Update Anywhere Information Flow Occasionally Connected 5 Deployment Scenarios 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 officeMobile Workgroup/Server Solutions Packages 6 Agenda Extending - Criteria and Meaning The Distributed Architecture CRM Application Study General Observations Next Steps 7 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 8 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 9 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? 10 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 11 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 12 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 13 Agenda Extending - Criteria and Meaning The Distributed Architecture CRM Application Study General Observations Next Steps 14 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 15 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 16 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? 17 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. 18 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 19 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 20 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 21 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() 22 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 23 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 24 Agenda Extending - Criteria and Meaning The Distributed Architecture CRM Application Study General Observations Next Steps 25 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 26 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 27 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 Merging Less Data in Remote Table Consolidated Table1Consolidated Table2 28 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) 29 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 30 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 31 Agenda Extending - Criteria and Meaning The Distributed Architecture CRM Application Study General Observations Next Steps 32 Next Steps Review options for Mobile/Remote databases SQL Anywhere Studio Developer Edition is free On Demand Getting Started with SQL Anywhere webcasts PHP source, documentation and the latest PHP binaries New PHP binaries 33 Summary Distributed Architecture has challenges but has upside Application availability Performance/Responsiveness Reduce costs (connectivity, hardware) Potentially New Markets Competitively Differentiating 34 Questions? Chris Gruber iAnywhere Solutions