2 Building AIA Integration Flows

This chapter introduces AIA integration flows and describes how to set up development and test environments. It discusses the role of the AIA Project Lifecycle Workbench and provides an overview of choosing of integration styles and AIA patterns. Finally, it provides a high-level overview of the development tasks for AIA artifacts and how to test integration flow.

Note:

Composite Business Processes (CBP) will be deprecated from next release. Oracle advises you to use BPM for modeling human/system interactions.

This chapter includes the following sections:

2.1 How to Set Up Development and Test Environments

For AIA development and testing, the setup of development and test environments consists of the following activities:

2.1.1 How to Set Up JDeveloper for AIA Development

Task 1   Set up JDeveloper for AIA development
  1. Download and install JDeveloper 11.1.1.9 or above from http://www.oracle.com/technetwork/developer-tools/jdev/downloads/jdeveloper11117-1917330.html.

  2. Install the SOA Composite Editor, AIA Code Compliance Inspector, and AIA Service Constructor JDeveloper extensions from the JDeveloper Update Center.

    1. In JDeveloper, navigate to Help > Check for Updates. The Welcome screen displays. Click Next.

    2. The Source screen displays. Select Search Update Centers. Select Oracle Fusion Middleware Products. Click Next.

    3. The Updates screen displays. Select AIA Service Constructor, Integration Code Compliance Inspector, and Oracle SOA Composite Editor. Click Next.

    4. The Updates screen displays the progress of the extension downloads. Once the downloads are complete, the Summary screen displays a confirmation of the extensions you have downloaded. Click Finish.

    5. You will be prompted to restart JDeveloper to complete installation of the extensions. Click Yes. Upon restart, installation of your extensions is complete.

    Note:

    Alternatively, you can download extensions directly from http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/156082.xml and use the Install From Local File option on the Source screen to install them.
  3. If you installed the AIA Service Constructor extension, download FreeMarker 2.3.16 or later. This tool is required by the AIA Service Constructor extension.

    1. Download the FreeMarker template engine from http://www.freemarker.org.

    2. Extract freemarker.jar from the downloaded tar.gz file and place it in your /jdeveloper/jdev/lib folder.

For more information about using Code Compliance Inspector, see Using the Code Compliance Inspector in Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack.

For more information about using Service Constructor, see Chapter 4, "Working with Service Constructor."

Task 2   Create a connection to the SOA Suite server
  1. Create a connection to the SOA Suite server set up for AIA Development and test using these details after Oracle Fusion Middleware is set up.

    For more information, see Section 2.1.2, "How to Set Up the Oracle Fusion Middleware Environment for AIA Development."

    1. Connection name: <give a connection name for your application>.

    2. Connection Type: use the default value - WebLogic 10.3.

    3. Provide the username and password of your WebLogic server.

      WebLogic Host name: <your server host name>.

    4. Port: <your server port number>.

    5. SSl port: <your server ssl port>.

    6. WLS Domain: <provide your domain name where SOA server is installed>.

Task 3   Create the database connection for SOA-MDS connection.

Create a connection to SOA MDS set up after Oracle Fusion Middleware is set up.

For more information, see Section 2.1.2, "How to Set Up the Oracle Fusion Middleware Environment for AIA Development."

  1. From the Resource Palette, click New.

  2. Select the New Connections and then select a Database.

  3. Create a database connection using MDS DB credentials. Contact your administrator for details.

Task 4   Create the SOA-MDS connection
  1. From the Resource Palette, click New.

  2. Select the New Connections and then select SOA-MDS.

  3. Provide a connection name and select connection type as DB based MDS.

  4. Select the DB connection you created in the previous step.

  5. Select the MDS partition as SOA-Infra and Save.

Task 5   Set up the Harvester utility
  1. Download AIAHarvester.zip from $AIA_HOME/ Infrastructure/LifeCycle.

  2. Unzip to a local folder. Use this to harvest the composites.

For more information about harvesting AIA content, see Chapter 5, "Harvesting Oracle AIA Content."

2.1.2 How to Set Up the Oracle Fusion Middleware Environment for AIA Development

The Oracle Fusion Middleware components used in the development environment depend on the topology of the development environment:

2.1.2.1 Set Up Oracle SOA Suite

  1. Download Oracle SOA Suite 11.1.1.9 and install from http://www.oracle.com/technology/products/soa/soasuite/collateral/downloads.html.

  2. Deploy AIA Foundation Pack artifacts from AIA Workstation.

    For more information, see Section 2.1.3.17, "How to Deploy AIA Foundation Pack Artifacts to Oracle SOA Suite Server."

2.1.2.2 Set Up Oracle Enterprise Repository

  1. Download Oracle Enterprise Repository and install from http://www.oracle.com/technetwork/middleware/repository/downloads/index.html.

  2. Import AIA SOA portfolio Oracle Enterprise Repository Solution Pack.

    For more information, see Chapter 12, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."

2.1.2.3 Set Up Oracle Service Registry

Download Oracle Service Registry and install from http://www.oracle.com/technetwork/middleware/registry/downloads/index.html.

2.1.2.4 Set Up Oracle Business Process Publisher

Oracle Business Process Publisher is installed as part of the AIA Foundation Pack install.

2.1.3 How to Set Up AIA Workstation

AIA Workstation is a dedicated system set up to drive AIA development. Install the AIA Foundation Pack on this system and set up the AIA Project Lifecycle Workbench from the AIA Foundation Pack.

This section includes the following topics:

2.1.3.1 Prerequisites

  • Install 11g WebLogic Server with Oracle Application Development Framework.

  • Install 11g Database.

  • Install JDeveloper.

Hardware should be at least 2 CPU and 4 GB of RAM with a supported Operating System.

2.1.3.2 How to Install AIA Foundation Pack

To install AIA Foundation Pack:

  1. Install the AIA Foundation Pack

    For more information, see "Installing and Deploying Using AIA Foundation Pack Installer" in Oracle Fusion Middleware Installation and Upgrade Guide for Oracle Application Integration Architecture Foundation Pack.

  2. Select the Copy AIA Software option.

  3. The system creates $AIA_HOME and copies all the software to it.

    When new artifacts are created as a part of development, copy them to a relevant folder in $AIA_HOME. If a separate source control is maintained for development, then content from the builds generated is expected to be copied to $AIA_HOME.

    This enables content to take advantage of the features provided in AIA Project Lifecycle Workbench.

2.1.3.3 Updating SOA MDS with AIA MetaData

The content under $AIA_HOME/AIAMetaData provided as part of AIA Foundation Pack is uploaded to SOA-MDS. This content includes all the schemas, WSDLs, XSLs, domain value map (DVM) and Cross Reference meta information, default fault policies, AIAConfigurationProperties.xml, and AIAEHNotification.xml.

Note:

After any extensions or customizations on the artifacts in $AIA_HOME/AIAMetaData, copy back and upload the artifacts to SOA-MDS > apps/AIAMetaData.

When new artifacts similar to the ones in $AIA_HOME/AIAMetaData, are created as part of development, copy them to a relevant folder in $AIA_HOME/AIAMetaData to facilitate their upload to SOA-MDS > apps/AIAMetaData.

If a separate source control is maintained for all development, the content from the builds generated are expected to be copied to $AIA_HOME/AIAMetaData to facilitate uploading to SOA-MDS > apps/AIAMetaData.

2.1.3.4 Using MDS in AIA

Oracle Metadata Services (MDS) repository contains metadata for deployed J2EE applications, including SOA Suite on WLS.

Under a partition SOA-MDS created specifically for SOA, all SOA Composites (including AIA composites) are also stored upon deployment.

Under the same partition, the contents of $AIA_HOME/AIAMetaData are uploaded to SOA-MDS > apps/AIAMetaData.

The content and details of each set of metadata and how it is used by AIA is provided below. Also described is the process of creating new content or changing existing content.

Uploading the $AIA_HOME/AIAMetaData content to MDS is also described in Section 2.1.3.15, "Updating MDS."

2.1.3.5 Content of $AIA_HOME/AIAMetaData

AIA MetaData ($AIA_HOME/AIAMetaData) includes the following content:

AIAComponents - Presents the various schemas and WSDLs referred to by various services. The structure is as follows:

  • ApplicationConnectorServiceLibrary: Abstract WSDLs of various Application Business Connector Services (ABCSs)

  • ApplicationObjectLibrary: WSDLs of services exposed by applications and schemas of application business objects

  • B2BObjectLibrary: Business-to-business (B2B) schemas

  • B2BServiceLibrary: Abstract WSDLs of various B2B Connector Services (B2BCSs) and B2B Infrastructure Services

  • BusinessProcessServiceLibrary: Abstract WSDLs of Enterprise Business Flows (EBFs)

  • EnterpriseBusinessServiceLibrary: Abstract WSDLs of Enterprise Business Services (EBSs)

  • EnterpriseObjectLibrary: Schemas of the Oracle AIA Canonical Model

  • ExtensionServiceLibrary: Concrete WSDLs pointing to mirror servlet

  • InfrastructureServiceLibrary: Abstract WSDLs of infrastructure services

  • Transformations: XSLs shared among various services

  • UtilityArtifacts: Utility schemas and WSDLs

config: AIAConfigurationProperties.xml and AIAEHNotification.xml

dvm: Domain Value Maps

faultPolicies: Default policies applicable to all the services

xref: Metadata for Cross References

2.1.3.6 Working with AIA Components Content in $AIA_HOME/AIAMetaData

The AIA Components consist of Schemas, WSDLs, and XSLs shared among various AIA artifacts at runtime. Usage and purpose of each of these files is dealt with in detail in AIA artifact-specific chapters of this guide.

AIA Components Folder Structure

All the abstract WSDLs of various application connector services and adapter services are stored here. The folder structure convention followed is: ApplicationConnectorServiceLibrary.

AIAMetaData\AIAComponents\ApplicationConnectorServiceLibrary\<Application Name>\<Version Number>\<Service Type>

  • Possible values for <Version Number> are V1, V2, and so on.

  • Possible values for <Service Type> are:

    • RequesterABCS

    • ProviderABCS

    • AdapterServices

  • Possible values for <Application Name> are:

    • PeopleSoft

    • BRM

    • UCM

    • SAP

    • PIM

    • OracleRetail

    • Logistics

    • JDEE1

    • CRMOD

    • Agile

    • Ebiz

    • Siebel

Note:

The <Application Name> specified here is used in AIA Project Lifecycle Workbench in the definition of the bill of materials for deployment. It should match the <productCode> list of values in the Workbench.

Examples:

AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/RequestorABCS

AIAMetaData/AIAComponents/ApplicationConnectorServiceLibrary/Siebel/V1/ProviderABCS

ApplicationObjectLibrary

All the WSDLs of the services exposed by the participating applications and the referenced schemas are stored in:

$AIA_HOME/AIAMetaData/AIAComponents/ApplicationObjectLibrary

Applications consume AIA requester service WSDLs. To avoid any need for transformation in the participating applications, the AIA requester services' WSDLs are developed referencing the external facing business object schemas of the participating applications. These schemas are also stored in:

$AIA_HOME/AIAMetaData/AIAComponents/ApplicationObjectLibrary.

The folder structure convention followed is:

ApplicationObjectLibrary/<Application Name>/<Version Number>/schemas

ApplicationObjectLibrary/<Application Name>/<Version Number>/wsdls

The possible values for <Application Name> and <Version Number> are as described in the previous section.

Note:

The <Application Name> specified here is used in AIA Project Lifecycle Workbench in the definition of the bill of materials for deployment.

Examples:

AIAMetaData/AIAComponents/ApplicationObjectLibrary/Siebel/V1/schemas

AIAMetaData/AIAComponents/ApplicationObjectLibrary/Siebel/V1/wsdls

B2BServiceLibrary

All of the abstract WSDLs of B2B Connector Services (B2BCSs) are stored in this location.

Requester B2BCS WSDLs are stored under $AIA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdls.

The folder structure convention followed is: B2BServiceLibrary/Connectors/wsdls/<B2BStandard>/RequesterB2BCS/<ConnectorVersion>/*.wsdl.

Provider B2BCS WSDLs are stored under $AIA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Connectors/wsdls.

The folder structure convention followed is: B2BServiceLibrary/Connectors/wsdls/<B2BStandard>/ProviderB2BCS/<ConnectorVersion>/*.wsdl.

Other abstract WSDLs of reusable infrastructure services are stored under $AIA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Infrastructure/<ServiceVersion>/.

BusinessProcessServiceLibrary

All the abstract WSDLs of Composite Business Processes and Enterprise Business Flows are stored in:

$AIA_HOME/AIAMetaData/AIAComponents/ BusinessProcessServiceLibrary

The folder structure convention followed is:

BusinessProcessServiceLibrary/<Service Type>

The possible values for <Service Type> are CBP and EBF.

Example:

AIAMetaData/AIAComponents/BusinessProcessServiceLibrary/CBP

AIAMetaData/AIAComponents/BusinessProcessServiceLibrary/EBF

EnterpriseBusinessServiceLibrary

Part of Oracle AIA Canonical Model

All the abstract WSDLs of Enterprise Business Services are stored in:

$AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary

EnterpriseObjectLibrary

Part of Oracle AIA Canonical Model

All the schema modules of the Enterprise Object Library are stored in:

$AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary

ExtensionServiceLibrary

All the concrete WSDLs pointing to mirror servlet are stored in:

$AIA_HOME/AIAMetaData/AIAComponents/ExtensionServiceLibrary

The folder structure convention followed is:

ExtensionServiceLibrary/<Application Name>

The possible values for <Application Name> are described in the AIA Components Folder Structure section.

Note:

The <Application Name> specified here is used in AIA Project Lifecycle Workbench in the definition of the bill of materials for deployment.

Examples:

AIAMetaData/AIAComponents/ExtensionServiceLibrary/Siebel

InfrastructureServiceLibrary

All the abstract WSDLs of infrastructure services are stored in:

$AIA_HOME/AIAMetaData/AIAComponents/InfrastructureServiceLibrary

The folder structure convention followed is:

InfrastructureServiceLibrary/<Version Number>

Example:

AIAMetaData/AIAComponents/InfrastructureServiceLibrary/V1

Transformations

All the XSLs shared among various AIA services are stored in:

$AIA_HOME/AIAMetaData/AIAComponents/Transformations

The folder structure convention followed is:

Transformations/<Application Name>/<Version>

The possible values for <Application Name> and <Version Number> are described in the AIA Components Folder Structure section.

Note:

The <Application Name> specified here is used in AIA Project Lifecycle Workbench in the definition of the bill of materials for deployment.

Example:

AIAMetaData/AIAComponents/Transformations/Siebel/V1

UtilityArtifacts

All the Utility schemas and WSDLs are stored in:

$AIA_HOME/AIAMetaData/AIAComponents/UtilityArtifacts

The folder structure convention followed is:

UtilityArtifacts/schemas

UtilityArtifacts/wsdls

2.1.3.7 How to Change an Existing File

To change an existing file:

  1. From JDeveloper, open the relevant file by browsing to AIAWorkstation/$AIA_HOME/AIAMetaData/AIAComponents/<Path to file>

  2. Make modifications. Review the upgrade safe extensibility guidelines provided in AIA artifact-specific chapters of the guide.

  3. Save.

  4. Upload to SOA-MDS > apps/AIAMetaData/AIAComponents. Refer to Section 2.1.3.15, "Updating MDS."

2.1.3.8 How to Create File

To create a file:

  1. In JDeveloper, create a file following the design and development guidelines provided in AIA artifact-specific chapters of the guide.

  2. Copy the file to AIAWorkstation/$AIA_HOME/AIAMetaData/AIAComponents/<Path to file>.

    Note:

    Place the file in this folder.
  3. Upload to SOA-MDS > apps/AIAMetaData/AIAComponents. Refer to Section 2.1.3.15, "Updating MDS."

Accessing the Files in the AIA Components Folder

Use the following protocol to access the AIA Components content from all the AIA service artifacts at design time and runtime:

oramds:/apps/AIAMetaData/AIAComponents/<Resource Path Name>

Example:

oramds:/apps/AIAMetaData/AIAComponents/ApplicationObjectLibrary/SampleSEBL/schemas/CmuAccsyncAccountIo.xsd

Note:

All of the files in the AIA Components folder use relative paths to refer to other files in the AIA Components folder, if needed.

The WSDLs in the Enterprise Business Service Library use relative paths to refer to schemas in the Enterprise Object Library.

2.1.3.9 How to Work with AIAConfigurationProperties.xml in $AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/config

AIA provides external configuration properties to influence the run-time behavior of system, infrastructure components, and services. These properties are provided as name-value pairs at the system, module, and service levels in AIAConfigurationProperties.xml.

The AIAConfigurationProperties.xml supports two types of configurations:

  • System level, including module level

    Contains system-level configuration name-value pairs and module-level configuration name-value pairs within the system level.

  • Service level

    Contains service-specific configuration name-value pairs.

The following XPath functions are provided to access the configuration name-value pairs in the AIAConfigurationProperties.xml:

  • aiacfg:getSystemProperty (propertyName as string, needAnException as boolean) returns propertyValue as string

  • aiacfg:getSystemModuleProperty (moduleName as string, propertyName as string, needAnException as boolean) returns propertyValue as string

  • aiacfg:getServiceProperty (EBOName as string, serviceName as string, propertyName as string, needAnException as boolean) returns propertyValue as string

"getSystemModuleProperty()" and "getServiceProperty()" functions first look for the appropriate module and service property and if it is not found, they then look for a system property with the same property name.

In all three functions, if a matching property is not found, the result depends upon the value of the needAnException argument. If need AnException is true, then a PropertyNotFound Exception is thrown; otherwise, an empty string is returned.

2.1.3.10 How to Add a New Property to AIAConfigurationProperties.xml

To add a new property to AIAConfigurationProperties.xml:

  1. From JDeveloper, open the file AIAConfigurationProperties.xml by browsing to AIAWorkstation/$AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/config.

  2. Make modifications, as needed in AIA artifact development.

  3. Save.

  4. Upload to SOA-MDS > apps/AIAMetaData/config. Refer to Section 2.1.3.15, "Updating MDS."

  5. From the AIA Home Page, click Go in the Setup area. Select the Configuration tab to access the Configuration page. Click Reload to refresh the AIA Configuration cache.

2.1.3.11 How to Work with AIAEHNotification.xml in $AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/config

This file is the template of the email notification sent as a part of the Error Handling Framework.

To modify the AIAEHNotification.xml:

  1. From JDeveloper, open the file AIAEHNotification.xml by browsing to AIAWorkstation/$AIA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/config.

  2. Modify as needed.

  3. Save.

  4. Upload to SOA-MDS > apps/AIAMetaData/config. Refer to Section 2.1.3.15, "Updating MDS."

2.1.3.12 How to Work with Domain Value Maps in $AIA_HOME/AIAMetaData/dvm

The Domain Value Maps utility is a feature of Oracle SOA Suite. It supports the creation of static value maps and provides the custom XPath function:

dvm:lookupValue("oramds:/apps/AIAMetaData/dvm/<DVM Map Name>",<Source Column>,<Source Column Value>,<Target Column>,"")

For more information about DVMs, see Section 26.4, "Working with DVMs and Cross-References."

The DVMs are used by all the AIA Pre-Built Integrations and are shipped as part of AIA Foundation Pack. They are stored in $AIA_HOME/AIAMetaData/dvm.

To modify the Domain Value Maps:

  1. From JDeveloper, open the DVM file by browsing to AIAWorkstation/$AIA_HOME/AIAMetaData/dvm.

  2. Modify as needed.

  3. Save.

  4. Upload to SOA-MDS > apps/AIAMetaData/dvm. Refer to Section 2.1.3.15, "Updating MDS."

2.1.3.13 How to Work with Cross Reference (Xref) in $AIA_HOME/AIAMetaData/xref

The Cross Reference utility is a feature of Oracle SOA Suite. It supports the creation of dynamic values.

For more information about cross references, see "Working with Cross References" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

The Cross Reference meta information as used by all the AIA Process Integration Packs are shipped as part of AIA Foundation Pack and are stored in $AIA_HOME/AIAMetaData/xref.

To modify the Cross Reference metadata:

  1. From JDeveloper, open the Cross Reference file by browsing to AIAWorkstation/$AIA_HOME/AIAMetaData/xref.

  2. Modify as needed.

  3. Save.

  4. Upload to SOA-MDS > apps/AIAMetaData/xref. Refer to Section 2.1.3.15, "Updating MDS."

2.1.3.14 How to Work with Fault Policies in $AIA_HOME/AIAMetaData/faultPolicies/V1

The default fault policy file "fault-bindings.xml" is shipped as part of AIA Foundation Pack and is stored in $AIA_HOME/AIAMetaData/faultPolicies/V1.

To modify the "fault-bindings.xml":

  1. From JDeveloper, open the fault-bindings.xml file by browsing to AIAWorkstation/$AIA_HOME/AIAMetaData/faultPolicies/V1.

  2. Modify as needed.

  3. Save.

  4. Upload to SOA-MDS > apps/AIAMetaData/faultPolicies/V1. Refer to Section 2.1.3.15, "Updating MDS."

2.1.3.15 Updating MDS

Note:

Repeat this procedure every time a file is added to MDS.

To update SOA-MDS > apps/AIAMetaData:

  1. Browse to the folder at $AIA_HOME/aia_instances/$INSTANCE_NAME/bin.

  2. Source the file aiaenv.sh by executing the following command:

    source aiaenv.sh
    
  3. Browse to the folder at $AIA_HOME/aia_instances/$INSTANCE_NAME/config and open the deployment plan file, UpdateMetaDataDP.xml.

  4. Update the file UpdateMetaDataDP.xml by inserting include tags for each resource group that you want to add to the MDS:

    1. To upload all the files under "AIAMetaData", add the following:

      <include name ="**"/>
      
    2. To upload the files copied to "AIAComponents/ApplicationObjectLibrary/SEBL/schemas" folder, add the following:

      <include name ="AIAComponents/ApplicationObjectLibrary/SEBL/schemas/**"/>
      

    Note:

    In the include tag, the folder path must be relative to the folder AIAMetaData.
  5. Browse to AIA_HOME/Infrastructure/Install/config. Execute the script UpdateMetaData.xml by typing the command:

    ant -f UpdateMetaData.xml
    

Note:

MetaData gets deleted when you uninstall Foundation Pack. For specific instruction on how to clean the MDS after you uninstall Foundation Pack, see "Cleaning the MDS" in Oracle Fusion Middleware Installation and Upgrade Guide for Oracle Application Integration Architecture Foundation Pack.

2.1.3.16 How to Set Up AIA Project Lifecycle Workbench

The AIA Project Lifecycle Workbench application is set up on the AIA Workstation. All the members of the AIA implementation team developing services use the AIA Project Lifecycle Workbench.

For more information about setting up AIA Project Lifecycle Workbench, see "Setting up AIA Roles" in Oracle Fusion Middleware Installation and Upgrade Guide for Oracle Application Integration Architecture Foundation Pack.

2.1.3.17 How to Deploy AIA Foundation Pack Artifacts to Oracle SOA Suite Server

For more information about deploying AIA Foundation Pack artifacts to the Oracle Fusion Middleware-SOA server set up for AIA development, see "Installing and Deploying Using AIA Foundation Pack Installer" in Oracle Fusion Middleware Installation and Upgrade Guide for Oracle Application Integration Architecture Foundation Pack.

2.1.3.18 How to Deploy AIA Service Artifacts to Oracle SOA Suite Server

Define an AIA project in the AIA Project Lifecycle Workbench and capture meta information for all of the AIA service artifacts to be developed. The system uses this information to generate a deployment plan specific to the AIA project.

For more information about deploying all the AIA Project artifacts using a deployment plan generated from AIA Project Lifecycle Workbench to the Oracle Fusion Middleware-SOA server set up for AIA development, see Chapter 8, "Generating Deployment Plans and Deploying Artifacts."

2.2 Role of AIA Project Lifecycle Workbench

An AIA project is about engineering service-oriented business processes. The outcome of business process analysis and reengineering is taken as input, leading to conceptualization of service, planning, development, deployment and support paradigms of a typical SOA project.

The AIA Project Lifecycle flow consists of the following phases:

  • Business Process Modeling and Analysis

  • Business Process Decomposition and Service Conception

  • Service Design and Construction

  • Installation and Deployment

    Figure 2-1 illustrates the AIA project lifecycle flow showing the six phases and the actors involved in each phase.

Figure 2-1 AIA Project Lifecycle Flow: Phases and Actors

The image is described in the surrounding text

2.2.1 Introduction to the Tools Used

The following tools support the entire lifecycle of the an AIA project:

  • Oracle Business Process Publisher

  • Oracle Enterprise Repository

  • AIA Service Constructor plugin in JDeveloper

  • Oracle Enterprise Repository and AIA Harvester

  • AIA Deployment Plan Generator

  • AIA Project Lifecycle Workbench

Oracle Business Process Publisher

Use the Oracle Business Process Publisher to analyze the Reference Process Models delivered as part of Foundation Pack.

For more information about Reference Process Models, see Oracle Fusion Middleware Reference Process Models User's Guide for Oracle Application Integration Architecture Foundation Pack.

Oracle Enterprise Repository

Oracle Enterprise Repository is the design-time repository for governing design-time and run-time assets to achieve reuse and sharing across the distributed development community. Oracle Enterprise Repository provides:

  • Visibility - From design time to runtime, captures and maintains metadata, relationships, categories, and so on.

  • Control - Manages development lifecycle transition from concept, through implementation, to release.

  • Evolution - Empowers customers to evolve their business and integration processes.

For more information about Oracle Enterprise Repository, see Chapter 12, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."

AIA Service Constructor

The AIA Service Constructor is an Oracle JDeveloper plug-in to generate composites conforming to AIA guidelines and naming standards. It also provides guidance for annotating the artifacts to support governance.

For more information about the AIA Service Constructor, see Chapter 4, "Working with Service Constructor."

AIA Harvester Tool

The AIA Harvester parses the AIA service artifacts and captures metadata into the AIA Project Lifecycle Workbench database and the Oracle Enterprise Repository, if used. The system uses this information to generate deployment plans.

AIA leverages Oracle Enterprise Repository to achieve SOA visibility. Oracle Enterprise Repository is an optional component to AIA installation and execution.

AIA Harvester is built on top of the Oracle Enterprise Repository Harvester Extension Framework. It introspects SOA artifacts and publishes their ensuing metadata into the Project Lifecycle Workbench back end or Oracle Enterprise Repository (optional), or both, to aid governance and downstream automation. In AIA, the AIA Harvester is provided in the form of command-line utility. Users may download and set up on their local development environment.

For more information about AIA Harvester, see Chapter 5, "Harvesting Oracle AIA Content."

AIA Project Lifecycle Workbench

The AIA Project Lifecycle Workbench is installed on the AIA Workstation and helps drive the AIA Project Lifecycle flow.

For more information about the AIA Project Lifecycle Workbench, see Chapter 3, "Working with Project Lifecycle Workbench."

Deployment Plan Generator

The deployment plan has all the details for the artifacts in an AIA project to be deployed. The AIA Deployment Driver takes the deployment plan as input and deploys all the artifacts on Oracle Fusion Middleware servers and updates the end point information back into Oracle Enterprise Repository.

It also facilitates publishing this information into Oracle Service Registry.

For more information about the Deployment Plan Generator, see Chapter 8, "Generating Deployment Plans and Deploying Artifacts."

2.2.2 Introduction to the Business Process Modeling and Analysis Phase

Business Process Models are blueprints of the work accomplished in an enterprise to add value and deliver to customers. The models represent the ideal way work should be carried out with optimal cost at highest possible efficiencies.

The analysis of these models and categorizing them into business processes, business activities, and tasks is done by Business Analysts. The result of this analysis is a set of reusable business activities and tasks, which can be woven into different business processes.

In this phase, Business Analysts identify and catalog the set of reusable business activities and tasks for the business processes. Business Analysts also establish the Key Performance Indicators (KPIs) that are to be met. They use the Oracle BPA Suite to analyze the AIA Reference Process Models and identify the business processes, business activities, and tasks to be implemented.

Business Analysts define the project and provide details of solutions needed.

For more information about reference process models in Oracle AIA, see the Oracle Fusion Middleware Reference Process Models User's Guide for Oracle Application Integration Architecture Foundation Pack.

For more information about the AIA Project Lifecycle Workbench, see Chapter 3, "Working with Project Lifecycle Workbench."

2.2.3 Introduction to the Business Process Decomposition and Service Conception Phase

Each of the business activities and tasks can be described in terms of business entities involved and the action being performed with them. The origins of the service definition are in the categorization of reusable business activities and tasks.

  • Examples of business entities are Customer, Product, Order, and so on.

  • Examples of tasks are Create Customer, Update Order, Enter Service Request, Request Account Balance, and so on.

  • Examples of business activities are Do Customer Credit Check, Fulfill Order, Process Trouble Ticket, and so on.

The EBSs defined as AIA artifacts represent the business activities and tasks. The metadata about the EBSs are available in Oracle Enterprise Repository after loading the AIA Solution Pack.

Various business activities and tasks defined in AIA Reference Process Models provide links to the corresponding EBSs in the Oracle Enterprise Repository.

Solution Architects refine the projects defined by business analysts, identify the services available, create definitions for new services to be developed, and engage with developers to drive the design of new services.

For more information about the Project Lifecycle Workbench, see Chapter 3, "Working with Project Lifecycle Workbench."

2.2.4 Introduction to the Service Design and Construction Phase

During the service construction phase, Developers extend available AIA services, if needed, or design and develop new services.

The tasks of this phase are supported by the following tools:

  • The service solution components defined in the Project Lifecycle Workbench provide guidance to developers about the fine-grained services they must create to fulfill the functionality of a task.

    For more information about Project Lifecycle Workbench, see Chapter 3, "Working with Project Lifecycle Workbench."

  • The Service Constructor enables developers to automatically generate AIA-compliant SCA composites for ABCSs.

    For more information about Service Constructor, see Chapter 4, "Working with Service Constructor."

  • The Composite Application Validation System (CAVS) supports process and service testing.

    For more information about CAVS, see "Preparing to Use the Composite Application Validation System" in Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack.

  • The error handling framework augments SCA exception management and retries.

    For more information about error handling, see "Setting Up Error Handling" in Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack.

2.2.5 Introduction to the Deployment Plan Generation Phase

After composites are constructed, installation developers select desired composites that collectively perform a required functionality. An AIA project is a collection of functionally related composites. Each composite is self-contained in that its deployment information (such as adapters, queues, schemas, and JDNI resources) is fully specified by its developer during the preceding service construction stage.

The installation developer creates an AIA project specific deployment plan by aggregating deployment information from all composites that form an AIA project. The developer may choose to use the Deployment Plan Generator to automatically generate process deployment plans.

For more information about error handling and logging, see Chapter 8, "Generating Deployment Plans and Deploying Artifacts."

2.2.6 Introduction to the Install and Deploy Phase

The AIA Installer helps to deploy an AIA project release into your development environment. The AIA Installer makes all AIA composites and other artifacts available to target environments. It deploys the composites and other artifacts specified in your selected deployment plan. It also publishes assets to a SOA repository and registry, respectively.

For more information about the AIA Installer, see the Oracle Fusion Middleware Installation and Upgrade Guide for Oracle Application Integration Architecture Foundation Pack.

2.3 AIA Artifacts in Various Integration Styles

AIA Architecture recommends variety of integration styles and AIA patterns to enable the flight of a message in an Integration Flow.

AIA implementation teams should evaluate the following points to choose an integration style and methodology to follow when creating various AIA artifacts.

Business Scenario - The Functional Design Document (FDD) describes the Business Scenario and provides:

  • A detailed description of the business case.

  • Various use cases detailing the various usage scenarios, including 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 performance and scalability requirements.

  • Details about business objects to be used.

  • Actions to be performed on the various business objects.

  • Oracle tools and technologies to be leveraged.

The AIA artifacts that are required for the collaboration between the applications or functions are dependent on the integration style adopted for an integration flow. These artifacts include ABCSs, EBSs, EBFs, CBPs, and various adapter services.

The AIA Project Lifecycle Workbench is used to define an AIA Project, which contains definitions of all the artifacts to be designed, developed, tested, packaged, and delivered.

2.3.1 Integration Through Native Application Interfaces Using the Oracle Applications Technology Infrastructure

In this style, messages flow from the requester application to the providing application. The mode of connectivity could be SOAP/HTTP, queues, topics, or native adapters.

No middleware is involved in this integration.

The requester application must establish the connectivity with the provider applications. The requester application is responsible for sending the request in the format mandated by provider's API and interpreting the response sent by the provider. Requester and provider applications are responsible for the authentication and authorization of requests.

The integration flow consists of individual application functions interacting directly. All capabilities required to make this interaction possible must be available or made available in the individual applications.

Figure 2-2 illustrates how a requester application interacts directly with a provider application.

Figure 2-2 Example of a Requester Application Interacting Directly with a Provider Application

The image is described in the surrounding text

In more complex situations, when the integration flow consists of multiple steps involving interactions with multiple applications, leverage the workflow-like capability in one or more applications.

No AIA artifacts are built in this case. Establish direct connectivity between applications.

For more information about different modes of connectivity, see Chapter 24, "Establishing Resource Connectivity."

2.3.2 Understanding Integration Styles with Integration Framework

In all the integration styles with integration framework, middleware technologies are leveraged. The applications push the messages to the middleware, and the middleware pushes the messages to the target applications.

These integration styles have integration framework:

  • Integration flow leveraging provider services

  • Integration flow leveraging provider services with canonical model-based virtualization

The AIA service artifacts needed for implementing an integration flow in any of the integration styles with integration framework depends on:

  • Complexity of data exchange

    • No processing logic

    • With processing logic

  • Message exchange pattern

    • Synchronous request-response

    • Asynchronous one-way (fire-and-forget) - Need for guaranteed delivery assumed

    • Asynchronous request-delayed response - Need for guaranteed delivery and correlation of response assumed

These AIA service artifacts are defined in AIA Architecture:

  • CBP

  • EBSs

  • EBFs

  • ABCSs

  • Adapter Services

    • JMS Producer and JMS Consumer

    • JCA Adapter Service

For more information about different message exchange patterns, see Chapter 14, "Designing and Developing Enterprise Business Services" and Chapter 28, "Working with AIA Design Patterns."

For more information about different AIA service artifacts and Oracle SOA Suite components used to implement them, see Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

Note:

In the following sections, for each integration style with integration framework, the AIA artifacts to be developed are recommended for a combination of situations.

2.3.2.1 Integration Flow with Requester Application Services

The requester application invokes a single AIA service on the middleware. The request presented by the requester application is fulfilled by the AIA service by invoking suitable APIs in the provider applications. The AIA service can accept a message in the requester application format. The AIA service presents the request to the provider applications in the format mandated by the provider's API. The AIA service accepts the response in the provider application format, if needed. The AIA service is responsible for the authentication and authorization of the requests.

The integration flow consists of this single AIA service artifact deployed on the middleware managing all interactions with all participating applications.

Figure 2-3 illustrates how a service deployed on the middleware enables integration between the requester and the provider application.

Figure 2-3 Example of Integration Flow with Native Application Services

The image is described in the surrounding text

For more complex situations in which the integration flow consists of multiple steps involving interactions with multiple applications, the AIA service implements a workflow-like capability and manages all interactions with all the participating applications.

The AIA service artifacts to be developed depend on the complexity of data exchange and various message exchange patterns.

Table 2-1 lists suitable AIA artifacts for a combination of situations.

Table 2-1 AIA Artifacts for Integration Flows with Requester Application Services

Message Pattern No Processing Logic With Processing Logic

Synchronous Request Response

EBS

EBF

Asynchronous One-Way

EBS

EBF

Asynchronous Request-Delayed Response

EBS - Request

EBS - Response

EBF


2.3.2.2 Direct Integration Through Application Web Services

A provider application-specific AIA service, exposing a coarse-grained functionality of the provider application leveraging one or more APIs, is created with a suitable provider application-specific interface. Several business initiators can invoke this AIA service. If the business initiators cannot present the request in the format understood by the provider application-specific AIA service, a requester application-specific AIA service is used to transform the business initiator request to the provider application format. The requester application-specific AIA service is responsible for authenticating and authorizing the requests. The provider application-specific AIA service propagates the authentication and authorization information of the requests to the provider application.

The integration flow would consist of a requester application-specific AIA service artifact deployed on the middleware managing all interactions with all provider application-specific AIA services.

Figure 2-4 illustrates how a service deployed on the middleware enables the integration between the requester and the provider application.

Figure 2-4 Example of Integration Flow Leveraging Provider Services

The image is described in the surrounding text

For more complex situations in which the integration flow involves interactions with multiple applications, the requester application-specific AIA service implements a workflow-like capability and manages all interactions with all the provider application-specific AIA services.

The AIA service artifacts to be developed depend on the complexity of data exchange and various message exchange patterns.

Table 2-2 lists suitable AIA artifacts for a combination of situations.

Table 2-2 AIA Artifacts for Leveraging Provider Services

Message Pattern No Processing Logic With Processing Logic

Synchronous Request Response

Requester ABCS

Provider ABCS

Requester ABCS

Provider ABCS

Asynchronous One-Way

Requester ABCS

Provider ABCS

Requester ABCS

Provider ABCS

Asynchronous Request-Delayed Response

Requester ABCS

Provider ABCS

Requester ABCS

Provider ABCS


2.3.2.3 Integration Through Packaged Canonical and Standardized Interfaces

Loose coupling through a canonical (application-independent) model is a sign of a true SOA. Participating applications in loosely coupled integrations communicate through a virtualization layer. Instead of direct mappings between data models, transformations are used to map to the canonical data model. While this allows for greater reusability, the transformations both increase the message size and consume more computing resources. For functional integrations, this integration pattern is ideal since the reusability gained is worth the slight overhead cost.

In this case, an EBS based on the Enterprise Business Objects (EBOs) and Enterprise Business Messages (EBMs) is created as a mediator service.

A provider service, exposing a coarse-grained functionality of the provider application leveraging one or more APIs, is created with the same EBM interface as the EBS operation interface.

If the business initiators cannot present the request in the format understood by the EBS operation interface, a requester service is used to transform the business initiator request into the provider service format.

Figure 2-5 illustrates how the request sent by the source application is processed by the target application with the help of the EBS and a set of intermediary services. The request and provider transport services are optional and are needed only in case of non-SOAP-based transports.

Figure 2-5 Example Showing Canonical Model-based Virtualization

The image is described in the surrounding text

For more complex situations in which the integration flow involves interactions with multiple applications, the requester application-specific AIA service presents its request to the mediator AIA service. The mediator AIA service triggers an AIA service, which implements a workflow-like capability and manages all interactions with all the provider application-specific AIA services through mediator AIA services. In this case, the mediator AIA service interface chosen is assumed to be accepted as the common interface. Thus, all requester application-specific AIA services invoke this mediator AIA service, and all the provider application-specific AIA services implement this common interface. The AIA service artifacts to be developed depend on the complexity of data exchange and various message exchange patterns.

Table 2-3 lists suitable AIA artifacts for a combination of situations.

Table 2-3 AIA Artifacts for Integration Flows with Multiple Application Interactions

Message Pattern No Processing Logic With Processing Logic

Synchronous Request Response

Requester ABCS

EBS

Provider ABCS

Requester ABCS

EBS

Provider ABCS

Asynchronous One-Way

Requester ABCS

EBS

Provider ABCS

CBP

Requester ABCS

EBS

EBF

Provider ABCS

Asynchronous Request-Delayed Response

Requester ABCS

EBS

Provider ABCS

CBP

Requester ABCS

EBS

EBF

Provider ABCS


2.3.3 Bulk Data Processing

Bulk data processing involves a large batch of discrete records or records with very large data. The methodology is point-to-point integration specializing in the high-performance movement of data with a trade-off of reusability.

Bulk data processing is about persistent data replicated across multiple applications. The integrations fall into four styles:

  • Initial data loads

  • High-volume transactions with Xref table

  • Intermittent high-volume transactions

  • High-volume transactions without Xref table

For complete details about using bulk data processing with AIA, see Chapter 25, "Using Oracle Data Integrator for Bulk Processing."

2.3.4 Integration Style Choice Matrix

In any AIA implementation, a variety of integration flows conforming to different integration styles coexist. Integration flows represent processing of messages by AIA services deployed to deliver the business functionality desired.

The choice of an integration style influences the design of AIA services. Conversely, decisions about the design of AIA services lead to a particular integration style.

Various aspects of AIA service design are:

  • Service Granularity

    Decide on the functionality to be implemented in a service either based on the business logic needed for a business activity or task (the result of business process analysis) or based on the functions exposed by a provider application.

    Service granularity is Coarse-Grained if the business logic conforms to the requirements of a business activity or task (result of business process analysis of AIA Reference Process Models). In this case, the service is implemented by invoking multiple low APIs of the provider application.

    Service granularity is Granular if the business logic conforms to the low-level functions exposed by the provider application.

  • Service Reusability

    Service reuse is High for different Integration Flows if its design is modular and built for the requirements of various business use cases. Conformance to the requirements of a business activity or task (the result of business process analysis of AIA Reference Process Models) leads to modular design.

    If the service is built to meet the requirements of a particular business use case, then the logic is monolithic and reuse is Low.

  • Service Virtualization

    This aspect provides for separation of concerns and independence of requester applications and provider applications from changes. The choices are Yes or No.

  • Service Interoperability

    The capability of diverse service implementations to interoperate is dependent on their conformance to WS-I standards, a common message meta model, and a robust versioning strategy. The AIA EBS WSDLs and AIA EBOs and EBMs provide this capability as delivered. For others, special effort is needed to ensure interoperability.

Table 2-4 summarizes the granularity, reusability, virtualization, and interoperability for the various integration styles.

Table 2-4 AIA Service Design Summary

Integration Styles Granularity Reusability Virtualization Interoperability

Integration Flow with Native Application APIs

No AIA services on middleware; direct Application to Application interaction

No AIA services on middleware; direct Application to Application interaction

No AIA services on middleware; direct Application to Application interaction

No AIA services on middleware; direct Application to Application interaction

Integration Flow with Requester Application Services

Coarse Grained with High Performance overhead

Low

No

Special Effort

Integration Flow leveraging Provider Services

Granular

High

No

Special Effort

Integration Flow leveraging Provider Services with Canonical-Model based Virtualization

Coarse Grained

High

Yes

As Delivered


2.4 Development Tasks for AIA Artifacts

This section discusses the development tasks for AIA artifacts and describes how to:

  • Identify the EBO

  • Design an integration flow

  • Identify and create the EBS

  • Construct the ABCS

  • Enable the participating applications

  • Identify and create the EBF

2.4.1 Identifying the EBO

The FDD should discuss:

  • The conceptual canonical model or EBOs to be used and the actions that must be performed on this entity.

  • Identification of the EBO from the Foundation Pack or construction of EBO. The EBO should incorporate all of the requirements needed by this integration.

  • Identification of the EBM from the Foundation Pack or construction of EBM, if required.

For more information, see the Enterprise Object Library Extensibility Guide on My Oracle Support in article ID 983958.1.

2.4.2 Designing an Oracle AIA Integration Flow

The design of an Integration Flow is detailed in a technical design document (TDD). The criteria for completion of a TDD are dependent on the project and the accompanying deliverables.

The TDD lays out complete details on the flow logic, integration artifacts, object/element mapping, DVM types and values, error handling, and installation specifics. It also includes an outline of the unit test plans that a developer uses to validate run-time operation.

The Integration Flow is not a run-time executable artifact, so a message exchange pattern cannot be attributed to the Integration Flow. The design of the AIA service artifacts listed previously must include a careful analysis of the business scenario, which leads to a decision on the message exchange patterns for each AIA service artifact.

For more information about message exchange pattern decisions, see Section 14.2.3, "Establishing the MEP of a New Process EBS", Section 15.3, "Identifying the MEP", and Section 19.2.2, "How to Identify the Message Pattern for an EBF."

The tasks needed to enable the Oracle AIA service artifacts to participate in various message exchange patterns are discussed in the chapters detailing the development of these artifacts.

To design an Integration Flow:

  1. Analyze the participating Application Business Messages (ABMs) and map them to the EBM.

    For more information, see "Understanding EBOs and EBMs" in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

  2. Identify the EBSs.

    See Chapter 14, "Designing and Developing Enterprise Business Services."

  3. Identify the EBFs.

    See Chapter 19, "Designing and Constructing Enterprise Business Flows."

  4. Identify the ABCSs.

    See Chapter 15, "Designing Application Business Connector Services."

  5. Identify and decide on the participating application connectivity methodology.

    See Chapter 14, "Designing and Developing Enterprise Business Services."

    For more information, see "Understanding Interaction Patterns" in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

  6. Identify and decide on the security model.

    See Chapter 29, "Working with Security."

    For more information, see "Understanding Security" in Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack.

  7. Identify and decide on the performance and scalability needs.

  8. Identify and decide on the deployment strategy.

An Oracle AIA Integrating Scenario is a logical collection of AIA service artifacts, including:

  • EBSs

  • EBFs

  • ABCSs

Since an AIA service artifact can be part of multiple AIA integration flows, go through the Oracle Enterprise Repository and identify any service artifact that can be reused. The AIA service artifacts are built with reusability in mind.

For each of the artifacts, follow these reusability guidelines:

  • Reusability guidelines for EBSs

  • Reusability guidelines for EBFs

  • Reusability guidelines for ABCSs

To develop an AIA Integration Flow:

  1. Identify and create the EBS, if needed.

    See Chapter 14, "Designing and Developing Enterprise Business Services."

  2. Enable the participating applications.

    See Section 2.4.5, "Enabling and Registering Participating Applications."

  3. Construct the ABCS.

    See Chapter 16, "Constructing the ABCS."

  4. Construct the EBF.

    See Chapter 19, "Designing and Constructing Enterprise Business Flows."

    For more information about standard naming conventions, see Chapter 32, "Oracle AIA Naming Standards for AIA Development."

2.4.3 Identifying and Creating the EBS

Each EBO has an EBS to expose the "Create, Read, Update, Delete" (CRUD) operations and any other supporting operations. Each action present in the associated EBM is implemented as a service operation in EBS. Creation of the EBS and the implementation of all of the service operations is a critical task in the implementation of the end-to-end integration flow.

Note:

The operations in the entity EBS should only act on the relevant business object and not any other business object. Operations that act on multiple business object should reside in the process EBS.

When the EBS exists, check whether all of the actions necessary for acting on the EBO pertaining to this Integration Flow were implemented as service operations. If they were not, change the existing EBS to add the additional service operations.

This procedure lists the high-level tasks to construct an entity based EBS. Chapter 14, "Designing and Developing Enterprise Business Services" provides complete information on how to complete each of these tasks:

To construct an entity-based EBS:

  1. Define and create the contract for the EBS.

  2. Construct the EBS.

  3. Register relevant provider services for each of the operations.

  4. Add routing rules for new or existing operations.

  5. Enable each of the service operations for the CAVS.

For more information, see Chapter 14, "Designing and Developing Enterprise Business Services"

2.4.4 Constructing the ABCSs

For more information, see Chapter 16, "Constructing the ABCS" and Chapter 17, "Completing ABCS Development."

2.4.5 Enabling and Registering Participating Applications

This section discusses the steps required to enable the participating applications in your AIA Foundation Pack ecosystem. It also discusses the options available for managing participating applications to the AIA registry.

2.4.5.1 Enabling Participating Applications

To enable participating applications:

  1. Identify the service APIs that must be invoked.

  2. Provide the WSDL to the participating applications.

  3. Construct adapter services, if required.

2.4.5.2 Managing the Oracle AIA System Registry

This section discusses how to manage the Oracle Application Integration Architecture (AIA) system registry.

2.4.5.2.1 Understanding the Oracle AIA System Registry

The purpose of the system registry is to identify and capture information about the requester and provider systems that are participating in your Oracle AIA ecosystem. The system registry captures system attributes that are relatively static.

While the system registry for your Oracle AIA ecosystem is initially loaded during the Oracle AIA installation process, you can use the user interface to manage information in the registry.

A benefit of storing a system registry is that certain system attributes can be easily defaulted to enterprise business message headers. Requester and target systems may have multiple instances, each with different attributes. The system registry enables you to capture attributes for each instance so that they can be identified in subsequent processing.

Foundation Pack provides two ways to manage data in your system registry:

  • Systems page

  • SystemRegistration.xml configuration file

2.4.5.2.2 How to Manage the System Registry Using the Systems Page

Goal:

Use the Systems page to manage the participating applications stored in the Oracle AIA system registry.

Actor:

System administrator (AIAApplicationUser role)

To manage your Oracle AIA system registry using the System page:

  1. Access the AIA Home Page. Click Go in the Setup area.

  2. Select the Systems tab as shown in Figure 2-6 and Figure 2-7.

    Figure 2-6 Systems Page (1 of 2)

    Systems tab (1 of 2)

    Figure 2-7 Systems Page (2 of 2)

    Systems tab (2 of 2)
  3. Enter your search criteria and click Search to execute a search for a particular participating application system.

  4. Use the page elements listed in Table 2-5 to define participating application system registry entries.

Table 2-5 Systems Page Elements

Page Element Description

Delete

Select a system row and click Delete to execute the deletion.

Create

Click to add a system row that you can use to add a participating application to the system registry.

Save

Click to save all entries on the page.

Internal Id

System instance name assigned by an implementer, for example ORCL 01. This value would be used in transformation and domain value map column names to indicate a system instance. For example, the value can be used in transformations to identify the requester or provider system.

System Code

This is a required value. This value populated to the Enterprise Business Message (EBM) header.

System Description

Long description of the requester or provider system instance identified in the System Code field. This value populated to the EBM header.

IP Address

IP address of the participating application by which one can access the participating application endpoint. This value is populated to the EBM Header.

URL

This is the host name and port combination specified in the URL format by which one can access the participating application. Typically, this is in the form of http://hostname:port/. This value is populated to the EBM Header. This URL is not used by process integrations to access the participating application's web services, but rather this value is stored for informational purposes. Process integration developers determine which URL to use as the entry point for a participating application.

System Type

Provides the system type. For example, Oracle EBIZ. This is a required value.

Application Type

Application being run within the specified system. For example, a system type of Oracle EBIZ may have an application type value of FMS. This value populated to the EBM header.

Version

Provides the version of the application being run by the system. This value populated to the EBM header.

Contact Name

Provides the name of the contact responsible for the system. This value populated to the EBM header.

Contact Phone

Provides the phone number of the contact responsible for the system. This value populated to the EBM header

Contact E-Mail

Provides the email address of the contact responsible for the system. This value is populated to the EBM header.


2.4.5.2.3 How to Manage the System Registry Using the SystemRegistration.xml Configuration File

Goal:

Create a systemRegistration.xml configuration file for a Project Lifecycle Workbench process integration project. Create one systemRegistration.xml file per project. The systemRegistration.xml file is used by the Deployment Plan Generator and AIA Deployment Driver to populate the participating applications used by the process integration to the Oracle AIA system registry.

This is a progammatic approach to completing the same task that can be completed using the Systems page.

For more information about the Systems page, see Section 2.4.5.2.2, "How to Manage the System Registry Using the Systems Page."

Figure 2-8 illustrates how the values defined in systemRegistration.xml files for each process integration are used to populate the Oracle AIA system registry.

Figure 2-8 Flow of System Registration Data

Flow of system registration data

Role:

Integration developer

To manage your Oracle AIA system registry using the SystemRegistration.xml configuration file:

  1. Create a systemRegistration.xml file for your process integration project.

  2. To add participating application values to the system registry, use the <create> element provided in the sample XML structure shown in Example 2-1.

    Example 2-1 AIASystemRegistration.xml

    <AIASystemRegistration>
       <create>
       MERGE INTO AIA_SYSTEMS sysreg USING dual on (dual.dummy is
     not null and sysreg.SYSTEM_CODE='SampleSEBLDPT003' ) WHEN NOT
     MATCHED THEN INSERT (SYSTEM_ID,SYSTEM_INTERNAL_ID,SYSTEM_CODE,
    SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_URL,SYSTEM_TYPE,APPLICATION_
    TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_PHONE,CONTACT_
    EMAIL) VALUES (AIA_SYSTEMS_S.nextval,'SampleSEBLDPT003','SampleSEBLDPT003',
    'Sample Siebel Instance01','10.0.0.1','http://
    ${participatingapplications.SampleSiebel.server.
    soaserverhostname}:${participatingapplications.SampleSiebel.
    server.soaserverport}
    /ecommunications_enu'
    ,'Sample SIEBEL','CRM','${pips.BaseSample.version}
    ','Siebel contact','1234567891','aiasamples_contact@aia.com')
          / 
       MERGE INTO AIA_SYSTEMS sysreg USING dual on (dual.dummy is
     not null and sysreg.SYSTEM_CODE='SamplePortalDPT003' ) 
    WHEN NOT MATCHED THEN INSERT (SYSTEM_ID,SYSTEM_INTERNAL_
    ID,SYSTEM_CODE,SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_URL,SYSTEM_
    TYPE,APPLICATION_TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_
    PHONE,CONTACT_EMAIL) VALUES (AIA_SYSTEMSS.nextval,
    'SamplePortalDPT003','SamplePortalDPT003',
    'Sample Portal Instance 01','10.0.0.1',
    'http://${participatingapplications.SamplePortal.server.
    soaserverhostname}:${participatingapplications.SamplePortal.
    server.soaserverport}
    ','Sample Portal','BILLING','${pips.BaseSample.version}'
    ,'Portal contact','1234567892','aiasamples_contact@aia.com')
        / 
       </create>
    </AIASystemRegistration>
    

    The tokens you create in the <create> element should be based on the structure of the AIAInstallProperties.xml file.

    For example, the following token, ${participatingapplications.SamplePortal.server.soaserverhostname}, was derived from the structure in the AIAInstallProperties.xml file shown in Example 2-2:

    Example 2-2 AIAInstallProperties.xml

    <properties>
       <participatingapplications>
          <SamplePortal>
             <server>
                <soaserverhostname>adc2180948.xy.example.com
                </soaserverhostname>
             </server>
          ...
       </participatingapplications>
    </properties>
    

    Actual values for the tokens in bold are derived from $AIA_INSTANCE/config/AIAInstallProperties.xml during process integration installation using a deployment plan.

  3. To delete participating application values from the AIA application registry, use the <delete> element provided in the sample XML structure shown in Example 2-3 and replace the system code values in bold with the system codes of the participating applications.

    Example 2-3 <delete> Element in AIASystemRegistration.xml

    <AIASystemRegistration>
       <delete>
          delete from AIA_SYSTEMS where SYSTEM_CODE='SampleSEBLDPT005'
           / 
          delete from AIA_SYSTEMS where SYSTEM_CODE='SamplePortalDPT005'
           / 
       </delete>
    </AIASystemRegistration>
    
  4. Save the systemRegistration.xml file to $AIA_HOME/pips/<projectCode>/DatabaseObjects/.

    If you are using the Project Lifecycle Workbench in your development methodology, the <projectCode> folder name is the project code value assigned to your project in Project Lifecycle Workbench.

    If you are not using the Project Lifecycle Workbench, assign your own project code value to the folder name.

The Deployment Plan Generator always generates the system registration task in the deployment plan. The system registration task extracts configuration information from systemRegistration.xml, replaces tokens with actual values from AIAInstallProperties.xml, and executes an SQL statement to populate the system registry.

If no systemRegistration.xml file is present for the Deployment Plan Generator to leverage, manually remove the system registration task from the deployment plan, or the deployment fails.

Example 2-4 shows a generated deployment plan that includes the system registration task to register systems for projectCode ABCProcessInt:

Example 2-4 System Registration Task in Generated Deployment Plan

<DeploymentPlan>
   <Configurations>
      ...
      <SystemRegistration database="fp.db.aia" resourceFileName="$AIA_
HOME/pips/ABCProcessInt/DatabaseObjects/systemRegistration.xml" delimiter="/" 
action="create"/>
      ...
   </Configurations>
</DeploymentPlan>

The AIA Deployment Driver reads the deployment plan, replaces the tokens from the systemRegistration.xml with actual values from AIAInstallProperties.xml, and executes the system registration SQL statement to populate the system registry.

Example 2-5 shows the SQL content extracted by the AIA Deployment Driver:

Example 2-5 SQL Content Extracted by AIA Deployment Driver

MERGE INTO AIA_SYSTEMS sysreg
USING dual
on (dual.dummy is not null and sysreg.SYSTEM_CODE='SampleSEBL' )
WHEN NOT MATCHED THEN INSERT 
(SYSTEM_ID,SYSTEM_INTERNAL_ID,SYSTEM_CODE,SYSTEM_DESC,SYSTEM_IP_ADDR,SYSTEM_
URL,SYSTEM_TYPE,APPLICATION_TYPE,APPLICATION_VERSION,CONTACT_NAME,CONTACT_
PHONE,CONTACT_EMAIL)
VALUES (AIA_SYSTEMS_S.nextval,'Siebel','SampleSEBL','Sample Siebel Instance 
01','10.0.0.1','http://siebel.xy.example.com:7001/ecommunications_enu', 
SIEBEL','CRM','1.0, 'Siebel contact','1234567891','Siebelcontact@Siebel.com')
/

If you are deploying multiple Project Lifecycle Workbench process integration projects, multiple systemRegistration.xml files get added. Check whether participating applications are added to system registry entries before deploying them. Duplicate requests cause an SQL exception due to primary key and unique value constraints enabled on the system registry table.

Check them by including the text in bold in the SQL content above. If a participating application value is found to be a duplicate, it is not created. If it is unique, it is created.

The AIA Deployment Driver extracted this example SQL content based on replacing tokens from systemRegistration.xml with Example 2-6 data provided in $AIA_INSTANCE/config/AIAInstallProperties.xml:

Example 2-6 Sample SQL Content Extracted by AIA Deployment Driver

<?xml version="1.0" encoding="UTF-8"?>
   <properties>
      <participatingapplications>
         <siebel>
             <http>
                <host>siebel.xy.example.com</host>
                <port>7001</port>
             </http>
             <internal>
                <id>Siebel</id>
             </internal>
             <version>1.0</version>
          <siebel>
           ...
      </participatingapplications>
   </properties>

2.4.6 Identifying and Creating the EBF

Each identified EBF has a corresponding business process EBS. The operations within this EBS are the entry points to EBFs.

For more information, see Chapter 19, "Designing and Constructing Enterprise Business Flows."

2.5 Testing an Oracle AIA Integration Flow

The CAVS supports end-to-end testing by stubbing out the applications.

For more information about CAVS, see "Introduction to the Composite Application Validation System" in Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack.