Field Service Application requirements We have established that our mobile worker will be carrying two things: a set of hand

12.1 Field Service Application requirements We have established that our mobile worker will be carrying two things: a set of hand

tools and an Android device. Fortunately, in this book we are not concerned with the applicability of the hand tools in his toolbox, leaving us free to focus on the capabilities

Field Service Application requirements

and features of a Field Service Application running on the Android platform. In this section, we’re going to define the basic and high-level application requirements.

12.1.1 Basic requirements Before diving into the bits and bytes of data requirements and application features, it

is helpful to enumerate some basic requirements and assumptions about our Field Service Application. Here are a few items that come to mind for such an application:

The mobile worker is dispatched by a home office/dispatching authority, which takes care of prioritizing and distributing job orders to the appropriate technician.

The mobile worker is carrying an Android device, which has full data service, that is, a device capable of browsing rich web content. The application needs to access the internet for data transfer as well.

The home office dispatch system and the mobile worker share data via a wire- less internet connection on an Android device; a laptop computer is not neces- sary or even desired.

A business requirement is the proof of completion of work, most readily accom- plished with the capture of a customer’s signature. Of course, an electronic sig- nature is preferred.

The home office desires to receive job completion information as soon as possi- ble, as this accelerates the invoicing process, which improves cash flow.

The mobile worker is also eager to perform as many jobs as possible since he is paid by the job, not by the hour, so getting access to new job information as quickly as possible is a benefit to the mobile worker.

The mobile worker needs information resources in the field and can use as much information as possible about the problem he is being asked to resolve. The mobile worker may have to place orders for replacement parts while in the field.

The mobile worker will require navigation assistance, as he is likely covering a rather large geographic area.

The mobile worker needs an intuitive application. One that is simple to use with a minimum number of requirements.

There are likely additional requirements for such an application, but this list is ade- quate for our purposes. One of the most glaring omissions from our list is security.

Security in this kind of an application comes down to two fundamental aspects. The first is physical security of the Android device. Our assumption is that the device itself is locked and only the authorized worker is using it. A bit naïve perhaps, but there are more important topics we need to cover in this chapter. If this bothers you, just assume there is a sign-in screen with a password field that pops up at the most inconvenient times, forcing you to tap in your password on a very small keypad. Feel better now? The second security topic is the secure transmission of data between the

C HAPTER 12 Putting it all together–the Field Service Application

Android device and the dispatcher. This is most readily accomplished through the use of a Secure Sockets Layer (SSL) connection whenever required.

The next step in defining this application is to examine the data flows and discuss the kind of information that must be captured to satisfy the functional requirements.

12.1.2 Data model Throughout this chapter, the term job refers to a specific task or event that our mobile

worker engages in. For example, a request to replace a hard drive in a computer at the bookstore is a job. A request to upgrade the firmware in the fuel-injection system at the refinery is likewise a job. The home office dispatches one or more jobs to the mobile worker on a regular basis. Certain data elements in the job are helpful to the mobile worker to accomplish his goal of completing the job. This information comes from the home office. Where the home office gets this information is not our concern in this application.

In this chapter’s sample application, there are only two pieces of information the mobile worker is responsible for submitting to the dispatcher. The first requirement is that the mobile worker communicates to the home office that a job has been closed; that is, completed. The second requirement is the collection of an electronic signa- ture from the customer, acknowledging that the job has, in fact, been completed. Fig- ure 12.1 depicts these data flows.

Of course, there are additional pieces of information that may be helpful here, such as the customer’s phone number, anticipated duration of the job, replacement parts required in the repair (including tracking numbers), any observations about the condition of related equipment, and much more. While these are very important to a real-world application, these pieces of information are extraneous to the goals of this chapter and are left as an exercise for you to extend the application for your own learning and use.

The next objective is to determine how data is stored and transported.

Home office / dispatcher

Mobile worker

List of jobs sent to a specific mobile worker

Jobs

Each job contains

Job id Customer name Address City, State, Zip Product needing repair URL to product information

Figure 12.1 Data Comments

flows between the Job status (updated by mobile )

home office and a Signature (updated by mobile )

mobile worker

Field Service Application requirements

12.1.3 Application architecture and integration Now that we know which entities are responsible for the relevant data elements, and

in which direction they flow, let’s look at how the data is stored and exchanged. We will be deep into code before too long, but for now we will discuss the available options and continue to examine things from a requirements perspective, building to

a proposed architecture. At the home office, the dispatcher must manage data for multiple mobile workers. The best tool for this purpose is a relational database. The options here are numerous, but we will make the simple decision to use MySQL, a popular open source database. Not only are there multiple mobile workers, but the organization we are building this appli- cation for is quite spread out, with employees in multiple markets and time zones. Because of the nature of the dispatching team, it has been decided to host the MySQL database in a data center, where it is accessed via a browser-based application. For this sample application, the dispatcher system is super simple and written in PHP.

Data storage requirements on the mobile device are quite modest. At any point, a given mobile worker may have only a half-dozen or so assigned jobs. Jobs may be assigned at any time, so the mobile worker is encouraged to refresh the list of jobs periodically. Although you learned about how to use SQLite in chapter 5, we have little need for sharing data between multiple applications and don’t need to build out a ContentProvider , so we’ve made the decision to use an XML file stored on the filesys- tem to serve as a persistent store of our assigned job list.

The Field Service Application uses HTTP to exchange data with the home office. Again, we use PHP to build the transactions for exchanging data. While more com- plex and sophisticated protocols can be employed, such as Simple Object Access Pro- tocol (SOAP), this application simply requests an XML file of assigned jobs and submits an image file representing the captured signature. This architecture is depicted in figure 12.2.

The last item to discuss before diving into the code is configuration. Every mobile worker needs to be identified uniquely. This way, the Field Service Application can retrieve the correct job list, and the dispatchers can assign jobs to workers in the field.

WWW Server (Apache or IIS)

MySQL with PHP getjoblist.php

closejob.php

Dispatch functions

Figure 12.2 The Field Service Application and dispatchers both

Distributed dispatchers leverage PHP transactions.

C HAPTER 12 Putting it all together–the Field Service Application

Similarly, the mobile application may need to communicate with different servers, depending on locale. A mobile worker in the United States might use a server located in Chicago, but a worker in the United Kingdom may need to use a server in Cam- bridge. Because of these requirements, we have decided that both the mobile worker’s identifier and the server address need to be readily accessed within the application. Remember, these fields would likely be secured in a deployed application, but for our purposes they are easy to access and not secured.

We have identified the functional requirements, defined the data elements neces- sary to satisfy those objectives, and selected the preferred deployment platform. It is time to examine the Android application.