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

• Defining Actors and Their Roles In Business Processes

• Defining Business Events

• Defining Business Data Flows

• Defining the Quality of Service

• Defining the Integration Solution Topology

• Specifying Requirements for the Sample WebLogic Integration Application

 

---

Defining Integration Solutions and Business Processes

When determining integration solution requirements, the integration specialist must:

• Clarify the scope of the integration solution and then divide the work into a collection of smaller, discrete units of work. An integration solution consists of one or more related business processes, as described in Integration Solutions.

• Identify the business processes that are candidates for an integration solution. A business process is a set of interconnected business activities with a beginning and an end, and clearly defined inputs and outputs, as described in Business Processes.

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:

• What work must be done for each business process?

• What are the principal activities for each business process?

• What are the characteristics for each business process or component?

  • Sequence or order (in relation to other tasks and activities)

  • Frequency of occurrence

  • Urgency and timeliness

  • Duration or elapsed time

  • Volume range, including average volume, peaks, and lulls

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:

• Analyzing Actors

• Analyzing Roles

• Classifying Actors by Type

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:

• What are the actors of each business process? Who are the players? Do they include, for example, other departments within a company, vendors, customers, systems, and Web users?

• What is the geographic topology of these entities? Are they all located at one site, or are they distributed across other locations? Which entities are located at which site?

• How is data transported between actors?

  • At a single location (within a LAN or domain)?

  • Across a WAN to other locations within the same organization?

  • Outside the WAN to actors beyond a firewall?

• What is the format of the events flowing in and out of each entity in each business process?

Analyzing Roles

To define the role of each entity in the business process, the integration specialist must answer questions such as the following:

• What roles are involved in the business process?

• What is the sequence in which the work of each role is performed?

• How does the work of each role fit into the overall business process? Specifically, does the player of a given role:

  • Initiate the process?

  • Provide a service to the process?

  • Consume business events generated by the process without returning a response?

  • Review, approve, reject, or otherwise make a decision along the way?

• How many people and processes are associated with each role?

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:

• Human Users

• Application Integration—Enterprise Information Systems (EIS) Applications Used for Application Integration

• Other Domains In the Enterprise

• External Trading Partners Performing B2B Integration

The following illustration shows these actors:

Figure 2-1 Actors in a Business Process

 

Human Users

Human users fall into two categories:

• Worklist users are assigned work directly by the business process. For example, a manager using the Worklist might be assigned the task of approving all orders over $100,000. Users can be grouped by role. Tasks can be assigned either to individual users or to users associated with a role. Users who are assigned tasks in this way work closely with a business process.

• Client users interact with a business process indirectly, by using applications that are part of the process. For example, this type of user might initiate a create order process from a Web-based GUI and expect to receive confirmation of an order via e-mail.

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:

• Will the integration solution have a direct connection to the EIS?

• Can the EIS be customized to support the integration?

• Will the EIS and the business process exchange events?

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:

• For each EIS application, the business functionality that it provides (such as purchase order management, inventory management, and so on)

• For each EIS application that participates in the business process, the application details and interfacing technology that will be used

Examples of EIS Applications

Examples of EIS applications include:

• Packaged applications (including e-mail)

• Custom applications (WebLogic Server and nonWebLogic Server applications)

• Applications that use middleware technologies (such as CORBA or MQSeries)

• Applications with queue-based interfaces (such as MQSeries)

• Technology adapters (file or database adapters)

Analyzing EIS Integration Requirements

The integration specialist evaluates application requirements, asking questions such as the following:

• What are the name and version of the EIS?

• On which platform(s) does it run?

• What interfacing technology does the EIS offer? Does the EIS offer an API? Does the EIS have a file-based interface? Does the EIS use a middleware-based interface?

• Do the EIS internal business processes that will be involved in the integration mandate the use of a particular EIS interface?

• What is the format of the data passed by the interface (binary, XML, other)? Is metadata (data that describes the data) available, or does this metadata need to be created by hand?

• For each business event that is exchanged between the business process and the EIS application, what is the EIS interface (API, event, database table, and so on) that will be used?

• What are the human and application interfaces?

• What are the mappings between interfaces?

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:

• What is the nature of the B2B integration?

  • Is it a value-chain integration? If so, is it a supply-chain integration (where the trading partners are suppliers to the enterprise), a demand-chain integration (where the trading partners are customers to the enterprise), or a combination of both?

  • Is it a B2B exchange that can enlist trading partners for B2B transactions?

• Are there mandated protocols that must be included in the integration solution (XOCP, RosettaNet, cXML, or EDI)?

 

---

Defining Business Events

The following sections describe how to define business events:

• About Business Events

• Defining Business Event Characteristics

• Defining the Message Format for Business Events

• Specifying 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:

• Business events that can be sent and received

• Any unique characteristics of elements in the business events

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:

• Business event format (XML or binary) and metadata. A common format (such as XML) is used whenever possible. For application integration with EISs, the adapter converts proprietary EIS protocols or message formats to the common format.

• Any information in the event that may be used for controlling decisions (such as conditional processing, routing, triggering, and so on)

 

---

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:

• Defining Data Flow Requirements

• Analyzing the Data Flow

• Specifying 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:

• Conditional data—data that is required to make processing decisions. This data is extracted from business events.

• Business or application rules—processing rules that are applied to the conditional data to determine the run-time execution path of the process.

• Mappings—data transformations between the business events used as input and those used as output.

• Business transactions—transactional boundaries in the process. A single process might contain many business transactions. In addition, for each business transaction, the integration specialist needs to define any compensating actions that must be performed if a transaction needs to be rolled back.

• Error handling—what exceptions can occur and how they should be handled.

Analyzing the Data Flow

The integration specialist needs to analyze the technical aspects of the data flow, asking questions such as the following:

• What are the characteristics of each data element?

• What are the characteristics of messages?

  • Message size, specified in terms of minimum, maximum, and average size

  • Message volume, specified in the number of messages at peak, lull, and average volumes, plus any cyclical patterns

  • Single or batched (aggregated) message. If messages are aggregated, do they need to be split up and routed appropriately? If so, what are the routing criteria or conditions?

• What data transformations are needed between the source data and target data?

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:

• Three business events:

  • New order event from the order management application

  • Ship goods event to the shipping application

  • Send invoice event to the billing application

• Conditional data—the state to which the order will be shipped. This information is extracted from the billing address in the new order event.

• Business rules—the rule used to identify the shipping application instance to receive the ship goods event, which is based on the ship to state/province in the order and the list of states/provinces associated with each application instance.

• Mappings—the data transformation mappings from:

  • New order event to the ship goods event

  • New order event to the send invoice event

• Business transaction—Either both the shipping and billing applications are updated successfully, or neither is updated. Compensating actions for rolling back each application if the other fails must be defined.

• Error handling—if a data error occurs, such as an order is received with an invalid state/province

 

---

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

• Availability and Reliability

• Response Times

• Security

• Scalability

• Logging and Nonrepudiation

Performance

The integration specialist must answer questions such as the following:

• How quickly, in business terms, must the business process be carried out?

• What are peak and off-peak performance requirements?

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:

• When must systems be available? Are they needed 24 hours a day, 7 days a week (24x7)?

• What are the planned and anticipated periods of scheduled and unscheduled system downtime, respectively?

• What is the maximum allowable downtime?

• What failover and recovery protections are required in case a hardware or network failure occurs?

• Do business messages need to be persisted while in transit and recovered upon a system restart?

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:

• How sensitive is the information in the business process?

• What are the privacy needs associated with each role?

• What security safeguards are currently in place?

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:

• What kinds of problems can arise?

• What information needs to be logged and monitored?

• For integration solutions that use B2B integration, what information needs to be logged and maintained for audit or nonrepudiation purposes?

  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:

• At a single physical site (a LAN with a single domain)?

• At different sites that are connected via a WAN behind a firewall?

• At different sites for various trading partners, separated by firewalls?

 

---

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

• Specifying Actors and Roles

• Specifying Business Events

• Specifying Data Flow Requirements

• Specifying the Quality of Service

• Specifying the Integration Topology

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:

• Soliciting bids from suppliers (that is, querying suppliers for item price-and-availability) and awarding the order to the supplier with the best bid

• Issuing a purchase order to the selected supplier and receiving a sales order confirmation

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:

• Frequency of ordering parts (individual parts and all parts)

• Turnaround time for selecting suppliers

• Total number of purchase orders issued

• Seasonal fluctuations in order volumes, if any

Steps for Querying Price-and-Availability

The business process for selecting a supplier involves the following steps:

1. The buyer issues a request to potential suppliers for price-and-availability on a specific item.

2. Suppliers answer the request by providing price-and-availability information to the buyer.

3. The buyer gathers the suppliers' responses and presents them to the ordering manager.

4. The ordering manager reviews the responses and selects a supplier.

Steps for Issuing a Purchase Order

The business process for issuing a purchase order to the selected supplier involves the following steps:

1. The ordering manager issues the purchase order and notifies the selected supplier.

2. The purchase order is automatically entered into the company's enterprise resource planning (ERP) system.

3. The selected supplier returns a purchase order acknowledgment to the buyer.

4. The purchase order record is automatically updated with information from the purchase order acknowledgment (the supplier's sales order number).

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:

• Human actors:

  • the GCS purchasing agent who issues the request for item pricing and availability to suppliers

  • the supplier salesperson who responds to the request with item pricing and availability information

  • the GCS purchasing manager who selects the supplier and ends the process

• Software actor: ERP system, an Enterprise Information System (EIS) that manages the purchase order information

Actors and Roles for Selecting a Supplier

GCS plays the role of a buyer that:

• Initiates the request for pricing and availability information

• Reviews responses received from suppliers

• Selects the supplier to end the process

Each supplier plays the role of a potential seller that:

• Receives the request from the buyer

• Determines pricing and availability for the requested item

• Sends that information to the buyer

Actors and Roles for Issuing a Purchase Order

GCS plays the role of the buyer that:

• Notifies the selected supplier

• Issues the purchase order

• Enters the purchase order into the purchase order module of the ERP system

• Receives confirmation from the supplier

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:

• Receives the purchase order acknowledgment request from the buyer

• Provides the purchase order confirmation and supplemental information (such as the supplier's sales order number) to the buyer

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:

• Buyer requests price-and-availability from sellers.

• Sellers send price-and-availability response to the buyer.

• Buyer aggregates seller responses and selects a seller.

Events in the Purchase Order Process

The purchase order process includes the following events:

• Buyer requests a new purchase order.

• Buyer requests a purchase order acknowledgment from the selected seller.

• Seller sends acknowledgment to the buyer.

Specifying Data Flow Requirements

The sample WebLogic Integration application includes the following key data flows:

• Price-and-availability request

• Price-and-availability response

• Aggregated response

• Purchase order request

• Purchase order

• Purchase order acknowledgment

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:

• Business events—see Specifying Business Events.

• Conditional data

  • The list of suppliers to which the buyer sends the price-and-availability request.

  • The supplier that the buyer selects and for which the buyer issues a purchase order.

• Business rules—Rule governing the selection of a supplier, based on a comparison of the price-and-availability responses received from all supplier candidates.

• Mappings—Process of transforming data:

  • Purchase order request must be mapped from the ordering manager to the ERP system

  • Purchase order acknowledgment must be mapped from the selected seller to the ERP system

• Business transactions

  • If no responses are received from suppliers within the specified time frame, then the entire request-for-price-and-availability transaction could be rolled back.

  • If a purchase order confirmation is not received from the selected seller, then the entire purchase-order transaction could be rolled back.

  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:

• Unique request identifier, and date and time of the request

• Item information (unique part ID, quantity requested, date and time required, and desired unit price)

• Desired location of the shipping origin

• Any supplemental notes or instructions

The price-and-availability response data flow contains the following information:

• Unique response identifier, and the date and time of the response

• Associated request identifier

• Supplier information

• Item information (unique part ID, available quantity, available date, unit price)

• Location of the shipping origin

• Any supplemental notes or instructions

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:

• Supplier name

• Quote identifier

• Item information (part number, quantity, unit price, delivery quantity, delivery date)

The purchase order data flow contains the following information:

• Purchase order header (purchase order number, issue date, status, buyer contact information, supplier information, billing information, shipping information, financial information, and total amount)

• Purchase order detail (line number, part number, part description, quantity, unit price, delivery date, and notes)

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

• Availability and Reliability

• Response Times

• Security

• Scalability

• Logging and Nonrepudiation

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:

• Stay up during business hours (8am to 6pm)

• Remain available after business hours for offline processing

• Persist price-and-availability requests and purchase orders, and process them after a system restart whenever a system outage occurs

• Restart within a maximum downtime (such as two hours)

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:

• Price-and-availability requests should be sent to authorized or approved suppliers only.

• Price-and-availability responses from suppliers are confidential. Suppliers should not know anything about competitors' bids.

• The ERP system has its own security mechanism in place to ensure data integrity and prevent unauthorized access. Any integration must have sufficient access rights to create and update a purchase order in the ERP system.

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.