This chapter describes how to build AIA integration flows.
This chapter includes the following sections:
For AIA development and testing, the setup of development and test environments consists of downloading the SOA Suite, and setting up your AIA environment.
Start your AIA development by installing SOA Suite Quick Start and connecting to a SOA server.
Download and install SOA Suite 12.1.3 Quick Start.
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:
Connection name: <give a connection name for your application>.
Connection Type: use the default value - WebLogic 12.1.3
Provide the username and password of your WebLogic server.
WebLogic Host name: <your server host name>.
Port: <your server port number>.
SSl port: <your server ssl port>.
WLS Domain: <provide your domain name where SOA server is installed>.
AIA Workstation is a dedicated system set up to drive AIA development. Install the SOA Core Extension on this system and set up the AIA Project Lifecycle Workbench from the SOA Core Extension.
This section includes the following topics:
Working with AIA Components Content in $SOA_HOME/AIAMetaData
How to Work with AIAEHNotification.xml in $SOA_HOME/aia_instances/$INSTANCE_NAME/AIAMetaData/config
How to Work with Domain Value Maps in $SOA_HOME/AIAMetaData/dvm
How to Work with Cross Reference (Xref) in $SOA_HOME/AIAMetaData/xref
How to Work with Fault Policies in $SOA_HOME/AIAMetaData/faultPolicies/V1
Install 12.1.3 WebLogic Server with Oracle Application Development Framework.
Install Oracle Database.
Install SOA Suite Quick Start.
Ensure you comply with the Supported Systems Configuration, as detailed on OTN at, http://www.oracle.com/technetwork/middleware/fusion-middleware/overview/index.html
Hardware should be at least 4 CPU and 32 GB of RAM with a supported Operating System.
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 $SOA_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.
For more information see Developing SOA Core Composite Applications on the OTN network.
Note:
For new 12c customers you will have the utility objects and receive any other objects through the appropriate pre-built integrations you choose to license.
AIA MetaData ($SOA_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
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:
$SOA_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:
$SOA_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 $SOA_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 $SOA_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 $SOA_HOME/AIAMetaData/AIAComponents/B2BServiceLibrary/Infrastructure/<ServiceVersion>/.
BusinessProcessServiceLibrary
All the abstract WSDLs of Composite Business Processes and Enterprise Business Flows are stored in:
$SOA_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:
$SOA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary
EnterpriseObjectLibrary
Part of Oracle AIA Canonical Model
All the schema modules of the Enterprise Object Library are stored in:
$SOA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary
ExtensionServiceLibrary
All the concrete WSDLs pointing to mirror servlet are stored in:
$SOA_HOME/AIAMetaData/AIAComponents/ExtensionServiceLibrary
The folder structure convention followed is:
ExtensionServiceLibrary/<Application Name>
The possible values for <Application Name> are described in the Examples 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:
$SOA_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:
$SOA_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 section below:
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:
$SOA_HOME/AIAMetaData/AIAComponents/UtilityArtifacts
The folder structure convention followed is:
UtilityArtifacts/schemas
UtilityArtifacts/wsdls
To change an existing file:
To create a file:
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.
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.
To add a new property to AIAConfigurationProperties.xml:
This file is the template of the email notification sent as a part of the Error Handling Framework.
To modify the AIAEHNotification.xml:
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 Working with DVMs and Cross-References.
The DVMs are used by all the AIA Pre-Built Integrations and are shipped as part of SOA Core Extension. They are stored in $SOA_HOME/AIAMetaData/dvm.
To modify the Domain Value Maps:
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 Developing SOA Applications with Oracle SOA Suite.
The Cross Reference meta information as used by all the AIA Process Integration Packs are shipped as part of SOA Core Extension and are stored in $SOA_HOME/AIAMetaData/xref.
To modify the Cross Reference metadata:
The default fault policy file "fault-bindings.xml" is shipped as part of SOA Core Extension and is stored in $SOA_HOME/AIAMetaData/faultPolicies/V1.
To modify the "fault-bindings.xml":
Note:
Repeat this procedure every time a file is added to MDS.
To update SOA-MDS > apps/AIAMetaData:
Browse to the folder at $SOA_HOME/aia_instances/$INSTANCE_NAME/bin.
Source the file aiaenv.sh by executing the following command:
source aiaenv.sh
Browse to the folder at $SOA_HOME/aia_instances/$INSTANCE_NAME/config and open the deployment plan file, UpdateMetaDataDP.xml.
Update the file UpdateMetaDataDP.xml by inserting include tags for each resource group that you want to add to the MDS:
To upload all the files under "AIAMetaData", add the following:
<include name ="**"/>
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.
Browse to SOA_HOME/Infrastructure/Install/config. Execute the script UpdateMetaData.xml by typing the command:
ant -f UpdateMetaData.xml
Note:
MetaData gets deleted when you uninstall SOA Core Extension. For specific instruction on how to clean the MDS after you uninstall SOA Core Extension, see "Cleaning the MDS" in Installation and Upgrade Guide for Oracle Application Integration Architecture Foundation Pack.
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.
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-1 illustrates how a requester application interacts directly with a provider application.
Figure 2-1 Example of a Requester Application Interacting Directly with a Provider Application
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 Establishing Resource Connectivity.
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 Designing and Developing Enterprise Business Services and Working with AIA Design Patterns.
For more information about different AIA service artifacts and Oracle SOA Suite components used to implement them, see 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.
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-2 illustrates how a service deployed on the middleware enables integration between the requester and the provider application.
Figure 2-2 Example of Integration Flow with Native Application Services
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 |
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-3 illustrates how a service deployed on the middleware enables the integration between the requester and the provider application.
Figure 2-3 Example of Integration Flow Leveraging Provider Services
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 |
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-4 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-4 Example Showing Canonical Model-based Virtualization
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 |
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 Using Oracle Data Integrator for Bulk Processing.
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 |
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
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 SOA Core Extension or construction of EBO. The EBO should incorporate all of the requirements needed by this integration.
Identification of the EBM from the SOA Core Extension 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.
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 Establishing the MEP of a New Process EBS, Identifying the MEP, and 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:
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:
Identify and create the EBS, if needed.
Enable the participating applications.
Construct the ABCS.
Construct the EBF.
See Designing and Constructing Enterprise Business Flows.
For more information about standard naming conventions, see Oracle AIA Naming Standards for AIA Development.
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. Designing and Developing Enterprise Business Services provides complete information on how to complete each of these tasks:
To construct an entity-based EBS:
For more information, see Designing and Developing Enterprise Business Services
For more information, see Constructing the ABCS and Completing ABCS Development.
This section discusses the steps required to enable the participating applications in your SOA Core Extension ecosystem. It also discusses the options available for managing participating applications to the AIA registry.
To enable participating applications:
Identify the service APIs that must be invoked.
Provide the WSDL to the participating applications.
Construct adapter services, if required.
This section discusses how to manage the Oracle Application Integration Architecture (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.
SOA Core Extension provides two ways to manage data in your system registry:
Systems page
SystemRegistration.xml configuration file
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:
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 |
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 |
System Type |
Provides the system type. For example, |
Application Type |
Application being run within the specified system. For example, a system type of |
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. |
Goal:
Create a systemRegistration.xml configuration file for a Project Lifecycle Workbench process integration project. Create one systemRegistration.xml file per project.
For more information about the Systems page, see How to Manage the System Registry Using the Systems Page.
Role:
Integration developer
To manage your Oracle AIA system registry using the SystemRegistration.xml configuration file:
Example 2-1 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')
/
Example 2-2 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>
Example 2-3 Sample SQL Content Extracted by AIA Deployment Driver
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-1 shows the SQL content extracted by the AIA Deployment Driver:
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-2 data provided in $AIA_INSTANCE/config/AIAInstallProperties.xml
:
Example 2-4 Sample SQL Create Code
<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>
Example 2-5 Sample Participating Application Code
<properties> <participatingapplications> <SamplePortal> <server> <soaserverhostname>adc2180948.xy.example.com </soaserverhostname> </server> ... </participatingapplications> </properties>
Example 2-6 Sample Delete Code
<AIASystemRegistration> <delete> delete from AIA_SYSTEMS where SYSTEM_CODE='SampleSEBLDPT005' / delete from AIA_SYSTEMS where SYSTEM_CODE='SamplePortalDPT005' / </delete> </AIASystemRegistration>
Each identified EBF has a corresponding business process EBS. The operations within this EBS are the entry points to EBFs.
For more information, see Designing and Constructing Enterprise Business Flows.
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 Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack.