| GISdevelopment.net ---> GITA 2003 ---> System Integration |
System integration using Websphere MQ
Carolyn Bakke
Senior Industry Consultant
Intergraph
Dan Givens
Senior Technical Manager
Intergraph
241 Disk Drive
Madison, AL 35758
Carolyn Bakke
Senior Industry Consultant
Intergraph
Dan Givens
Senior Technical Manager
Intergraph
241 Disk Drive
Madison, AL 35758
Abstract
Although there has been much talk about the concept of EAI, a single dominant EAI framework has not emerged in the industry. This paper will point out the trends and benefits associated with EAI strategies and then focus on one aspect of EAI – message brokering. A case study will be presented a utility using MQSeries middleware to manage interfaces between their geospatially enabled workforce management systems and other enterprise systems.
Introduction
Enterprise Application Integration (EAI) is critical to the utility as a way to join together islands of data and fully leverage separate IT systems. Data and/or analysis from multiple systems are required for most end users. Although most industry experts agree that a single user interface accessing data and processes from enterprise systems is better than a user having to run multiple applications to perform a job function, a single EAI framework for integrating these systems has not emerged in the industry, nor have there been many successful utility implementations using this integration strategy.
In our opinion, there should be two main goals of EAI:
- Integration of enterprise systems and data should provide end users a more streamlined workflow for performing their job, using data from multiple systems in a single application GUI.
- Consistent interface standards, common information models, and messaging middleware should be considered when choosing the EAI framework.
Streamlining the user's workflow
The main reason EAI technology is necessary is because of the need to streamline a user’s workflow to increase productivity. This purpose of EAI is often overlooked because focus shifts to the complexity and expense of the interfaces needed to achieve this streamlined workflow. The picture below shows an example of EAI where a process may be streamlined from several applications with many interfaces to a single user interface for a field resource to perform his job.
Figure 1 - Streamlining Field Workflow
To that field user, a single workflow-oriented application is used to do his job. In reality, he is accessing and manipulating data from multiple systems with this streamlined application, which interfaces with these other enterprise systems. It is important to keep this goal of streamlining a user’s workflow at the forefront of system integration in order to achieve the desired paybacks.
EAI technology
Now that we’ve seen the goal, what technology is recommended to enable this integration? The classic example you see is to replace all point to point interfaces with a hub or message broker to handle all application to application interfaces.
]
Figure 2 - EAI using Middleware
With this approach, all interface messages are funneled through the hub, which is typically a middleware application responsible for message brokering. The message broker accepts messages from one system and then sends the message to the other system. The main advantage of using this technology is that it decouples applications that are interfacing with each other. Advantages of decoupling these applications include:
- Providing a standard mechanism for integrating applications across multiple hardware and operating system platforms
- Providing a standard message language so that applications need not know the programming languages supported by other applications.
- Ability to upgrade or replace software at one end without causing the other application to break (assuming that the new software understands the messages being sent by the broker)
- The technology for EAI is great (for the reasons listed above), but it is difficult to cost justify as a project by itself, especially when existing interfaces are working fine. One ideal time to evaluate such technology is when a new system is being implemented or going through a major technology change. During implementation of a new system, evaluate the interfaces necessary, and evaluate using EAI technology instead of point to point interfaces. Another time to evaluate EAI is when you are looking to streamline a particular workflow within your organization. Evaluate that workflow and all they systems/databases involved in the workflow. Using EAI technology can help you integrate these systems into a single streamlined workflow for the end user.
- Using EAI technology provides a loosely coupled interface. While this is fine for the interfaces between most applications, there are times when a more tightly coupled (point to point) interface may be appropriate. An example of such a case could include integration of a GIS application with an analysis package. If the desired workflow is for the engineer to invoke analysis directly from the GIS during design, then it may be more appropriate to incorporate objects from the analysis package in the GIS application. These tightly coupled interfaces are generally most appropriate when client applications need to talk to each other (instead of server applications).
- Not all applications need to talk to every other application. When implementing an application, evaluate other application(s) need interfaces (both now and in the future) before deciding whether integration using a message broker is appropriate.
Knoxville Utilities Board (KUB) is an independent agency of the City of Knoxville, Tennessee. KUB provides electricity, gas, water, and wastewater services to more than 180,000 customers in Knoxville and parts of seven surrounding counties in eastern Tennessee. These customers may have up to four of these services. Individual billable meters of the electric, gas and water services total more than 360,000.
KUB is actively challenging the increasing competition it sees in its core utility business. Its business strategy is to remain East Tennessee’s best choice for utility services by delivering better services at a better price. KUB plans to continue improving its customer satisfaction through the implementation Intergraph’s InService, which will provide an enterprise-wide system for Outage and Mobile WorkForce Management (OMS/WFMS). A key success factor for this project is the integration with external systems, such as the Customer Information System (CIS).
KUB is streamlining the process for several job functions, such as dispatchers, supervisors, and field resources. The EAI technology chosen by KUB was IBM’s MQSeries, now known as WebSphere MQ. Aside from the fact that WebSphere MQ is one of the leading middleware packages available, other advantages included support for multiple platforms, redundancy through clustered queues, and a fairly simple development environment.
Websphere MQ enables applications to communicate with each other by sending and receiving messages from queues. A queue manager on each machine manages the queues on that machine. Message channels provide communication from a queue manager on one machine to a queue manager on another machine. WebSphere MQ assures a one-time message delivery through time independent communication. This means that when sending a message from application A to application B, application A does not have to be concerned about whether application B is currently running. MQ Applications developed for the KUB project:
Intergraph provided productized interfaces to two queues. The first is called the MQ Connector. This connector receives messages from a queue when an external application wants to initiate an action within the InService Outage & Workforce Management System or query InService for job details. The second is a Status Writer, which writes messages to a queue when an external system should be notified of a job closure or crew status change.
KUB also provided interfaces to the same two queues. The first interface sends messages for creation or query of electric outage calls, other trouble jobs (gas, water, and wastewater), and service jobs (all utilities). The second interface receives messages of job closures or crew status updates from a queue for service requests (all utilities) and trouble events (gas, water, and wastewater). The High Volume Call Application vendor also wrote an application to send messages for electric outage calls to the queue.
Streamlined Customer Service Workflow
The following diagram shows the streamlined workflow for a customer calling to report an outage.
Figure 3 - Customer Service Outage Workflow
With this integrated system, the customer service representative (CSR) answers a call from a customer and uses the CIS to enter the trouble call information. The CIS application writes the request to the input queue. The InService MQ Connector reads that message, groups the trouble call with other related trouble calls, and sends a message back to the queue to report information about the outage. The CIS application picks up that message and displays the outage information so that the CSR can relay this information back to the customer. With this seamless workflow, the CSR is able to tell the customer information, such as whether their trouble is isolated or part of a bigger outage, what type of device is out, how many customers are affected, whether or not a crew has been dispatched, and the estimated repair time of the outage.
The next diagram shows how the queues connect across multiple systems on multiple platforms to achieve the desired workflow.
Figure 4 - KUB Queue Configuration
The CIS writes a simple message to the Inbound Queue. The messages are XML based using a published format. The MQ Connector then reads the message and takes appropriate action within InService (Create Job, Dispatch Crew, Query Job, etc.). The response from InService (Success, Bad Address, Query Results, etc.) is then written to the Response queue.
An example of one of the XML Based Messages is as follows: <CreateEvent>
msgid=”123”
area=”01”
fieldvalues=”LOCATION=1000 GROVE AVE
LAKE;EVNTTYPE=SCN”>
</CreateEvent>
Streamlined Field Application
At KUB, the application for the field user is also streamlined. A single application is used to for the crew to receive, update, and close all jobs. At KUB, many crews are qualified to do multiple types of jobs (trouble or planned, multi-utility). A single application is used, no matter what the job type and no matter what system generated the work. Data necessary to support the job is sent to InService, which manages the distribution to the InService mobile application. The following screenprint shows the user interface from the mobile application, where data from multiple systems may be displayed.
Figure 5 - Mobile form at KUB
When the crew completes the job, the system automatically notifies the CIS, where completion information is stored, and followup activity, such as billing, can occur. The following diagram shows the workflow used to make that notification.
Figure 6 - Streamlining the completion workflow
The following architecture is used to achieve this integration:
Figure 7 - KUB Queue Configuration for Status Writer
An example of one of the XML Based Messages is as follows:
<CloseEvent>
<event<A0001730</event>
<evnttype<COLL</evnttype>
<evsubtyp<</evsubtyp>
<date<08222002</date>
<time<075652</time>
<configid<3005</configid>
<amt_paid<90.50</amt_paid>
</CloseEvent>
Benefits
The EAI at KUB will improve productivity by streamlining user activities and uses industry standards, such as XML and message queuing. Some of the specific benefits to KUB include:
- Each side of the interface can be stopped independently, and messages in the queue are not lost.
- IT staff can concentrate on project requirements and areas of internal expertise
- Development cost is likely to be less
- Shielded from changes in CIS and OMS/WMFS applications during product upgrades and architecture changes.
Although no single EAI framework has emerged in the utility industry, utilities should consider leading middleware packages, such as IBM’s WebSphere MQ to provide standardized integration necessary to streamline workflows. When using this standard technology, overall IT costs can go down, and implementation teams can focus on project/user requirements necessary to gain efficiencies. Using this technology to integrate islands of data and IT systems that have been previously operating autonomously allows utilities to fully leverage these systems and data in order to maximize their benefits.
Trademarks
WebSphere, and MQSeries are registered trademarks of International Business Machines Corporation in the United States or other countries or both.