Track your development and integration efforts with IBM Rational Application Lifecycle Management

IBM Redbooks Solution Guide

Published 13 October 2014

Authors: Ernest Calalang, Kapciak Sebastian

Abstract

Your integration environment plays a key role in allowing solution components to communicate using their native mechanisms and protocols. The business scenario in this Solution Guide is an example of the variety of technologies that can be used for integration.

The modern IT world shows a rapid change in application integration and systems development. With this rapid change, organizations have to shorten delivery times, reduce the cost of software and mobile application development, and maintain the quality of product offerings. Although these objectives are occasionally conflicting, each is a high priority. Application Lifecycle Management is a methodology that enables you to meet these objectives.

This IBM® Redbooks® Solution Guide describes the use of the Application Lifecycle Management methodology to manage how to build business applications that use a number of IBM products. These include IBM WebSphere® Application Server, IBM WebSphere Message Queing (MQ), IBM Integration Bus, IBM Business Process Manager, IBM Operational Decision Management, IBM Worklight®, and IBM UrbanCode™ Deploy. Primary users for this information are those involved with systems development and applications integration.

Contents

Your integration environment plays a key role in allowing solution components to communicate using their native mechanisms and protocols. The business scenario in this Solution Guide is an example of the variety of technologies that can be used for integration.

The modern IT world shows a rapid change in application integration and systems development. With this rapid change, organizations must shorten delivery times, reduce the cost of software and mobile application development, and maintain the high quality of product offerings. Although these objectives are occasionally conflicting, each is a high priority. Application Lifecycle Management is a methodology that enables you to meet these objectives.

This IBM® Redbooks® Solution Guide describes the use of the Application Lifecycle Management methodology to manage how to build business applications that use a number of IBM products. These include IBM WebSphere® Application Server, IBM WebSphere Message Queuing (MQ), IBM Integration Bus, IBM Business Process Manager, IBM Operational Decision Management, IBM Worklight®, and IBM UrbanCode™ Deploy. Primary users for this information are those involved with systems development and applications integration, as shown in Figure 1.


Figure 1. Team members build and deploy applications that use multiple IBM products


Did you know?

Application integration and systems development need a unified process for managing projects, from requirements gathering, to application development, to governance. Application Lifecycle Management can coordinate your activities and assets to produce, manage, and change software applications throughout their lifecycle.

Business value

The Application Lifecycle Management methodology can assist you with:

  • Making delivery times shorter
  • Reducing the cost of software development
  • Maintaining the quality of product offerings
  • Building and deploying business applications that use:
    • IBM WebSphere Application Server
    • IBM WebSphere MQ
    • IBM Integration Bus
    • IBM Business Process Manager
    • IBM Operational Decision Management
    • IBM Worklight
    • IBM UrbanCode Deploy
  • Coordinating activities and assets to produce, manage, and change software applications throughout their lifecycle.

IBM, Hewlett-Packard, and Computer Associates are some of the vendors that have products that implement Application Lifecycle Management. Rational® Collaborative Lifecycle Management is the implementation of Application Lifecycle Management that IBM uses.

The Application Lifecycle Management methodology is an end-to-end solution that can track the most significant project activities:
  • Project management
  • Asset management
  • Requirements gathering
  • High-level design (architecture)
  • Low-level design
  • Build and software development
  • Quality assurance
  • Release management
  • Change management

A Business scenario is included in this Solution Guide in which an organization has multiple products that need to be integrated. For more information and a deeper understanding of this scenario, see Creating integrated WebSphere solutions using Application Lifecycle Management, SG24-8243.


Solution overview

In today's fast paced environment, project management usually works in silos, and this can often cause project delays, thus adding to the overall cost of the project. The structure of teams today is tightly coupled. Teams cannot send a solution to the next team to integrate, test, or deploy. The stakeholder (customer) needs to know the demands and needs of their users. Business analysts need to be more involved with users, so they are aware of the users’ pain points and where the system can be improved. Architects need to be involved to determine which architectural principle or pattern applies to the business. They need to know the stakeholders’ needs as well. These efforts must be cascaded to the software developers, so they can understand the business well and identify assets that can be reused. For software testing, quality assurance testers need to be closely aligned with the business analysts to ensure that the applications delivered are high quality.

When complexity affects quality, it affects the entire business. This costs your organization real bottom-line cost, damage to your reputation and client relationships, and damage to your clients’ loyalty. There is also the risk of managing multiple applications that can cause product recalls. This is also damaging to business.

Application Lifecycle Management is a widely accepted methodology that involves the coordination of activities and assets to produce, manage, and change software applications throughout their lifecycle. Use IBM Rational Collaborative Lifecycle Management to implement Application Lifecycle Management. IBM has offerings to support each of the practices that are required for continuous delivery, that is, the develop, build, deploy, test, and release practices:
  • Rational Collaborative Lifecycle Management offerings enable agile development to support collaborative requirements management, development management, test (quality) management, and build management.
  • IBM UrbanCode solutions enable application release automation and support the practice of continuous release and deploy.


Solution architecture

To meet all of the requirements for the business problem, several software components must be used.

You need to provide two different access channels for users, so that web and mobile access are provided by separate services. Both services trigger the Redbooks Company Service Desk business process, which handles the execution of business rules and the approvals that are required from technical support and the financial manager to complete the process. Generally, use a single integration point that handles the transportation and mediation of the incoming messages. Such a component performs the enterprise service bus (ESB) role. It translates the incoming messages so that process management can understand them. The last important component of the solution is the database where all claim records are kept and updated throughout the business process lifecycle.

The following are the key elements for implementing the solution:
  • Web application server
  • Mobile access server
  • ESB
  • Process management server
  • Database

Figure 2 shows a high level solution overview for the business scenario.


Figure 2: High-level solution overview for the Redbooks Company Service Desk

The solution requires the implementation of each of the elements specified in Figure 2.

The following table maps the key solution elements to specific IBM software products that are used for the implementation. These products establish a solid technology baseline for the solution, upon which the customer-ready system is created.

Table 1. Map of key solution elements to IBM product components (part 1 of 2)
Solution component nameProduct nameFunction within this solution
Web Application ServerIBM WebSphere Application ServerProvides a scalable Java Enterprise Edition (Java EE) platform that runs a custom developed web application and many other advanced features and tools that can be used with little or no configuration to perform a fast integration with other components.
Mobile access serverIBM WorklightProvides an advanced platform for developing, deploying, hosting, and managing mobile enterprise applications for smart devices. The Worklight server is also a scalable gateway based on Java between applications and internal services.
Enterprise service busIBM Integration BusProvides a great variety of options for implementing a universal integration foundation, based on enterprise service bus. It enables the integration of data sources from both web and mobile channels, and provides the transformation of the messages running inside the solution.
Process management serverIBM Business Process Manager AdvancedProvides a comprehensive business process management platform. The Advanced edition supports high-volume automation, and extensive system integration and human workflow. The main components of this product are the process server, process center, IBM Process Designer, and IBM Integration Designer.
IBM Operational Decision ManagerProvides a comprehensive platform for the management and execution of business rules and business events:
  • WebSphere Decision Center enables business users to govern business rules and business event-based decision logic.
  • WebSphere Decision Server automates decision logic, enabling sense and respond actions based on the context of an event.
DatabaseIBM DB2®Provides a scalable, enterprise-wide solution for handling high-volume workloads and relational data structures.

Additional solution artifacts

The final solution consists of the elements in Table 1 that must be configured and integrated with other components. The need for custom made artifacts, such as applications, business processes, rules, and integration flows is addressed. The following is a brief list of extra artifacts that complete the solution:
  • The dynamic web application, packaged as a web application archive (WAR file), includes an HTML-generated claim form for the user and controller logic for sending a message containing the user input to the Integration Bus.
  • The mobile, integrated application that enables mobile users to file the same claim form as do the web application users, and send it to the Integration Bus from a smart device.
  • Integration flows that retrieve messages from both web (Extensible Markup Language (XML)) messages and mobile (JavaScript Object Notation (JSON)) messages, transform them, persist them in the database, and start the business process.
  • The business process and set of business rules that model the acceptance process of the claim form, including human tasks required for the business user to submit a claim for approval.

The database contains the tables and relations that are required to store claim requests from users.

Determine the deployment topology

This section describes the deployment topology and configuration aspects of each of the solution components.

The final solution is composed of the elements described in Table 1. Figure 3 shows a detailed deployment diagram of the components with the custom made artifacts.


Figure 3. Deployment diagram of the components and the custom made artifacts

As you can see in Figure 3, some of the integration between the solution components is done using functions that are provided by products, such as messaging providers. However, some require further development to ensure proper integration, such as custom integration flows.

The Integration Bus consists of two integral components: the Integration Server and the WebSphere MQ Queue Manager. Both are installed on the same system. The following are also true about this configuration:
  • All custom integration flows with the integration logic are run in the Integration Server runtime environment, which has access to the WebSphere MQ Queue Manager.
  • There is a single queue defined on the WebSphere MQ Queue Manager, which is exposed to the WebSphere Application Server.
  • The web application uses the WebSphere MQ messaging provider from the WebSphere Application Server to communicate with the WebSphere MQ Queue Manager and send the messages to its WebSphere MQ queue using Java Message Service (JMS).
  • The mobile application runs on the business user’s smart device. To communicate with the Integration Bus, it uses the Worklight environment, which provides an HTTP adapter. This adapter is configured to communicate with the Integration Bus message flow using Representational State Transfer (REST) services.

    Note: This is a simplified scenario to demonstrate the integration capabilities of the WebSphere components. In a real-life production environment, both web and mobile users are not to communicate directly with the WebSphere Application Server or the Worklight server. Consider an extra firewall configuration for securing local area networks (DMZ) with HTTP proxy servers to secure this communication.

The business process part of the solution is running on two components that are installed separately:
  1. The Decision Server, which is part of the Operational Decision Manager product. It runs all decision rules that are used in the solution.
  2. The Process Center, which is the runtime environment for business processes, which are defined in the Business Process Manager.

Both of these products are implemented on the WebSphere Application Server runtime environment and use its JDBC provider features to connect to the DB2 database.

Software development using Application Lifecycle Management

The team members involved in this business scenario play critical roles during the implementation of this solution. All of these efforts began with clearly defined business requirements:

  • Information defined by the stakeholders is used to complete activities across multiple software disciplines. These activities include extra elicitation techniques, when needed, so that all team members have a clear understanding of each requirement.

    The stakeholders have the opportunity to convey their business needs by using the language and vocabulary of the business and its customers. Requirements definition and management activities ensure that the business ideas are captured and communicated to the solution team, and, at the same time, the solution team learns the nuances and expectations of the customer.

  • The business analyst contributes to the effort by providing context around the statements expressed by the stakeholders. Context is provided in the form of business processes or application sketches, storyboards, models, and other rich text content.
  • After the requirements are approved, the project leader plans all of the related activities. The project leader and stakeholders review the plans during the project, and the project leader updates the requirements to reflect the team's decisions. The project leader also controls the activities that are assigned to the developers.
  • With all of these activities planned, the developers can track and monitor their assigned activities using IBM Rational Team Concert™ queries and dashboards. All code changes made by them are associated with their assigned activities, and version controlled by the software configuration management component of Rational Team Concert.
  • After development efforts are completed, the testers create test plans and associate them with the stakeholder’s approved requirements. If errors are found during test plan execution, the tester might open a defect associating the test plan to the errors. The defect is assigned to the developer who fixes it.
  • After the tests plans are run and defects fixed, the release engineer can request the build for the code using the built-in Rational Team Concert build engine. The release engineer then monitors the build results using the Rational Team Concert dashboards.
  • On the governance side of the business scenario, the project leader and project manager have consistently current information available about project activities through real-time dashboards and reports that are available with the tools.

This end-to-end solution is Rational Collaborative Lifecycle Management. It is a collaborative solution in which all team members share all information about the tools that are available to help them do their jobs. Figure 4 shows an example of how all team members can use the Rational Team Concert dashboards to track assigned activities, other planned project activities, and build results. The Rational Team Concert dashboards are updated in real time during the entire software development lifecycle.


Figure 4. Rational Team Concert dashboard example


Business scenario

This section describes a fictitious business scenario and how Application Lifecycle Management can assist with meeting the project requirements in your environment. Figure 5 depicts the initial business problem that Application Lifecycle Management will address.


Figure 5. The business scenario

The business problem

The Redbooks Company Service Desk is having a problem with a lack of automation at their service desk. By repeating manual tasks, such as reviewing warranty claims and parts, the company becomes less productive.

This business scenario describes a warranty claim system that is used to accept all of the claims that are entered by the users from either the web or from mobile devices. The system can determine the appropriate course of action the business might take, given the clients’ input, to track and resolve warranty claims. A business process to automate tasks, and business rules will be created that will determine which category the product falls into.

The following is a high level process flow, as currently practiced at the Redbooks Company Service Desk:
  1. A client provides the serial number of a purchased product and submits it from either the web or a mobile application.
  2. When a claim is received, the system starts a business process to initiate the warranty review.
  3. If the system records multiple pending claims for the same serial number over a specified period, the system automatically rejects the claim. Otherwise, the system triggers an event to indicate that these claims with the same serial number need further investigation.
  4. Multiple claims with the same serial number are routed to technical support staff for further investigation, and they assess if the claim is valid.
  5. The process then starts a business rule, wherein the serial number is assessed if the parts that are affected have low or high impact in terms of cost. A claim requires special handling if the assessment from the business rules produces a high impact to cost.
  6. In cases for which there is a high impact to cost, the financial manager then approves the claim for special handling. Otherwise, the claim is processed automatically for implementation.
  7. All claims are written to the database for logging and tracking purposes.

This scenario describes how project team members can take advantage of events using well-defined processes to create rapid changes and flexible business decisions. This solution describes how the components fit together to become one system.


Solution integration

Your integration environment plays a key role in allowing solution components to communicate using their native mechanisms and protocols. The Business scenario in this Solution Guide is an example of the variety of technologies that can be used for integration.

The WebSphere family of products is known for its ease of integration with other systems. The main integration point of the solution is the Integration Bus, which can handle a wide variety of different protocols. To demonstrate this, use WebSphere MQ as an asynchronous method for delivering messages from the application server to the Integration Bus. The web application uses Java Message Service (JMS) to deliver an XML message to the WebSphere MQ queue. The Integration Bus listens on this queue and picks up the messages that arrive.

The mobile application integrates with the Integration Bus through the Worklight HTTP adapter. It sends a synchronous HTTP request to a REST service using JSON data.

When the user submits the claim form, both web and mobile applications generate a tracking number, enabling users to check the status of the request. This tracking number, along with a time stamp, is included in the data payload that is sent to the Integration Bus.

The Integration Bus transforms the incoming messages so that it can persist them in a relational database using the native Open Database Connectivity (ODBC) drivers. Additionally, after it commits the record to the database, the Integration Bus updates a log file for each request. This log file is an extra solution feature that can be helpful for administrators in tracing whether the request came from the mobile or web application. The last part of the integration flow that is run by the Integration Bus is the invocation of a business rule, which is exposed as a web service by the Operational Decision Manager.

The purpose of the exposed business rule is to verify whether the user claim request is valid and whether it will initiate the business process. If so, the Operational Decision Manager triggers the business process using a web service call to the Business Process Manager.

During the business process flow, the Business Process Manager is the supervisor of the business process state. However, it queries the Operational Decision Manager for any decisions that are based on business rules (for example, to check whether the serial number requires more financial manager approval). The Business Process Manager handles the tasks carried out by humans, such as providing approvals, and it updates the final status of the claim form in the database. Both the Business Process Manager and the Operational Decision Manager use JDBC connections to communicate with the database where the claim form was persisted.

Figure 6 shows the integration model for the solution.


Figure 6. Solution integration model

Detailed integration tasks are provided in the companion book to this Solution Guide (see Creating Integrated WebSphere solutions using Application Lifecycle Management, SG24-8243).


Supported platforms

IBM products support most of the current operating system versions. For a detailed compatibility report of the product versions that will suit your environment, including hardware and hypervisor editions, see:

http://www.ibm.com/software/reports/compatibility/clarity/index.jsp


Ordering information

Software packages might differ between development, test, and production environments. The ordering information shown in Table 2 is intended for a full production environment that requires high availability and disaster recovery functionality.

Table 2. Ordering part numbers (part 1 of 2)
Package namePart numberDescription
IBM Integration Bus V9.0CRM3TMLMulti-platform
IBM WebSphere Application Server Network Deployment V8.5.5CRM34ML, CRM35ML, CRM36ML, CRM37MLMulti-platform, package also contains the Liberty profile
IBM Worklight Enterprise Edition V6.2 CRR8UENMulti-platform
IBM Operational Decision Manager V8.6CRRU3MLThis package is intended for the Intel x86 platform for Linux only, but there are separate packages for other distributed system platforms

Table 2. Ordering part numbers (part 2 of 2)
Package namePart numberDescription
IBM Business Process Manager Advanced Version 8.0CRIG8MLThis package is intended for the Intel x86 platform for Linux only, but there are separate packages for other distributed system platforms
IBM DB2 Enterprise Server Edition V10.5CRMG3MLLinux, UNIX, Windows, package for IBM z/OS® also available
IBM UrbanCode Deploy V6.0.1CRPU3ENMulti-platform
IBM Rational Collaborative Lifecycle Manager Server Install V4.0.6CN0M4MLMulti-platform


Related information

For more information, see the following documents:


Special Notices

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.

Follow IBM Redbooks

Follow IBM Redbooks