Case Study: OfficeMedium - Web-based Business Intranet Software (Drupal SaaS)

What is OfficeMedium?

A web-based collaborative suite and office intranet providing you and your team with a centralized solution for most of your daily business and communication needs. OfficeMedium is also the first-ever, Drupal-based SaaS offering.

Built with efficiency and convenience in mind, OfficeMedium offers a secured, hosted platform for:

• Contact Information Management
• Task and Event Coordination
• Personal and Group Calendars
• File Sharing, Storage, and Organization
• Resource Repository
• Secured Client and Outsider Integration
• Automated Organization and Archiving
• A Suite of Social and Communication Functions

OfficeMedium aims to offer businesses all of these critical functions, in a single, secured, web-accessible, easy-to-use, inexpensive software package that removes the reliance of email, individual desktop computers, and expensive servers and networked software.

Challenges

As long time Drupal developers and innovators, the decision to build on Drupal was an easy one. By utilizing the incredible contributed modules, Views, CCK, and Panels, and some of your own magic, just about anything can be accomplished. Initially we were faced with three main challenges:

1. Developing the core software and features needed
2. Handling a multi-company / multi-user / multi-role environment
3. Charging and invoicing each company

Confident in our abilities, challenge #1 didn't seem like a matter of ability, but rather time. So we began with #2...

The Subinstance Module Package

By design, each company has their own intranet, each with a number of user accounts, each user account holding up to three roles: Client, Employee, Superuser. Our first plan was to somehow utilize Organic Groups or something similar to be able to achieve this architecture while using a single database and single codebase. But that quickly became too confusing and too insecure. Also, we wanted each company to be accessible via companyname.officemedium.com. Our next focus was on the incredible AEgir hosting system. We thought we could create installation profiles that could be spawned for each company. But the hosting system was too complexed and not nearly as automated as we needed it to be. The next idea was to simply start from scratch. And that's how Subinstance.module was born.

Essentially, the Subinstance module allows for the completely automated spawning of subdomain sites, otherwise known as instances. The module can be given a custom SQL dump of an existing Drupal installation. This SQL template is our Intranet software, completely ready to go. From the admin's side, after actually configuring the module with all the needed server information, you can enter the subaddress and title of the site, press a button, and you now have a completely new, independant subsite - different database, shared codebase. The spawning is possible by passing some information to a few custom shell scripts, creating and filling the new database, entering the subsite into the sites directory, and creating a custom settings.php file.

Still, some issues existed, such as how to communicate with these instances, how to determine how many users existed on them, how to block access, delete them, invoke cron, detect problems, charge money based on their usage, etc. So the Subinstance package was created:

• Subinstance: Automatically spawn subinstance Drupal installations
  • Replicates SQL dump of Drupal installation
  • Extensive configuration settings to work with most servers
  • Determine percentages of instances to invoke cron and fetch data from on each cron run
  • Admin panel to view all available instances. Each instance lists the current users, data usage, user account owner, and links to check the instance, fetch data, block/restore access, invoke cron, or delete the instance.
  • Optional email alert to notify on non-responsive instances
  • Block access to instances by directly altering the maintenance variable in their database
  • Hooks:
    • hook_subinstance_launch()
    • hook_subinstance_fetch()
    • hook_subinstance_lock()
    • hook_subinstance_delete()
• Subclient: Active on each instance. Communicates with instance host
  • Required to be active on each instance
  • Receives initialization call from instance host to allow other modules to perform actions upon instance creation
  • Gathers user account and memory consumption data and passes it to instance host upon request
  • Receives request to invoke cron.
  • Hooks:
    • hook_subclient_initialize()
    • hook_subclient_fetch()
• Subfinancial: Plugs into Subscribe.module (see below). Handles pricing of instance
  • Utilizes Subscribe.module's API (see below)
  • Set amount to charge per user account and gigabyte used
  • Set free amount of users and gigabytes used
  • Provide Subinstance form on Sign Up page
  • Block instance on failed payments
  • Optional 'Instance Trash' on cancelled subscriptions. If user cancels subscription, instance can be blocked but stored for X amount of days.
  • If trash is enabled, users have the option to restore their instance upon signing up again, if it's still available.

The Subscribe Module Package

Now that we've handled everything else, we need a proper way to charge users for their instances, invoice them, keep track of payments, securely handle credit card information, and issue recurring payments. After spending over a week searching for a simple Drupal subscription payment handler, and trying to reverse-engineer Ubercart, we, again, decided to start from scratch. Sometimes that's just the easiest way to go.

We wanted to create a subscription handler that was independent of any specific site features, so, Subscribe.module was made to be completely open, allowing other modules to plug-in and handle what the subscription offers. We also needed to decide on what payment gateway and method to use. Authorize.net was chosen because it seems the most developer-friendly and there are a lot of code examples out there already. Authorize.net offers ARB (Automatic Recurring Billing) and CIM (Customer Information Management). We needed rebilling, but ARB focuses more towards fixed subscription prices - and we needed to be flexible. CIM securely stores customer payment profiles in compliance of PCI standards. Also, you can easily tell Authorize.net to charge a CIM profile for any amount needed; very easily. So we decided to only use CIM, and build the module to handle rebilling and invoicing. And now we have a full subscription module package:

• Subscribe: Handles user subscriptions, issuing payments, and invoicing
  • Set the payment interval at 1 day, 7 days, 14 days, 1 month, 3 months, etc.
  • Set a fixed price or allow module hooks to determine the price (any amount of modules can add or subtract from the price)
  • Set a max amount of payments to issue per cron run
  • Max Payment Errors: Set an amount of allowable consecutive payment errors before blocking a subscription. If a subscription's payment attempt fails, it will be retried every 24 hours, the amount set here. Once blocked, the user will be prompted and can submit for an unblock request in which their credit card will be tried again and unblocked only if successful.
  • Send configurable emails for all payment actions: Success, Fail, Blocked.
  • Provide the sign up form, and billing information change form.
  • Keeps track of every payment attempt made and invoicing
  • Currently only supports the Authorize.net module (see below)
  • Hooks:
    • hook_subscribe_payment_api() [based on result or to fetch amount]
    • hook_subscribe_confirm_message()
    • hook_subscribe_cancel_message()
• UC_Authorizenet: Implementation of Authorize.net CIM API (recycled from Ubercart)
  • Modified from Ubercart module to work without Ubercart, and with Subscribe.module
  • Handles the creation, deletion, updating, and charging of CIM profiles
  • Links CIM profile ID's to Subscription ID's

Creating the Intranet

As stated before, that was the most time-consuming, but not the most difficult. The software underwent radical changes almost every week or two. We did not have a set plan to begin with - more of like just seeing all of the great features we could implement that made sense, then working off of those. Also as stated before, the majority of the functionality stems from Views, Panels, and CCK. We used CCK to create 9 important content types which seemed to fit the needs of a business intranet:

• Blog Entry
• Company
• Contact
• Event
• File
• Poll
• Private
• Resource
• Task

We created 3 simple user roles: Client, Employee, and Superuser. Every view, panel, page, and block use these roles to strictly keep certain users from viewing important information. Client accounts are a handy feature to have in an intranet, because having your clients be able to log in and submit events, tasks, and files, is an amazing productivity booster - and makes the software that much more useful.

To keep owners from rambling through settings, and most importantly, altering the Subclient settings (which effect price), the admin account was created and blocked, so no user has full administrator control of the Intranets.

Important Non-Core Modules Used

• Views
• Panels + Delegator
• CCK
• Activity (modified)
• Calendar + Date
• Privatemsg
• Messaging + Notifications
• Pathauto
• Securepages (modified)
• Popups
• Node Access User Reference
• RoleAssign (modified)
• Content Access
• Facebook Statuses (modified)
• Shoutbox (modified)

More Information and a Demo of OfficeMedium

Homepage: http://www.officemedium.com

Screenshots: http://www.officemedium.com/screenshots

Live Demo: https://demo.officemedium.com

Features: http://www.officemedium.com/features

Solutions: http://www.officemedium.com/solutions

About Us: http://www.officemedium.com/about

Conclusion

This was an amazing accomplishment and project for all of us. It was extremely exciting to see it finally come to life, as we are now open for business. We are currently charging a monthly fee of $6/user, $1/gig, with a free 512MB of storage space, and your first month completely free (recently reduced by 25%).

These amazing Drupal modules will be shared with the community soon, just as all of you have shared your great software with us. We still need to go over them to make sure they are completely safe to share, as well as add a handful of features that we feel would make great additions.

Please leave any comments or questions below and I will answer them all. Check back for changes, as I will be adding and editing this page.

I hope you all enjoyed this post.

Thank you,

OfficeMedium