Ujumbo: A Generic Development Toolkit for Messaging Based Workflows Dept. of CIS - Senior Design 2012-2013 Archit Budhraja Bob Han Sung Won Hwang [email protected] [email protected] [email protected] Univ. of Pennsylvania Univ. of Pennsylvania Univ. of Pennsylvania Philadelphia, PA Philadelphia, PA Philadelphia, PA Jonathan J. Leung Sean Welleck Boon Thau Loo [email protected] [email protected] [email protected] Univ. of Pennsylvania Univ. of Pennsylvania Univ. of Pennsylvania Philadelphia, PA Philadelphia, PA Philadelphia, PA ABSTRACT We began development by consulting local and interna- Many organizations, especially in developing countries often tional nonprofits and small scale organizations that may lack technical expertise, resource, and financial capital neces- require custom platforms in their operations. We gath- sary to build applications with complex logic flows. Looking ered data on their proposed workflows, needed functional- at the different kinds of products on the market, there seems ity, as well as surveyed their available financial resources. to be a lot of commonality between them yet each of them After talking to several resource-constrained and non-profit is developed independently of each other, requiring program- clients, it was observed there was far too much manual com- ming ability and a substantial investment in time and financ- munication. Most organizations we interviewed are physi- ing for each application. Our project aims to reduce these cally entering and processing data on day to day operations, additional costs in building a new application with common often in simple spreadsheet software. They also invest many communication features by creating a generic platform that hours manually calling and text messaging their members for users with non-technical abilities could build off of. This recurring events. Due to their rapidly expanding user-base, will lower the temporal, financial, and technical knowledge many have expressed an exigent need to automate these pro- required to developing the additional application. cesses. This motivated us to create an efficient and general In the paper we will further discuss the motivations for toolkit of such tools. our platform, the high level structure of our program, how Our finished product has the ability to read spreadsheet it is implemented, and the work we have completed and the and CSV input data from Google Docs or outsourced CSV work that still remains. files; Bulk SMS/Email sending features using Twilio for SMS and SendGrid for Email, and scheduling ability using Resque scheduler. By integrating all these features into a 1. INTRODUCTION comprehensive platform, we can let different organizations Communication and general management platforms have save time, effort, and money from repetitive manual work rapidly grown in recent years due to the increased reliance by allowing them to use our platform to create a customized on cell phones and the rapid adoption of web and electronic application suited to solve their particular problem. management of data. Many organizations are leveraging this In order to implement such system with different inputs technology by building complex services on top, as well as and communication outputs, we developed an architecture relying on these technologies to manage general day to day called \Pipeline", a chain of modules that perform a cus- operations. tom series of actions on the data dictionary input. The At the same time, many small scale organizations as well idea of this architecture is motivated from Rack Middle- as non profits, often lack technical expertise, resource, and ware(Rack) [7], an interface between Ruby web servers. We financial assets necessary to build such web and mobile ap- will talk more about the details of what a pipeline is and plications. Looking at the different kinds of products on how it works later in the System Implementation section. the market, there seems to be a lot of commonality between them. Yet, each of them is developed independently of each 2. RELATED WORK other, requiring programming ability and a substantial in- vestment in time and financing for each application. We investigated several services and products that are Our product aims to reduce these additional costs in build- similar to our project in terms of functionality, target au- ing a new application with common communication features. dience, and/or software architecture. We have created a generic platform that others with non- technical abilities could build off of, lowering the temporal, 2.1 Generic SMS Application Platforms financial, and technical knowledge required to develop the RapidSMS [8] is a general web framework for data collec- additional application. tion, logistics coordination and communication, using basic SMS technology. An application built using RapidSMS is addition, we have also developed the ability to batch process able to receive input from basic mobile phones, and can dis- large amounts of data for each trigger or action block. play collected data online. For example, ChildCount is a product built with RapidSMS that allows health workers 2.3 Related Software Architecture to register patients and send health reports to a web dash- In addition to applications with related functionality, we board by sending text messages. RapidSMS is an extension also did research on applications that we could use to help of the Django web framework, and thus requires program- design the structure of our platform. The architecture of ming ability for setup, use, and customization. RapidSMS Rack [6] middleware is similar to our platform's structure. differs from the proposed project since it requires the end Rack is an interface between Ruby web servers. Using Rack, user to have technical expertise. However, RapidSMS ad- one can build a modular, minimal web application that takes dresses a similar problem space: creating a generic platform a defined environment as input, and outputs an HTTP re- for building SMS based applications. sponse. Rack is designed such that multiple applications Frontline SMS [2] is a generic, mass SMS-based platform can be chained together, with each application using the that allows users to send, receive and manage SMS over a response information outputted by the preceding applica- mobile network. Frontline SMS eliminates the need for an tion. The concept of \chaining" is used as a model for our internet connection, and allows easy development of forms `Pipeline' architecture, which links modular actions together that incorporate SMS. However, the platform does not work to create an action sequence. Another design inspiration with many phones, and does not support any Android phones. derives from Rack's Decorator pattern, which establishes a Including Frontline SMS in an application requires program- common input and output format for applications, thus al- ming ability; however, simple SMS based applications such lowing general chaining. Namely, all Rack applications in- as surveys or polls can be created without programming. put and output three element arrays. In our platform, we Frontline SMS is open-source, so we will their product can established a common input and output type by using Ruby be used for non-Android SMS communication within our hashes to pass parameters across pipes. Such a design al- platform. lows for dynamic, flexible input and output to pipes while Another product that is similar to our project is Comm- allowing pipes to be linked together. Care HQ [1]. CommCare HQ is a general platform for mobile data collection that allows creation of forms and question- 2.4 API’s naires that use mobile data as input. The platform helps Another part of our platform involves creating general with application creation and deployment, as well as man- modules for SMS messaging, emailing, document input and aging the collected data. CommCare differs from our project output, and scheduling. We have incorporated several APIs in that it does not provide a GUI for nontechnical users to into our platform in order to help accomplish these func- develop applications. tions. 2.2 Non-Technical Application Development 2.4.1 Communication API’s One existing product that opens SMS and voice-based ap- Twilio is a communication API that we use for sending plication development to non-technical users is SendFlow [5]. and receiving SMS messages and voice calls. For email send- SendFlow allows users to create interactive applications through ing and filtering, we use the SendGrid API, which provides a graphical interface. SendFlow abstracts various functions functionality for sending custom emails, filtering incoming such as SMS messaging and data source operations into emails, and defining responses to various email-related events. drag-and-drop blocks, which can be arranged into logical flows. SendFlow's user interface will be a useful guide for 2.4.2 Data I/O API’s designing the interface for our project. Our platform modularizes interaction with Google Docs. Another product that allows non-technical users to create An existing Google Docs API wrapper, called Google Drive an application is Microsoft SharePoint Designer [9]. Mi- Ruby [3], is used to implement this module. crosoft SharePoint Designer, a member of the Microsoft Of- fice suite, contains a Workflow Designer that allows users to create an application based on actions and events. Exam- 3. SYSTEM MODEL ple actions include sending an email, performing a calcula- Several difficulties that campus organizations face in their tion, or moving a document; example events include clicking operations, according to our research, have commonalities: a button, changing a document, or deleting a spreadsheet disorganized communications and manual tasks that could row. Using the Workflow Designer, a user can create a flow be automated. The specific challenges these entities face of actions and events using a graphical interface, without come down to three points: Data Input(I/O) and Model- programming knowledge. ing, Messaging or Communication, and automating a cus- The inspiration for our process flow comes from a product tom series of these items.