Building Customized Versioning for Google Docs

Table of contents
Reading Time: 2 minutes

Many of us are amazed by the collaboration and functionality that Google Docs provide, however when you are talking to enterprises, that too one of the largest BPO’s in the world, the situation gets a little different. There are some inherent needs of the enterprise which cannot be met right out of the box by Google products. I would like to present one such situation where the BPO is a heavy user of a well-known Microsoft web application platform and wanted a DMS like functionality to be achieved with Google Docs. One of the requirement was to do custom versioning of the externally uploaded files.

Let us see what it means. If you upload 2 documents by the same name on Google Docs, you would see the results as the following (in this case we are uploading the CSR record of the BPO)

As you would notice, the CSRLog.pdf file is shown twice with different timestamps. You could argue that it is already a kind of versioning because in any case you have different timestamps. Try explaining that to the enterprise 😉

Ok, so what is the business need.

  1. As soon as a file with the same name is uploaded through our custom gadget, rename the earlier one with an incremental version number. So if we already have SomeFile.pdf and the last version is say SomeFile_v1.pdf then rename the existing SomeFile.pdf to SomeFile_v2.pdf and upload the new one as SomeFile.pdf
  2. Also, the old versions should be archived in a folder called “Archive” and the latest one should not be tagged with any collection
  3. While uploading the document, there should be a capability to add custom metadata with the documents

So what would the new uploaded functionality look like

If you notice, not only the documents have versions now but, the previous documents are also archived in a separate archival folder.

What would the user stories for this functionality look like?

1. Building a GWT gadget to upload the file on Google App Engine (this Google gadget would be embedded in the Google Sites / Website of the client)
2. Handling file operations on Google App Engine. Assuming that the GWT gadget would be deployed on the app engine
3. Interacting with Google Docs on the app engine
4. Embedding the external versioning gadget as a part of Google sites or website.

Let us see how we went about each of these steps one by one in the subsequent posts.

Inphina, as an expert on Google App Engine and Google Apps has helped more than 10 medium to large organizations help take advantage of the cloud by building, migrating or re-engineering their complex line of business applications to the cloud thereby making significant reductions in their capex expenditure. If you are interested in an assessment send us a mail at cloud@inphina.com

Written by 

Vikas is the CEO and Co-Founder of Knoldus Inc. Knoldus does niche Reactive and Big Data product development on Scala, Spark, and Functional Java. Knoldus has a strong focus on software craftsmanship which ensures high-quality software development. It partners with the best in the industry like Lightbend (Scala Ecosystem), Databricks (Spark Ecosystem), Confluent (Kafka) and Datastax (Cassandra). Vikas has been working in the cutting edge tech industry for 20+ years. He was an ardent fan of Java with multiple high load enterprise systems to boast of till he met Scala. His current passions include utilizing the power of Scala, Akka and Play to make Reactive and Big Data systems for niche startups and enterprises who would like to change the way software is developed. To know more, send a mail to hello@knoldus.com or visit www.knoldus.com

Discover more from Knoldus Blogs

Subscribe now to keep reading and get access to the full archive.

Continue reading