Field workforce management is an application segment responsible for scheduling resources working in the field, assigning work orders, dispatching work, and letting workers report from a mobile terminal. Among those using such systems are utilities, construction crews, maintenance organizations, telecommunication operators, and equipment manufacturers responding to trouble reports. The new generation of field workforce management is based on an application server architecture and allows the field workforce to work in a disconnected mode, which is mandated by lack of full wireless coverage and by the fact that wireless networks are slow and unstable.

Utilizing Web services in this environment usually focuses on integrating workforce management systems with other systems, such as the call center system, the part management system, the financial system, and more. Web services enables faster integration and supports real-time interfacing with a lower total cost of ownership (TCO). This article, however, focuses on the use of Web services on the front end - the messaging between the mobile terminals and the central server - serving business scenarios in which the field workforce communicates with the central dispatch station as well as among themselves.

Because the workforce doesn't always have full connectivity to central dispatch, and because the network bandwidth may be limited and/or expensive, interaction between the field workforce and the server is based on store-and-forward messaging rather than "normal" Web transactions. Because the Web services model is inherently asynchronous, it fits the interaction model between the field and the central server. By ensuring that the data content is formatted using Web services and delivered over wireless messaging technology, the service enterprise can achieve lower TCO not only on the back end but also in field interaction.

Field Workforce Management
A field workforce management system can be broadly classified in two parts: the scheduling and dispatch servers and the field terminals. As Figure 1 shows, an application server manages all work orders and all interaction with the server, both from the dispatch stations and from the field. The system is accessed over either the LAN/ WAN (e.g., the dispatchers) or wireless networks (e.g., field technicians).

 

A typical scenario involves a work order that comes in from an external system (a call center system, help desk, customer information system, etc.). If back-end integration utilizes Web services, the order is created by invoking a Web service implemented by code running within the application server.

The scheduling module assigns the optimal resource to perform the work, which is then dispatched over the wireless network. This is either pushed out to the client (using a wireless messaging service) or pulled by the client device. Sometimes the implementation involves both - a notification is pushed out to the client device informing it that new data exists, and the data is pulled by the client in response to this notification. In all three cases (push, pull, and push-pull), all interaction is asynchronous because individual components in the system (and especially the mobile terminals) may not be online at a given time.

The asynchronous Web services model is perfect for these environments. While most of the current infrastructure used in these environments is based on proprietary messaging, infrastructure services are now moving to a Web services model in which the message content is packaged as SOAP messages and delivered to an endpoint defined using WSDL.

Wireless Messaging
Most of today's wireless gateways implement wireless messaging using a queuing abstraction. They implement a set of APIs that support message delivery by placing application messages into queues. Messages are received by registering to receive messages through an incoming queue. This is true for both the client and the server, as shown in Figure 2.

 

A messaging metaphor (also called store-and-forward) is simple to use and the APIs are very clean. The wireless gateway hides all details about the underlying network and will behave in the same way regardless of whether the network is IP-based, whether it does or does not support sessions, whether it requires a connection to be set up or is always on, whether multiple networks should be tried, and so on.

The major advance in the marriage of wireless messaging and Web services is Web services-aware message routing. All wireless middleware supports routing, allowing messages to be routed to the right location based on the application, the message type, or an address. Routing can be very intelligent. Advanced routing features can include routing different message types on different networks. For example, in utilities, maps and schematics may be required in the field; delivering these documents over a slow wireless network isn't feasible. However, when a truck enters a yard it usually has access to an 820.11 network through which it can receive large quantities of data.

Such routing has been based on proprietary methods and formats. A new generation of wireless middleware is on the horizon - one that uses native SOAP routing information. In such systems, the content of the SOAP envelope is inspected to determine where the SOAP request needs to be delivered and to handle additional delivery attributes packaged within the SOAP request.

Independent Contractors
While Web services can be used for all field interaction with the workforce management system, they really shine in the independent contractor scenario. Many companies employ independent contractors, which allows them to utilize skilled workers without staffing up, manage periods with peak load, and avoid complex employment contracts. The independent contractor often works with many service companies and needs to be able to perform work assigned by various sources. The field application used by the independent contractor needs to receive work orders from multiple dispatch centers. Using Web services is probably the only way to do this without incurring very large costs.

Let's look at a business environment in which "Joe" specializes in complex troubleshooting of problems related to large oil furnaces. Joe is an independent contractor and may receive work from any number of companies that provide warranty services on such furnaces.

During his workday Joe receives allocated work orders from multiple companies and is in the field doing repairs. Each of these service companies has a scheduling and dispatch system they use to pick the best resource for a given problem. These applications use a Web services-enabled Web calendaring system to access Joe's calendar information. If they select Joe as the optimal resource, they schedule the job using the Web calendaring service and use a Web notification service to inform Joe. Joe then uses his mobile device to access the company's online server through a set of Web services and download the work assigned to him (see Figure 3). Upon completion, another set of Web services closes the work order and uploads information about the finished work.

 

Peer-to-Peer Dispatching
Web services-aware wireless middleware can provide increased benefits in peer-to-peer dispatching scenarios as well. Normally, all dispatching is done from the central dispatch site by a dispatcher. However, advanced service organizations want the ability to have a field technician or a field supervisor dispatch work to a peer. This can be a transfer of work, a request for assistance, or an employee who is both a worker and a manager performing multiple tasks from the same mobile terminal.

Peer-to-peer dispatching allows mobile field technicians to remotely reassign work orders over a wireless network without the aid of a dispatcher. The new resource can accept, reject, or reassign the order. This capability allows organizations to improve productivity and customer service. The ability to share work in real time results in better workload balancing and increased field utilization. In addition, dispatchers are freed of daily work-monitoring responsibilities, which results in more time allocated to productive planning activities and reduced dispatcher costs.

The key to efficient peer-to-peer dispatching is how quickly the message can be routed to the correct field terminal. In the simplest case, every message has to make it all the way to the application server and be handled by the workforce management system - the entire system is overloaded unnecessarily. A better approach is one in which the wireless gateway can inspect the SOAP envelope and reroute the message directly to another mobile terminal, as shown in Figure 4. In this case, the central server doesn't need to be involved in the dispatch process and needs to be updated only when the work has been accepted by the receiving field technician. Perhaps one day (not for a while yet) one field terminal will directly invoke a Web service hosted by another mobile terminal.

 

Conclusion
Wireless environments are very different from classic Web environments. The networks are slow, coverage is less than perfect, and the bandwidth is extremely limited. Most importantly, the wireless-messaging world is based on asynchronous store-and-forward. Historically, wireless environments have grown separately from Web technologies, which are mostly synchronous. This is changing, however, due in part to Web services.

Wireless environments have always been message based. All wireless middleware vendors take the wireless-messaging approach, and the facilities they provide involve message queuing. Web environments, on the other hand, have been inherently synchronous and online. A convergence of these two environments is now possible due to the asynchronous nature of Web services. This convergence and the ability to run Web services over wireless middleware hold much promise for companies that have had to put up with high TCO because their environments have been highly proprietary. However, this technology is still very young - it remains to be seen whether it can deliver on the promise.