How to Use the AIA Development Guide Introduction to Project Lifecycle Workbench

1-2 Developers Guide for Oracle Application Integration Architecture Foundation Pack

1.3 Integration Styles Addressed by AIA

AIA provides reference architecture for a variety of situations. Depending on the size and complexity of integration projects, the integration style adopted for implementing integration flows varies. The number of participating applications and their role in integration flows contribute to the integration style adopted. The integration flow as shown in Figure 1–1 represents the journey of a message from a business event triggering source to one or more target milestones, after passing through possible intermediary milestones. At each milestone, the message is stored in a different state. Figure 1–1 Illustration of the Integration Flow The integration flow represents the run-time path of a message. It is not a design time artifact. AIA addresses the following integration styles: ■ Integration Through Native Application Interfaces Using the Oracle Applications Technology Infrastructure ■ Integration styles with integration framework – Direct Integration Through Application Web Services Using Oracle SOA Suite – Integration Through Packaged Canonical and Standardized Interfaces Using Oracle Foundation Pack ■ Integration styles for bulk data processing – Real-time data integration flow – Batch data integration flow

1.4 How to Use the AIA Development Guide

The sales process provides detailed information about the value of AIA offerings. The value presented is perceived in the context of a business problem for which a solution is being sought. Getting Started with the AIA Development Guide 1-3 The detailed analysis of the business problem and documenting of related business requirements leads to a Functional Design Document FDD, which provides: ■ A detailed description of the business case ■ Various use cases detailing the various usage scenarios including the exception cases with expected actions by various actors ■ Details about all the participating applications - commercial, off-the-shelf with versions and homegrown ■ Details about the triggering business events ■ Details about the functional flow ■ Details about business objects to be used ■ Actions to be performed on the various business objects ■ Details about performance and scalability requirements The AIA Development Guide assumes: ■ A Functional Design Document is available ■ Access to AIA software ■ Access to all AIA-provided documents ■ You have read the AIA Concepts and Technologies Guide The AIA Development Guide is logically divided as follows: ■ Overview of all tasks for building the AIA integration flow ■ Details of development of various AIA artifacts ■ Activities around interaction between AIA artifacts and external artifacts ■ Discussion of various design patterns, best practices, and tuning for run-time performance Start with Chapter 20, Building AIA Integration Flows and move to relevant chapters in the Development Guide as needed. 1-4 Developers Guide for Oracle Application Integration Architecture Foundation Pack 2 Working with Project Lifecycle Workbench 2-1 2 Working with Project Lifecycle Workbench This chapter includes the following sections: ■ Section 2.1, Introduction to Project Lifecycle Workbench ■ Section 2.2, Adding Project Lifecycle Workbench Lookup Values ■ Section 2.3, Working with Project Lifecycle Workbench Projects ■ Section 2.4, Working with Project Lifecycle Workbench Service Solution Components

2.1 Introduction to Project Lifecycle Workbench

As a part of the Oracle Application Integration Architecture AIA development methodology and lifecycle, functional designs are created to specify requirements and functionality that need to be implemented for an integration project. Users, such as solution architects and functional product managers, can use Project Lifecycle Workbench to perform functional decompositions to break down overall projects into business tasks, each of which will be implemented by a collection of composites and services, as shown in Figure 2–1 . Figure 2–1 Functional Decomposition of a Project into Actual Implemented Services Project Lifecycle Workbench complements any existing design and analysis process with its various modeling and functional analysis mechanisms. The functional decomposition, the final output of the design and analysis process, is captured and persisted in Project Lifecycle Workbench. The primary building blocks that enable functional decomposition in Project Lifecycle Workbench are: 2-2 Developers Guide for Oracle Application Integration Architecture Foundation Pack ■ Project A project is a named effort to deliver a solution conforming to the AIA methodology and guidelines. The components of a project must be packaged and deployed on a middleware solution. ■ Business Task A business task represents a reusable unit of work that is arrived at based on analysis of reference process models. These could be business processes, business activities, or business tasks and are loosely added to a project in the Project Lifecycle Workbench as business tasks. ■ Service Solution Component A service solution component is a chunk of functionality within the scope of a business task that is implemented as an AIA service artifact. For example, a service solution component corresponds to an Application Business Connector Service ABCS, Enterprise Business Service EBS, or Enterprise Business Flow EBF. A service solution component conveys the functionality that the AIA service artifact needs to fulfill. For more information about the overall Oracle AIA Project Lifecycle, see Chapter 20, Building AIA Integration Flows.

2.2 Adding Project Lifecycle Workbench Lookup Values