By Steven Baker
Modern business applications today are designed and implemented so they can be easily integrated with other applications within the enterprise. With the growth of networking, local intranets, and the World Wide Web, it has become important to be able to easily share information electronically between business processes. Consequently, the new paradigm for applications is essentially a collection of services and associated data that can readily be used by other applications.
However, many of the existing applications in use in an organization were not designed to plug into Enterprise Application Integration (EAI) architecture. Not long ago, each application was an island unto itself. Custom business applications were typically built as monolithic programs designed to solve a specific set of business problems. Packaged business applications, while having some configurable options, were also designed using similar models. These stovepipes, as they are often called, exist in most large organizations and reflect solutions purchased over time for specific problems. Even some of the largest packaged applications represent stovepipes of sorts that support rather limited ways to share information with other applications and processes. These applications may also reside on a variety of computer and operating systems.
Enterprise Application Integration is being promoted as a way to improve productivity and tie disparate applications together into a more cooperative whole. In the previous chapter, we discussed the integration of data as a natural choice for many tasks. Data integration can bypass the necessity of making intrusive and costly changes to the existing application logic, user interface, or data structures. But for many custom and packaged applications, data integration may not be appropriate as the point of integration. In some existing applications, the database metadata may be so complex or poorly documented that integration using the data would be difficult or impossible. Some packaged applications (SAP R/3, for example) function as application servers with integrated transaction processing, making it difficult to use data integration without affecting the reliability and transactional integrity of the data store.
Fortunately, many of these custom and packaged applications expose application programming interfaces (APIs) that can be used to access the business logic, processes, and data used by these programs. Leveraging these interfaces, enterprise planners and developers can bundle several separate applications into a more cooperative whole. The only limitations on using application integration are the specific interfaces and functions that a custom or packaged application exposes.
Organizations often need to share business information among their different applications. For example, information on company employees maintained by a human resources or personnel department includes employee wages, benefits, and other information needed by payroll and accounting software to write paychecks, properly withhold taxes, and issue forms required for compliance with the Internal Revenue Service.
A typical scenario in many large organizations regarding employee benefits is that an open enrollment period (typically the month of December) is available for employees to review and change their benefits. Employees receive handbooks that describe the medical, dental, life insurance, disability, and other benefits (401K plans, stock purchase options, etc.) to be offered in the following 12-month period. Employees also receive a paper form that must be submitted by the end of the open enrollment period with the benefits that they wish to select along with other needed information (dependents and insurance beneficiaries, for example). The information from this benefits enrollment form may be entered into some system maintained by the Human Resources department. A subset of this information must also be forwarded to the Payroll department to be entered by a data entry clerk into the payroll system. The scenario just described is the norm in many state government and university systems.
Now the goal is to automate existing business processes such as employee benefits enrollment to improve productivity, enhance employee satisfaction, and streamline the process. The scenario we will discuss in this chapter is based on automating the existing manual procedures described above for employee benefits enrollment with a Web-based self-service process using application integration. This EAI solution can easily include validation logic to check for problems and eliminate costly and error-prone manual data entry errors. The approach we will discuss for providing this integration uses Web-based middleware in conjunction with interfaces exposed by the payroll and benefits administration application as the point of integration.
Microsoft has developed several popular technologies that have become de facto standards used for Web-based middleware:
Microsoft offers a number of products and technologies that could potentially be used to implement an application integration solution. These products and technologies include the following:
This chapter will focus on how some of these Microsoft products and technologies can be used together to provide a low-cost application integration solution.
The chapter is divided into the following four sections: