![]() |
![]() |
|
|
Determining Integration Solution Requirements
An integration specialist must investigate the business and technical requirements for an integration solution. The integration specialist works collaboratively with business analysts and architects to clarify these requirements and to achieve a consensus on the organization's needs and priorities. Business analysts and architects provide the detailed requirements definitions that an integration specialist uses to design an integration solution architecture on WebLogic Integration.
With one exception, the following sections describe issues to consider when determining the requirements of an integration solution. The final section shows how these issues relate to the sample WebLogic Integration application.
Defining Integration Solutions and Business Processes
When determining integration solution requirements, the integration specialist must:
To see how these tasks apply to the sample WebLogic Integration application, see Specifying the Integration Solution and Business Processes.
Each business process should consist of a single process definition that describes the required business activities. Integration specialists, business analysts, and architects work together to define each business process. The integration specialist must ask questions such as the following:
To see how this task applies to the sample WebLogic Integration application, see Specifying the Integration Solution and Business Processes.
Defining Actors and Their Roles In Business Processes
Actors are people and processes that produce and consume business events. A business process defines the relationships among the actors, the roles of the actors in the process, and the business events that are exchanged by the process and the actors. The integration specialist identifies the actors and their roles, as described in the following sections:
To see how this task applies to the sample WebLogic Integration application, see Specifying Actors and Roles.
Analyzing Actors
For each business process, the integration specialist asks questions such as the following:
Analyzing Roles
To define the role of each entity in the business process, the integration specialist must answer questions such as the following:
Classifying Actors by Type
The integration specialist must identify and characterize the different types of actors involved in a business process. The actors in a business process include both humans, who use the WebLogic Integration Worklist and other client applications, and various software entities. The following sections describe several types of actors:
The following illustration shows these actors:
Figure 2-1 Actors in a Business Process
Human Users Human users fall into two categories:
The integration specialist must identify the type of client required by each user, such as a Swing GUI, HTML, e-mail client, and so on.
Application Integration—Enterprise Information Systems (EIS) Applications Used for Application Integration
The technical infrastructure of an organization can consist of a variety of enterprise information systems (EIS), including legacy mainframe systems, client-server applications, and packaged applications, such as ERP and CRM applications.
The integration specialist focuses on EIS applications that are directly involved in the integration solution, asking questions such as the following:
The integration specialist needs to identify the EIS applications that are involved in the business processes and for which the answer to these questions is yes.
In addition, the integration specialist must determine the following:
Examples of EIS Applications
Examples of EIS applications include:
Analyzing EIS Integration Requirements
The integration specialist evaluates application requirements, asking questions such as the following:
Determining Whether Additional Customization is Required
The EIS applications might not implement all the functionality required to support the integration solution and might therefore require internal customization. The integration specialist needs to determine whether this is needed and, if so, define the technical requirements.
Other Domains In the Enterprise
An integration solution might involve contact with other locally-administered domains in the enterprise, such as remote offices. In such situations, the internal mechanics of the other domain are beyond the control of the integration solution. Specifically, the other domain might or might not use WebLogic Integration as its integration solution.
The interface between the business process and other domains is the set of business events that flow between them. This interface must be defined.
One approach is to represent independent domains as trading partners within the enterprise, using B2B integration functionality to support the flow of information among them. For example, suppose an enterprise owns a factory in Malaysia that supplies parts to a wholly-owned assembly-line factory in Japan. Using B2B integration, the Malaysian office can act as a supplier ("seller") of components to the Japanese office, which acts as a buyer.
External Trading Partners Performing B2B Integration
An integration solution might involve external trading partners with which a business process needs to communicate. Such processes cross the enterprise firewall. For trading partner integration, the integration specialist must define:
Defining Business Events
The following sections describe how to define business events:
To see how this task applies to the sample WebLogic Integration application, see Specifying Business Events.
About Business Events
Business events are exchanges of messages or tasks that occur between actors during a business process. A business event indicates that a business activity has taken place and needs to be performed. For example, an EIS could publish a new customer created event, or an order management application could subscribe to new order events to process new orders. Each actor can exchange business events with the business process. Each business event should be given a descriptive name that uniquely identifies it in the business process.
Business events contain business data. For example, suppose a create new customer event occurs during the execution of a customer management application. In the process of creating a new customer, the application might receive the name and address of the customer name from another actor in the business process and return a number for the customer to that actor.
Defining Business Event Characteristics
For each interaction between an actor and the process, the integration specialist must define:
Defining the Message Format for Business Events
In WebLogic Integration, business events are sent as either XML or binary messages. The integration specialist must define:
Defining Business Data Flows
The business process defines the required flow of data between actors. From this flow, the integration specialist can determine how the business data needs to be manipulated. Perhaps, for example, the business data should be split into multiple events, concatenated from multiple events, or transformed from one data format to another.
This data flow should also define any business data that is used in the business process to make processing decisions. For example, if the business process includes an algorithm specifying that purchase orders over $5,000 must be approved by a vice president, then the amount of money in each purchase order should be defined as required business data.
The following sections describe the work of preparing data flow requirements:
To see how this task applies to the sample WebLogic Integration application, see Specifying Data Flow Requirements.
Defining Data Flow Requirements
For each data flow, the integration specialist needs to define the following requirements:
Analyzing the Data Flow
The integration specialist needs to analyze the technical aspects of the data flow, asking questions such as the following:
For example, suppose an order management application sends a new order event to a shipping application for processing. Suppose that a shipping application runs in three separate regional offices (eastern, central and western) as three separate instances. The order management application needs to notify the appropriate application instance based on the ship to address in the order. In addition, the order management application needs to notify the billing application of the new order.
In this scenario, the data flow requirements would be:
Defining the Quality of Service
The integration specialist must define the following Quality of Service characteristics in business and technical terms. The following sections describe these characteristics:
Performance
The integration specialist must answer questions such as the following:
For example, an integration specialist might specify that the system must be capable of handling 20,000 orders per business day (between 9am and 5pm) with a maximum load of 5,000 orders at any one time.
For more information about WebLogic Integration performance, see Performance Considerations in Integration Design. To meet performance requirements, high-volume integration solutions might require a clustered configuration. For more information about clustering, see Configuring WebLogic Integration Clusters in Deploying BEA WebLogic Integration.
Availability and Reliability
The integration specialist must define the availability requirements for the business process, asking questions such as the following:
Some systems might require 24x7 availability with instant failover, while others might require availability only during the business day with scheduled maintenance on evenings or weekends. To meet reliability requirements, high-availability integration solutions require a clustered configuration, which is described in Configuring WebLogic Integration Clusters in Deploying BEA WebLogic Integration.
Response Times
The integration specialist must define the response time requirements for the business process. For example, suppliers might need to respond to a bid request within 24 hours, or suppliers might need to be notified within 60 minutes of the bid award. An event might time out if the response time limit has elapsed.
Security
The integration specialist must define the security requirements for the business process, asking questions such as the following:
Scalability
The integration specialist must define the scalability requirements for the business process, based on the current volume of work and the projected volume in the future. For example, an order-processing integration solution might need to be able to handle triple, within two months, the volume of orders it can handle, without interruption to service or additional application development. To meet scalability requirements, integration solutions can use a clustered configuration, which is described in Configuring WebLogic Integration Clusters in Deploying BEA WebLogic Integration.
Logging and Nonrepudiation
The integration specialist must define the system logging requirements for the business process, asking questions such as the following:
Nonrepudiation is the ability of a trading partner to prove or disprove having previously sent or received a particular business message to or from another trading partner. Nonrepudiation of origin and nonrepudiation of receipt might be required by law for critical business messages.
Defining the Integration Solution Topology
The integration specialist must define the integration topology that specifies the physical location of the various entities in the integration environment. This topology should include information about the types of network connections among the participants, including LAN, WAN, Internet, dial-up, and so on.
The integration specialist must ask whether all the constituent entities in an integration solution will be located:
Specifying Requirements for the Sample WebLogic Integration Application
The following sections explain how the requirements are defined for the sample WebLogic Integration application:
Specifying the Integration Solution and Business Processes
In the sample WebLogic Integration application, General Control Systems (GCS) defines a single integration solution, purchasing integration, to better manage the value chain with its suppliers. Their analysis reveals that they need to define integration requirements for two business processes:
These two business processes are connected: after GCS selects the supplier, it issues the purchase order for that supplier. These processes are triggered when anticipated or actual sales drive the need to manufacture more EnergyMiser 76 products. Increased manufacturing, in turn, drives the need to obtain more parts.
Characteristics for these business processes are not defined in the sample scenario, but analysis is recommended for factors such as:
Steps for Querying Price-and-Availability
The business process for selecting a supplier involves the following steps:
Steps for Issuing a Purchase Order
The business process for issuing a purchase order to the selected supplier involves the following steps:
Specifying Actors and Roles
In the sample WebLogic Integration application, both business processes involve trading partners acting in the buyer and supplier (seller) roles. In addition, the purchase order business process includes integration with an EIS.
Types of Actors
The GCS scenario involves human and software actors:
Actors and Roles for Selecting a Supplier
GCS plays the role of a buyer that:
Each supplier plays the role of a potential seller that:
Actors and Roles for Issuing a Purchase Order
GCS plays the role of the buyer that:
The GCS ERP system plays the role of information manager for the purchase order. It handles the creation of the purchase order and receipt of the acknowledgment from the supplier.
The selected supplier plays the role of seller that involves the following tasks:
Specifying Business Events
In the sample WebLogic Integration application, business events are associated with both business processes.
Events in the Supplier Selection Process
The supplier selection process includes the following events:
Events in the Purchase Order Process
The purchase order process includes the following events:
Specifying Data Flow Requirements
The sample WebLogic Integration application includes the following key data flows:
Certain information about these data flows—anticipated volume of data, peaks and lulls, seasonal patterns, and so on—is not defined in the sample WebLogic Integration application.
List of Requirements
These data flows have the following requirements:
Note: Transaction rollbacks for these conditions are currently not implemented in the sample WebLogic Integration application.
Data Flows in the Price-and-Availability Request Process
The price-and-availability request data flow contains the following information:
The price-and-availability response data flow contains the following information:
The aggregated response data flow contains all the information in the price-and-availability response, but the information is collected under a common request identifier and date of request.
Data Flows in the Purchase Order Process
The purchase order request data flow contains the following information:
The purchase order data flow contains the following information:
The purchase order confirmation data flow contains all the information in the purchase order, plus the sales order number and the date of the sales order.
Specifying the Quality of Service
The sample WebLogic Integration application includes Quality of Service (QoS) requirements for the following:
Performance
While the scenario for the sample WebLogic Integration application does not include performance requirements, transaction volumes, or peak loads, we can assume that GCS needs the integration solution to provide acceptable performance at all times, regardless of the number of queries for price-and-availability sent and the number of supplier responses received.
Availability and Reliability
While there are no availability and reliability requirements for the sample WebLogic Integration application, we can safely assume that the integration solution must:
Response Times
While the sample scenario does not indicate response time requirements, we can assume that when a new purchase order is created in the ERP application, the purchase order confirmation request must be sent out almost immediately (for example, within 10 seconds).
Security
GCS has the following security requirements:
Scalability
Using WebLogic Integration in a clustered environment, GCS can scale its systems so that they handle a large number of suppliers and a substantially increased volume of bid solicitations and purchase orders.
Logging and Nonrepudiation
Purchase orders and purchase order confirmations must conform to the standards of nonrepudiation because they represent legal contracts between buyers and sellers.
Specifying the Integration Topology
Both business processes in the sample WebLogic Integration application involve communication between GCS and its trading partners across the GCS firewall. In addition, behind the GCS firewall, integration with the ERP system requires that the integration solution has network access to the ERP system.
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|