7.3 Sample scenario


7.3 Sample scenario

The sample application is a Pervasive Portal for a computer maintenance company. It can be used by its customers, technicians and help desk attendants. This Pervasive Portal can be accessed through a regular Internet browser like Netscape or Internet Explorer, and also through a cell phone with a WAP browser or a PDA with PalmOS. It can be expanded to other platforms supported by the tools used, such as WebSphere Everyplace Access.

The sample application implements a help desk portal with three perspectives: customer, technician and customer service attendant.

The customer perspective shows the "problem entry" and the "problem follow-up" applications. These applications are available through a Web browser, on PDAs and for WAP phones. In the technician perspective, it also has the "close defect" and "invoice customer" applications and access to the knowledge system. The call center attendants can have the same perspective as the customer but can search the knowledge database to find help for the customer at the first call.

This section gives a detailed description of the sample scenario we have used for this book. This scenario is based on a sample application that handles service requests from the customers, manages the service fulfilment, and provides help for the agents in the field.

There are three different types of users for the application:

  • The Client can submit a request to the system. There is an option to request help using a computer with a simple Web browser. Since the application handles service requests for computer parts , the computer is probably going to be broken, so we have to provide another channel for the customer: a phone contact.

  • The Customer Service will help the customer submit the request, in case the customer has a broken system or is not willing to use a Web browser on a computer.

  • The Technicians are the technical specialists who can fix the problem at the customer site. They need to know about the problem, the details of the problem, the address where the problem has to be solved . They have to be able to place orders remotely in case the service requires new parts or replacement. The technician needs to have access to a knowledge or supporting database to solve unusual situations and problems.

    With today's technology, we can arm the technician with several different accessories on the field, for example a laptop, PDA, or intelligent wireless phone. These instruments all have some sort of network connection to the Internet, either wireless or wireline connection, permanent (online most of the time) or temporary (offline most of the time).

7.3.1 Business flow

The business flow explains how the solution works in an everyday situation, without too many technical details. There are three different flows, according to the roles identified for the business.

  1. Customer's perspective

  2. Customer representative's perspective

  3. Technician's perspective

Customer flow

  1. The customer runs into a hardware problem with the machine in the office. The hardware is supported by the company from our sample scenario.

  2. The user goes to the company's Web site to submit a service request.

  3. If the user is not registered yet, then he/she can register via the registration page and process.

  4. Once the user is registered or logged in, a service request needs to be submitted. The request is a simple Web-based form; it needs to be filled out and sent to the system.

  5. The user gets a reply from the system that the request was successfully processed .

  6. Based on the severity of the problem, the technician will visit the location, sooner or later, to fix the problem.

Customer representative flow

  1. The customer calls the customer representative to get help and schedule a service for the defective hardware.

  2. The customer representative uses an intranet version of the same application that the customer uses to submit a new service request.

  3. The request is a simple Web-based form; it needs to be filled out then sent to the system.

  4. The customer representative gets a reply from the system that the request was successfully processed. The customer representative can tell the customer about the details of the request or can send a notification to the customer.

Technician flow

  1. The technician receives the service request. If the request has a high priority, the technician gets a notification on a pervasive device. Otherwise, the technician can get the details by synchronizing a PDA, accessing the company's Web site or accessing the Pervasive Portal application with a smartphone. The technician receives a to-do list with the service request items.

  2. The technician goes to the customer to repair the defective hardware.

  3. The technician can access the company's knowledge database to find further information about the defect discovered at the customer site. It can be accessed with a browser on a laptop or a PDA, with a smartphone or using an interactive voice response system.

  4. If it is necessary to order parts to repair the hardware, the technician must fill out the order request form using a browser on a laptop, a PDA or a smartphone.

  5. The technician can also close the defect and put it in the closed state. In this case, the defect will disappear from the to-do list.

7.3.2 Component diagram

Figure 7-1 on page 115 depicts the components in the sample application.

click to expand
Figure 7-1: Component diagram
Note  

The Voice Server was not implemented in this book.

The client and the customer service users are using a desktop machine with a Web browser to access the portal application in order to submit a service request.

The interesting part is when the technician comes into the picture. There are different scenarios for this user, depending on the field device.

  1. Portable computer (laptop) with remote network connection. This option is quite simple; the technician needs a remote connection to the network to access the application using a Web browser.

  2. Smaller, more portable PDA for field agents. There are options again using this device:

    1. If the PDA has an online network connection and is powerful enough, then it can run a Web browser that is capable of handling simplified Web content. This option is very similar to the first one.

    2. The other option is to use the synchronization capabilities of the PDA and download (synchronize) the data between the server and the PDA every once in a while, when the technician has access to a network, to get the service request and the customer information. The synchronization can happen at the base (service provider station) a couple of times a day, or at home in the morning and evening.

      The knowledge management supporting database can be too "heavy" for a PDA to store everything, so the technician needs an alternative way to access that data. In this case, a simple telephone application (VoiceXML) can help out the technician to access the necessary information.

  3. An intelligent wireless phone (for example, a WAP phone) has limited online browsing capabilities. The technician can access the most essential information in order to get the service request and the customer information.

    The phone device is definitely not capable of storing or showing support information for the service. The knowledge database in this case can be accessed through a voice (VoiceXML) application.

7.3.3 Use case diagram

We have two actors in the system; one is the client that can register one defect. The client need to log in to the Portal because only authenticated users can log in to the system.

You can create new users with the self-register option in the Portal. The user will be saved in the LDAP Server (IBM SecureWay Directory).

The other actor is the technician. This user cannot register using the application; technicians are added to the system internally. There is a group created in the user registry (LDAP) and all technicians can join the group .

Important:  

In the application database, there is one table that states which technician ID is responsible for receiving the defect to work on. If you would like to create a new technician ID, you should create the categories and put this ID in a RESPONSIBLE_TECHNICIANID field in the CATEGORY table. The system uses this table to redirect the defect.

The technician can get information from the knowledge database; this database works as an intellectual capital.

Another function is checking the status of a reported defect. The technician can see who the client is and what the problem is. When the problem is resolved, the technician can close the defect and submit an invoice to the client.


Figure 7-2: Help desk use case diagram

7.3.4 Class diagram

This next diagram helps to understand the classes created for the sample scenario. It is not the goal of this book to explain in detail the decisions involved in the business structure.

Each entity bean maps one table in the database. These beans do not contain business process logic; they only model the data.

The value that entity beans provide is an object-oriented in-memory view of data in an underlying data store. The traditional method for applications in dealing with data is to work with relational tables in a database, reading and writing the data as needed. Entity beans, on the other hand, are object representations of this underlying data. You can treat data in a relational store as real objects. You can read an entire set of data out of a database at once into an in-memory entity bean component. You can then manipulate this entity bean in memory by calling methods on it.

Because EJBs model permanent data, entity beans are long lasting . They can survive critical failures, such as application servers crashing, because entity beans are just representations of data in a permanent, fault-tolerant underlying storage.

If a machine crashes, the entity bean can be reconstructed in-memory again by simply reading the data back in from the permanent database. Because the database survives crashes, the components that represent them do as well.

Figure 7-3 shows the relationship between the defect, order, category and knowledge management EJBs.

click to expand
Figure 7-3: Class diagram - persistent class

In our sample, the stateless session bean is working in a session facade pattern; it has to interact with entity beans and the portlets have to interact only with the stateless session bean.

click to expand
Figure 7-4: Class diagram - business class interaction with the entity bean

7.3.5 Sequence diagram

In Figure 7-5 on page 120, you can see the interaction between the portlets and the business components.

click to expand
Figure 7-5: Sequence diagram - make order

In the figure above, the portlet is PortMakeOrder . The business component is an EJB Stateless Session Bean. Its name is DefectService . The portlet has no access to the persistent component (entity bean) because the portlet knows only the business methods.

When the business method needs to send the results to the portlet, the portlet calls a method on the session bean to create a Value Object component. If you want to know more about this pattern, refer to "Data communication between the portlets and business tier " on page 135.




Patterns. Pervasive Portals
Patterns: Pervasive Portals Patterns for E-Business Series
ISBN: 0738427772
EAN: 2147483647
Year: 2002
Pages: 83
Authors: IBM Redbooks

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net