Chapter 3. Introducing the Sample Application
In this chapter:
Chapters Chapter 1 and Chapter 2 described the essentials of a business application, and the advantages of using CICS in business applications. The remainder of this book is concerned with the design and the programming needed to build a CICS application along the lines of those described in the previous chapters. Before getting into the details, let’s look at the business case and the reason why our fictitious company, KanDoIT, might want to develop a CICS application.
The Business Case
The KanDoIT company is a successful business with an IT department that includes a CICS development team and a web design group. It has thousands of customers. The customer accounts file holds the customer’s name, address, telephone number, charge limit, current balance, account activity, payment history, and so on. It uses a short, unique account number that is allocated manually (this wouldn’t happen in the real world but it’s included here for simplicity) when a new account is opened.
The existing application creates, reads, updates, and deletes customer accounts, and it needs to be expanded to meet the expected future demand. It runs on an IBM S/390 mainframe computer that is also used for other, unrelated applications. The application was developed many years ago, and is used by staff in the accounts department and in the customer services department. The staff run, the application using 3270 terminals. The company has a web site that is used primarily as a means of advertising the company’s business.
There are several business factors influencing KanDoIT’s decision to develop a new business application:
The customer services department has a high turnover of clerical staff and the manager would therefore like to spend less time on training new clerks to use the existing system. They would like their applications to present data using a graphical user interface (GUI). As well as being easier to use and learn, it would include its own online help information. The staff in the accounts department want to retain their existing terminals, familiar transactions and data presentations.
A strategic decision has been taken to enhance the web site so that customers can access and query their own accounts.
Head office auditors want to be able to conduct random checks on customer accounts.
A typical company may have many more requirements and demands than this. But for the moment let’s consider in more detail the IT requirements for the application.
The IT Requirements
The IT requirements for the new application are:
To replace the existing application with a new one better able to respond to business requirements.
To create a GUI using Visual Basic or a similar product.
To provide customers with direct access to their own account from the Internet using a web server and a Java program running in CICS.
To support more users in the Head Office.
To reuse the existing customer account database.
The Cross-Functional Team
So what is the process for addressing the IT requirements? KanDoIt formally starts their project by holding a “kick-off” meeting and inviting all departments affected to provide one representative to be a member of the cross-functional team. This is to ensure that all departments are familiar with the new proposal and that their concerns are aired at the meeting.
At KanDoIT’s kick-off meeting, the following departments are represented. In real life, it might not be necessary to have quite such a broad cross-section of groups; nevertheless, it’s always good policy to ensure that everyone involved in the project has the chance to provide input at the earliest possible stage. This can help to avoid extensive redesign later on.
- Application architect
This person directs the overall design of the application, but needs more information before submitting a proposed architecture.
- Security
This group is responsible for anticipating and preventing methods of defrauding the company, and ensuring data protection for customers, especially when the system is connected to the Internet.
- Audit
The Audit group is responsible for the integrity of the customer account record database. They are concerned with the diagnosis and correction of data corruption, and logging of user activity.
- Visual Basic development
This group is concerned with requirements and design of the new interface for the customer services department.
- Accounts department
This group would like to keep their familiar 3270 terminals and transactions.
- Customer services
This group would like to replace the user interface for the customer services department with a new, user-friendly one.
- Head office
This group wants the availability of data during specific business hours, and they want that data to be accessible with rapid response to achieve, for example, higher employee productivity and customer responsiveness.
- Web design
This group wants to enhance the web site to develop it for e-business and e-commerce.
- IT development planning
This group is concerned with project management, how much it will cost, how many people will be required, and how long it will take.
- IT technical planning
This group is concerned with capacity planning, whether the customer account record database is likely to grow as a result of the enhancements, if more MIPS (million instructions per second) are required.
- CICS development
This group is concerned with CICS aspects, and whether or not they can support the new features—the nature of the firewall, the operating system, and so on.
At the end of the meeting the application architect has the information required to make a first pass at defining the overall architecture. This will be reviewed and agreed by the cross-functional team before proceeding to detailed design and development. The next chapter looks in detail at the proposed design.
The Design of the Sample Application
Let us now look at the proposed architecture for the sample application. The key requirements for the KanDoIT company’s new system are:
Reuse the existing accounts file for a new application to keep track of customer accounts.
Provide online access to the application for the accounts department, the customer services department, head office, and for customers themselves using the Internet.
Use presentation logic and business logic components running on CICS, customer service department PCs, a web server, and so on. Server components will run on CICS to ensure that the technical requirements (see Technical Requirements in Chapter 1) are met.
The Initial Architecture
Let us now look in more detail at what each set of end users requires:
The customer services department requires:
Online access to the customer accounts database using a new, user-friendly interface written in Visual Basic and running on Windows NT workstations that can be used alongside the existing call management system.
The ability to search for records by name and to select the appropriate record easily if the search results in multiple matches.
The accounts department requires:
An account inquiry function.
The ability to add, delete, and change some fields unrelated to billing.
The ability to access records by account number. The account number is always available when they are processing work or answering questions.
The head office requires:
The ability to send an MQSeries message to obtain the full record of a customer, for audit purposes.
Customers require:
The ability to query their own account information.
Confidence that their account information is secure from other users.
It is clear that all users want to share the same data, and that they want a high-performance, reliable business logic component with a set of access services to the data. This leads to the initial architecture shown in Figure 3-1. They now need to refine the lines in the diagram above to give direction to each of the development groups.
- Customer service
The customer services department uses Windows NT workstations, and the developers of the customer services interface are using Visual Basic. So they plan to develop a component in Visual Basic that uses the External Call Interface provided by CICS (see “Designing the Visual Basic Component” in Chapter 12) to access the COBOL business logic. The programming is simplified using the VisualAge Interspace product.
- Accounts
Members of the accounts department want to continue using 3270 emulation for the repetitive tasks they perform. For this they decide to continue to use their current system, that is, a presentation logic component running in CICS using CICS 3270 presentation services.
- Head office
Head office wants to access the account files using MQSeries messaging. So the application architect decided to configure MQSeries and the MQSeries- CICS DPL bridge on their system to enable this. The sample in this book shows an application written in Java that can be used to test the messaging capability. It has been kept relatively simple for the purposes of clarity. For a head office in the real world it would have to be a little more extensive.
- Customers
The KanDoIT company chooses an approach that uses as many industry-standard components as possible. It includes a standard web browser connecting using HTTP to a web server and the WebSphere Web Application Server running Java servlets and Java server pages, connecting to CICS using the internet inter-orb protocol (IIOP). This is the approach that we have used in this book. However the burning issue that would have to be addressed and is beyond the scope of this book is security. One plan would have been to include a second database, unrelated to the account database, which would be used to validate customer access.
The end result of the planning stage looks like the architecture shown in Figure 3-2.
What’s Next…
The remainder of this book describes the steps involved in designing and developing the six components of our sample application: