Saturday, 24 March 2012

The Transaction Manager based on Oracle BPEL Process Manager - installation

Following are the requirements, assumptions and actions needed to install the Transaction Manager based on Oracle BPEL Process Manager.

Requirements

  1. Oracle BPEL Process Manager,
  2. JDeveloper - used when the business processes are installed,
  3. The Transaction Commiter - there is known URL at which it is/will be available.
  4. The Concurrency Control Module (optionally) - there is known URL at which it is/will be available
List of software that is used, with their Web pages is presented at Hardware and software requirements.

Installation steps

Installation of Transaction Manager based on Oracle BPEL Process Manager:
  1. First, installation file must be downloaded and unzipped.
  2. Then, project located in the file:Example1 directory must be imported to JDeveloper
Example1 project
Example1 project
  1. This project includes BPEL processes which initiate TC and CCM transactions. These processes should not be modified.
  2. The third BPEL process is an example that illustrates how transactional extensions can be used in the BPEL process. On the basis of this process, you can create your own BPEL process which will use the extensions in the imported project.
  3. At the end, it is necessary to modify the settings in the configuration file in the library: Example1/Example/SCA-INF/lib/mzt1.0.jar. This modification is described below, in the Configuration section.

Uninstallation

Uninstallation can be done by removing all components of the project related to the Transaction Manager. This will probably be a significant part of the project, therefore, we propose to delete the entire project and save your own processes, or other important files.

Configuration

Project can function as the Transaction Manager if it is configured correctly. Configuration consists in entering the appropriate addresses in the configuration file. These addresses are used during communication performed by extensions. Configuration file configuration.conf there is in the archive: Example1/Example/SCA-INF/lib/mzt1.0.jar. In this file, an entries that relate addresses of coordinators (TC and CCM) and initiators (which initiate transactions coordinated by TC and CCM), installed in the BProCORE environment should be updated. The addresses of the coordinators should be known after their installation. After the first deployment of the project is possible to verify the addresses of the initiators. These initiators are the business processes MZTInitiator and TFPInitiator.
The sample configuration is as follows:
Assume that MATaddr is address of the Transaction Commiter and MATport is port on which TC is listening, and that MZWDaddr is address of the Concurrency Control Module and MZWDport is port on which CCM is listening.
Then, after a standard installation of these modules, a sample configuration is as follows:
ActivationServiceAddress=http://MATaddr:MATport/axis2/services/\
    MATActivationCoordinator
StandardCoordinationType=http://cs.put.poznan.pl/itsoa/OB2-5/mat/2009/11/
E2PCServiceAddress=http://MATaddr:MATport/axis2/services/\
    MATParticipantEnhanced2PC
MzwdActivationAddress=http://MZWDaddr:MZWDport/axis2/services/\
    ActivationService
CompletionInitiateAddress=http://192.168.96.1:8001/soa-infra/\
    services/default/Example/mztinitiator_client_ep
MzwdTfpInitiatorAddress=http://192.168.96.1:8001/soa-infra/\
    services/default/Example/tfpinitiator_client_ep
Individual parameters in the configuration file have the following meaning:
ActivationServiceAddress
Address of TC activation service.
StandardCoordinationType
The standard type of coordination (not modify this value).
E2PCServiceAddress
Address of the protocol service of Enhanced2PC, used by the participant of transactions. This service is used for nested transactions.
MzwdActivationAddress
Address of CCM activation service.
CompletionInitiateAddress
Address of the protocol service of Enhanced2PC, used by the initiator of TC transactions after deployment on Oracle BPEL Process Manager (MZTInitiator business process),
MzwdTfpInitiatorAddress
Address of the protocol service of TransactionFinallizationProtocol, used by the initiator of CCM transactions after deployment on Oracle BPEL Process Manager (TFPInitiator business process).

Configure Transaction Timeout for BPEL on SOA 11g

Applies to:

Oracle SOA Platform - Version: 11.1.1.1.0 to 11.1.1.5.0 - 

Goal

During runtime you may be seeing errors in the log similar to the following:


The transaction was rolled back
or
Transaction Rolledback.: weblogic.transaction.internal.TimedOutException: Transaction timed out

The solution is typically to increase the transaction timeout for the process.  

Solution

As a general rule, you should keep the following relation between the timeout parameters:

syncMaxWaitTime < BPEL EJB's transaction timeout < Global Transaction Timeout
Note: This recommendation are ONLY applicable to Sync Processes. Additionally the default Timeout setting that comes with SOA 11g installation does not comply with this rule. You might need to adjust the setting according to your particular business needs.


1. Setting syncMaxWaitTime:

This property controls the maximum time the process result receiver will wait for a result before returning for Sync processes.

For SOA 11g R1 PS1 (11.1.1.1.0 to 11.1.1.5):
* Login into EM
* Expand SOA and right click on "soa-infra" and select: SOA Administration -> BPEL Properties
* Click on "More BPEL Configuration Properties..." link
* Locate syncMaxWaitTime and change it.


-- Alternative Method -- For SOA 11g R1 (11.1.1.1.0) ONLY:
* Take backup of bpel-config.xml, located at: /user_projects/domains//config/soa-infra/configuration/.
* Open the bpel-config.xml file.
* Edit the value for the syncMaxWaitTime property.
* Save the changes.
* Restart Oracle WebLogic Server.

Note: Since 11.1.1.2, bpel-config.xml is no longer available into the file system and therefore the only chance for modification is through EM Console.


2. Setting the transaction timeout for BPEL EJBs:

The timeout properties for the EJBs control the particular timeout setting for the SOA application, overriding the global setting specified by the JTA timeout (See step 3).


Note: Prior implement next steps, ensure to shutdown SOA managed server. Otherwise you will get errors, see following document for details Note 1271369.1




* Log into Oracle WebLogic Administration Console.
* Click Deployments.
* Expand soa-infra -> EJBs.
* Following EJBs need to be updated:
BPELActivityManagerBean
BPELDeliveryBean
BPELDispatcherBean
BPELEngineBean
BPELFinderBean
BPELInstanceManagerBean
BPELProcessManagerBean
BPELSensorValuesBean
BPELServerManagerBean
* You can change the parameter in the Configuration tab for the Transaction Timeout setting.
* Click Save.
* Save the Plan.xml to some known location
* Start SOA Managed Server



3. Setting the global transaction timeout at Weblogic Domain Level:

This property controls the transaction timeout seconds for active transactions. If the transaction is still in the "active" state after this time, it is automatically rolled back.

   * Log into Oracle WebLogic Administration Console.
   * Click Services -> JTA.
   * Change the value of Timeout Seconds (the default is 30).
   * Click Save.
   * Restart Oracle WebLogic Server.

Thursday, 22 March 2012

Application Integration Architecture

AIA has pre-built common object definitions and services. Oracle AIA is built on Oracle Fusion Middleware's market leading SOA and BPM products.
AIA provides a foundation on which to build business-process flows. AIA delivers Pre-built Integrations as either Direct Integrations (DIs) or Process Integration Packs (PIPs).
  • Direct Integrations (DIs): Pre-built integrations that manage data flows and data synchronizations between Applications.
  • Process Integration Packs (PIPs): Help optimize processes; they are pre-built composite business processes across enterprise Applications. They allow companies to get up and running with core processes quickly. AIA and PIPs decrease software development time. PIPs operate both horizontally and vertically. Vertical PIPs cater to industries like telecoms, retail, and banking/insurance.
Oracle AIA for Communications provide end-to-end, integrated business processes, applications, and technology for the Telecom industry. Oracle AIA for Communications provide three PIPs -
Order to Bill PIP - provides pre-built integration between Oracle Siebel CRM with Oracle BRM allowing for synchronization of customer, product and pricing data across these applications. Customer Service Reps (CSRs) can create accounts and submit Sales Orders which would syncchronize automatically between the CRM and Billing systems in the Business support systemBSS eco-system.
Order to Activate PIP - provide support for Lead to Cash and Concept to Market eTOM business processes by expediting the introduction of new product offerings, capturing and fulfilling orders efficiently and accurately, managing fallouts, and providing visibility across the entire order lifecycle. This is a part of the RODOD framework and typically spans across the following Oracle products - Siebel, BRM, AIA, OSM COM and OSM SOM. This PIP journeys the BSS as well as the OSS components.
Agent Assisted Billing Care PIP - provides pre-built integration for integration between Oracle Siebel CRM with Oracle BRM including usage and billing data maintained within Oracle BRM. This empowers CSRs to resolve billing queries faster, improving customer satisfaction.

Wednesday, 14 March 2012

FAULT POLICY IN SOA 11G


Fault Policy Overview


* Since 10.1.3.3
* Catches all faults from an invoke activity (both run time and business faults)
* Important: overrides all catch activities in BPEL process.
* A fault policy defines conditions and their corresponding fault recovery actions.
* Fault policies are defined in multiple files under directory:
- bpel\domains\default\config\fault-policies
* XSD files are:
- bpel\system\xmllib\fault-policy.xsd
- bpel\system\xmllib\fault-policy-binding.xsd
* A fault policy can be associated at the following levels:
- Partner link
- Port type
- Process level via bpel.xml
- Domain level via fault-bindings.xml
* Fault policy binding order:
-> bpel.xml: partner link -> port type -> process
-> domain: partner link -> port type -> process
-> Catch blocks defined in bpel diagram.

SOA Fault Types

Business Faults

* Programmer defined.
* Defined in WSDL.

Runtime Faults

* Predefined, e.g.
- remoteFault
- bindingFault
* Infrastructure faults, e.g.
- Service down
- Network outage
* Data format errors

Design a Fault Policy

Create a Fault Policy File

* Create policy file (e.g. my-policies.xml) in bpel\domains\domain_name\config\fault-policies directory

Define conditions

* Conditions are based on faultName. e.g.
 
<faultName
  xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
  name="bpelx:remoteFault">
 
* Multiple conditions are allowed for a single faultName
- if so, conditions are evaluated sequentially
 
  <condition>
    <test>$fault.code/code="WSDLReadingError"</test>
    <action ref="ora-terminate"/>
  </condition>
  <condition>
    <action ref="ora-java"/>
  </condition>
 
* Each condition has
- one test section which is an XPath expression against fault variable
 
    <test>$fault.code/code="WSDLReadingError"</test>
 
- one action section which references to the action defined in the same file
 
    <action ref="ora-terminate"/>
 
- No test condition catches all
 
<condition>
  <action ref="ora-rethrow"/>
</condition>
 
- No faultName catches all faults
 
<faultName > . . . </faultName>
 

Define actions

* See examples below.

Fault Policy Examples

* Conditions
 
<Conditions>
  <!-- when bpelx:remoteFault, retry -->
  <faultName
    xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
    name="bpelx:remoteFault">
    <condition>
      <action ref="ora-retry"/>
    </condition>
  </faultName>
 
  <!-- when bpelx:bindingFault, rethrow fault -->
  <faultName
    xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
    name="bpelx:bindingFault">
    <condition>
      <action ref="ora-rethrow-fault"/>
    </condition>
  </faultName>
</Conditions>
 
* Actions
 
<!-- retry Action -->
<Action id="ora-retry">
  <retry>
    <retryCount>8</retryCount>
    <retryInterval>2</retryInterval>
    <retryFailureAction ref="ora-terminate"/>
    <exponentialBackoff/>
  </retry>
</Action>
 
<!-- replayScope Action -->
<Action id="ora-replay-scope">
  <replayScope/>
</Action>
 
<!-- rethrowFault Action -->
<Action id="ora-rethrow-fault">
  <rethrowFault/>
</Action>
 
<!-- humanIntervention Action -->
<Action id="ora-human-intervention">
  <humanIntervention/>
</Action>
 
<!-- abort Action -->
<Action id="ora-terminate">
  <abort/>
</Action>
 
<!-- Custom Java Action -->
<Action id="ora-java">
  <javaAction className="mypackage.myClass"
    defaultAction="ora-terminate"
    propertySet="propSet1">
    <returnValue value="R_TRM"
      ref="ora-terminate"/>
    <returnValue value="R_THRW"
      ref="ora-rethrow-fault"/>
  </javaAction>
</Action>
- Java class must implement IFaultRecoveryJavaClass interface
 
public interface IFaultRecoveryJavaClass {
  public void handleRetrySuccess(IFaultRecoveryContext ctx );
  public String handleBPELFault(IFaultRecoveryContext ctx );
}

Associate a Fault Policy

* Process level
- Configured in bpel.xml file.
- Only one fault policy can be bound to a process, port type, or partner link.
- Multiple port types or partner links can be bound to a single fault policy.
 
<faultPolicyBindings>
  <!-- Fault on any plink/port type not specified -->
  <!-- below uses policy BillingFaults -->
<process faultPolicy="BillingFaults"/>
<partnerLink xmlns:credit="http://services.otn.com" faultPolicy="CRM_
    ServiceFaults">
      <!-- Fault on these 2 plink will use policy CRM_ServiceFaults -->
      <name>UnitedLoanService</name>
      <name>StarLoanService</name>
 
    <!----Fault on these 2 port types uses policy CRM_ServiceFaults -->
<portType>credit:CreditRatingService</portType>
<portType xmlns:united="http://services.uninted.com/loan">
    united:UnitedLoanService</portType>
  </partnerLink>
<partnerLink faultPolicy="myOtherFaults">
    <!-- Fault on this plink uses policy myOtherFaults -->
    <name>AnotherPartnerLink</name>
  </partnerLink>
</faultPolicyBindings>
 
* Domain level
- Configured in OracleAS_2\bpel\domains\default\config\fault-bindings.xml file.
 
  <!-- all processes in this domain use DefaultPolicy -->
<process faultPolicy="DefaultPolicy"/>
 
 
<partnerLink faultPolicy="DefaultPolicy">
    <!-- all invoke faults at partner link creditRatingService use DefaultPolicy -->
    <name>creditRatingService</name>
  </partnerLink>
 
 
<partnerLink faultPolicy="DefaultPolicy">
    <!-- all invoke faults at specific port type use DefaultPolicy -->
<portType
      xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/insert/">db:insert_plt</portType>
  </partnerLink>
 

Human Intervention in Oracle BPEL Control

* Login BPEL console
* Click Activities tab
* Seach activities based on states
- All States: Displays all activities, regardless of their state.
- Open: Displays only open activities.
- Completed: Displays only completed activities.
- Cancelled: Displays only cancelled activities.
- Stale: Displays only stale activities.
- Pending: Displays only pending activities.
* Click the faulted activity
* Optionally change the variable values
* Select action to take
- Retry: Retries the activity with an option to provide a retry success action.
- Abort: Terminates the process instance of the faulted activity.
- Rethrow: Rethrows the exception and allows the BPEL fault handlers (catch branches) to handle the fault.
- Replay: Replays the scope in which the fault occurred.
- Continue: Skips the activity. The framework assumes the activity completed with no fault.
* Click the Recover button.

SOA11g Adapter definitions

  1. Describe adapter concepts and framework
    1. Overview
    2. Adapter Types
    3. Service Types
    4. Technology Adapters
    5. Legacy Adapters
        1. Oracle Connect
        2. Oracle Studio
    6. Packaged-Application Adapters
    7. Oracle Adapter for Oracle Applications
  2. Describe Technology adapters: File, Database, JMS, etc
    1. File/FTP Adapter
    2. Socket Adapter
    3. JMS Adapter
    4. Database Adapter
    5. AQ Adapter
    6. MQ Adapter
    7. BAM Adapter
  3. Describe Applications Adapters Ebiz suite,Peoplesoft, Siebel, etc
  4. Explain adapter run-time configuration
  5. Explain adapter design-time configuration
  6. References
This is part of 1Z0-451: Oracle SOA Foundation Practitioner Exam

Describe adapter concepts and framework

Overview

* Oracle Adapters use JCA technology to connect external systems to the Oracle SOA Suite.
* Based on open standards such as JCA, XML, WSDL.
* Assembled with SCA model.

Adapter Types

* Technology adapters
- Installed as part of Oracle Fusion Middleware.
* Legacy adapters
* Packaged-application adapters
* Oracle application adapters

Service Types

Request-Response (Outbound Interaction) Service
* Support synchronous request-response service.
* Used to:
- CRUD back-end data
- call back-end workflows and transactions

Event Notification (Inbound Interaction) Service
* Support asynchronous event-notification service.
* Listen or poll for back-end event changes.
* Used to keep track of back-end events.

Metadata Service

Technology Adapters

* Files
* FTP
* Sockets
* Database Adapter
* Java Messaging Service (JMS)
* BAM
* Advanced Queuing (AQ)
* Message Queuing (MQ) Series
* See here for details.

Architecture


Design-Time Components
* Use JDev to generate adapter metadata.
- Binding config files consist of J2CA-centric XML markup.
- Binding config files used by JCA Binding Component to seamlessly integrate the JCA 1.5 resource adapter with Oracle Fusion Middleware.


Run-Time Components
* Adapter run-time component is the JCA 1.5 resource adapter for the specific back-end application.
* Deployed in JCA container of the WebLogic Server.
* Integration with OFM is achieved through the JCA Binding Component, which converts Web service messages to JCA interactions and back. See here for more details.

Deployment
* Technology adapters are deployed as JCA 1.5 resource adapters within the same WebLogic Server container as that of OFM.
* JNDI names are used at design time with JDev. Need to setup JNDI at deployment.

Legacy Adapters

* Tuxedo
* CICS
* VSAM
* IMS/TM
* IMS/DB

Architecture
Oracle Connect
* Oracle Connect is a component that resides on the legacy and mainframe platforms.
* It consists of native adapters for communicating with the mainframe application and data stores.
* It consists of:
- Server processes: process client requests.
- Native adapters: to communicate with Tuxedo and IMS-TM txn systems.
- Daemon: RPC-based listener that manages and maintains multiple server configurations.
- Repository: one repository per Oracle Connect instance to store XML-based schema and config info.

Oracle Studio
* Oracle Studio is a design time tool for configuring the Oracle AS Adapters for mainframes.
* Enables you to configure the services, events, and connection information for native adapters.
* Enables you to do management and monitoring of Oracle Connect.
* Based on Eclipse and available on Windows platform only.

Packaged-Application Adapters

* Available as part of the OracleAS Adapters CD.

Packaged-Application Adapters
* SAP R/3
* PeopleSoft
* Siebel
* J.D. Edwards OneWorld

Architecture

Oracle Adapter for Oracle Applications

* a.k.a E-Business Suite Adapter

Describe Technology adapters: File, Database, JMS, etc

* See here for a list of adapter related books.
* Provides comprehensive, bidirectional, multimodal, synchronous, and asynchronous connectivity to Oracle Applications.

File/FTP Adapter

Supported operations
* Read File
* Write File
* Synchronous Read File
* List Files

Features
* File formats
- XML
- Delimited
- Fixed positional
- Binary
- COBOL Copybook data
- opaque (e.g. JPEGs)
* FTP Servers
- Supports most RFC 959 compliant FTP servers on all platforms.
- Supports SFTP server version 4 or later.
* Inbound and outbound interactions
* File debatching: publish messages in a specific number of batches.
* File ChunkedRead: uses an invoke activity within a while loop to process the target file (usually large file).
* File Sorting
- Use a synchronous operation
- Add the following property to the inbound JCA file:
 
<property name="ListSorter" value="oracle.tip.adapter.file.inbound.listing.TimestampSorterAscending"/>
<property name="SingleThreadModel" value="true"/>
 
* Dynamic outbound directory and file name specification.
* Security
* Nontransactional
* Proxy support:
- make sure proxy server supports FTP traffic through HTTP connection.
- only passive data connections are supported.
* No payload support
- select Do not read file content option.
* Large payload support
- select Read File as Attachment option.
* File based triggers
* pre-processing and post-processing of files
- Use pipeline and valves
* Error handling
* Threading Model
- default threading model:

- modified threading model: single threaded model, partitioned threaded model.
* Performance tuning
- use knobs to throttle the inbound and outbound operations.
- see here for more details.
* High availability
* Multiple directories
- Process files recursively
- Use ignoreListingErrors property to ignore folder permission issues.
* Append mode
- Not supported for SFTP scenarios
* Securing Enterprise Information System Credentials
- Use WebLogic Admin Console to config.

Socket Adapter

* Used by Mediator and BPEL to read and write data over TCP/IP sockets.
* Oracle Socket Adapter is a JCA 1.5 compliant adapter for modeling standard or nonstandard protocols for communication over TCP/IP sockets.
* You can use an Oracle Socket Adapter to create a client or a server socket, and establish a connection.
* The data that is transported can be text or binary.
* Communication modes:
- Inbound synchronous request/response
- Outbound sync request/response
- Inbound receive
- Outbound invoke

JMS Adapter

* Is based on JMS version 1.0.2b
* Is a generic Oracle JMS Adapter (works with any JMS provider).
* Supports JMS topics and queues.
* Supports byte, text, and map message types.
* Supports JMS headers and properties.
* Supports jca.message.encoding property.
* Supports the JMS message selector.
* Is DOM2 compliant.
* Supports normalized message.
* Supports specifying a durable JMS subscriber.
* Supports persistent and nonpersistent modes of a JMS publisher.
* Support three JMS types of acknowledgments:
- DUPS_OK_ACKNOWLEDGE
- AUTO_ACKNOWLEDGE
- CLIENT_ACKNOWLEDGE
* Supports tracking message size.
* Supports MapMessage Data Type.
* Supports Enterprise Information System (EIS) Credentials.
* Supports Streaming Large Payload.
* Supports Transactions.
* Supports Error Handling.
* Supports Multiple Consumer Threads.
* Supports Performance Tuning
* Does not support connection retry functionality for MQ provider.
* Does not support outbound retry functionality for AQJMS on Solaris.

Database Adapter

* Enables Oracle SOA Suite and Oracle Fusion Middleware to communicate with database end points.
* Is a JCA 1.5 connector, which runs on the Oracle Application Server.
* Relies on an underlying JDBC connector/driver to enact the database communication.
* Non-programmatic (unlike JDBC).

AQ Adapter

* The Oracle AQ Adapter is both a producer and a consumer of AQ messages.
* The enqueue operation is exposed as a JCA outbound interaction.
* The dequeue operation is exposed as a JCA inbound interaction.
* The Oracle AQ Adapter supports ADT (Oracle object type), XMLType, and RAW queues as payloads. It also supports extracting a payload from one ADT member column.

AQ Adapter Features
* Enqueue-Specific Features (Message Production):
- Correlation Identifier which can be used to retrieve specific messages.
- Multi-consumer Queue.
- Message priority.
- Time specification and scheduling (delay interval and expiration time).
* Dequeue and Enqueue Features:
- Poll option.
- Notification option.
- Mutliconsumer queue.
- Navigation of messages for dequeuing (use correlation id as dequeue order).
- Retries with delays (message is moved to exception queue if retries failed).
- Rule based suscription.
- Oracle AQ Adapter header properties.
- Dequeue condition.

MQ Adapter

* The Oracle MQ Series Adapter enables applications to
- connect to MQ Series queue managers
- place MQ Series messages on queues
- or remove MQ Series messages from queues.
* The Oracle MQ Series Adapter provides all native MQ Series functionalities:
- Supports Positive Action Notification (PAN) and Negative Action Notification (NAN).
- Supports report messages such as confirmation on delivery, confirmation on arrival, exception report, and expiry report.
- Supports sending unwanted or corrupted messages to a dead-letter queue.
- Provides advanced filter options, such as filtering message belonging to a group.
- Faster and easier to use than Oracle JMS Adapter.

Friday, 9 March 2012

AIA Error Handling :How to Send Error Notification to the users


I will cover the steps required to enable/send error notifications in this post. AIA Error handling framework has out-of-the-box error email functionality. Incase of partner link errors like remote/binding faults the fault-policy.xml file should take care of sending the error notification/email. Incase of non-partner link error the AIAAsyncErrorHandlingBPEL process is called from catch-all block which inturn sends out the error email.

A sample fault-policy.xml file is shown below
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<!--?xml version='1.0' encoding='UTF-8'?-->
<conditions>
<faultname xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<action ref="aia-ora-java">
</action></condition>
</faultname>
<faultname xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault">
<condition>
<action ref="ora-retry">
</action></condition>
</faultname>
</conditions>
<actions>
<action id="ora-retry">
<retry>
<retrycount>3</retrycount>
<retryinterval>2</retryinterval>
<exponentialbackoff>
<retryfailureaction ref="aia-ora-java">
</retryfailureaction></exponentialbackoff></retry>
</action>
<action id="ora-terminate">
<abort>
</abort></action>
<action id="default-replay-scope">
<replayscope>
</replayscope></action>
<action id="default-rethrow-fault">
<rethrowfault>
</rethrowfault></action>
<action id="default-human-intervention">
<humanintervention>
</humanintervention></action>
<action id="aia-ora-java">
<javaaction classname="oracle.apps.aia.core.eh.CompositeJavaAction" defaultaction="ora-terminate">
<returnvalue value="REPLAY" ref="ora-terminate">
<returnvalue value="RETHROW" ref="ora-rethrow-fault">
<returnvalue value="ABORT" ref="ora-terminate">
<returnvalue value="RETRY" ref="aia-ora-retry">
<returnvalue value="MANUAL" ref="ora-human-intervention">
</returnvalue></returnvalue></returnvalue></returnvalue></returnvalue></javaaction>
</action>
</actions>
<properties>
</properties></faultpolicy>
</faultpolicies>

In above file, the oracle.apps.aia.core.eh.CompositeJavaAction class file gets invoked when remote/binding fault occurs and takes care of sending the error notification to AIAIntegrationAdmin user.

A sample code for populating EBM Header in catch-all block is shown below

1. First create a variable named EBM_HEADER
<variable name="EBM_HEADER" element="ns3:EBMHeader"/>

ns3 here refers to corecom namespace.

2. Make sure your ABM_to_EBM.xsl or EBM_to_ABM.xsl are populating the EBM header section correctly (eg. EBMID, EBOName etc...)

3. In catch-all block make sure you are populating the EBM_HEADER before invoking the AIAAsyncErrorHandlingBPELProcess
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
<assign name="Assign_Fault">
           <copy>
            <from expression="ora:processXSLT('xsl/EBM_to_Fault.xsl',bpws:getVariableData('EBM_HEADER'))"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault"/>
          </copy>
          <copy>
            <from expression="ora:getFaultAsString()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultMessage/ns3:Text"/>
          </copy>
          <copy>
            <from expression="xpath20:current-dateTime()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:ReportingDateTime"/>
          </copy>
          <copy>
            <from expression="ora:getProcessId()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultingService/ns3:ID"/>
          </copy>
          <copy>
            <from expression="'BPEL'"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultingService/ns3:ImplementationCode"/>
          </copy>
          <copy>
            <from expression="ora:getInstanceId()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultingService/ns3:InstanceID"/>
          </copy>
          <copy>
            <from expression="ora:getECID()"/>
            <to variable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
                part="FaultMessage" query="/ns3:Fault/ns3:FaultNotification/ns3:FaultingService/ns3:ExecutionContextID"/>
          </copy>
        </assign>
      <invoke name="Invoke_AIAAsyncErrorHandlingBPELProcess" inputVariable="Invoke_AIAAsyncErrorHandlingBPELProcess_initiate_InputVariable"
              partnerLink="AIAAsyncErrorHandlingBPELProcess"
              portType="ns10:AIAAsyncErrorHandlingBPELProcess"
              operation="initiate"/>

Apart from this there are certain configurations which need to be done for successfully sending error emails.

1. Set the email driver properties from EM Console :

OutgoingMailServer :
OutgoingMailServerPort :
OutgoingMailServerSecurity :
OutgoingDefaultFromAddress:

2. In AIA_HOME/aia_instances/Instance_name/AIAMetaData/config/AIAConfigurationProperties.xml file , below properties should be set
1
2
3
<Property name="EH.INVOKE.NOTIFY">true</Property>
<Property name="FROM.EMAIL.ID">Email:AiaAdmin@oracle.com</Property>
<Property name="EH.DEFAULT.ACTOR.ROLE">AIAIntegrationAdmin</Property>

3. In User Messaging Preferences console (http://:/sdpmessaging/userprefs-ui) add email Id for user AIAIntegrationAdmin. Login to this console with AIAIntegrationAdmin/welcome1.

NOTE: Message channels are meant to be a single email address or phone number etc.But you can refer to an email distribution list if you want to send these emails to multiple persons.

4. Upload the AIAConfigurationProperties.xml file to MDS and Reload the configuration from AIA Console setup page.Make sure when you update UpdateMetaDataDP.xml for loading the AIAConfigurationProperties.xml into MDS it should look something like below:
1
2
3
<fileset dir="${AIA_HOME}/aia_instances/instance_name/AIAMetaData">
<include name="config/AIAConfigurationProperties.xml" />
</fileset>

Also if the Go buttons are not enabled on AIA Console Setup page, make sure the weblogic user has the role AIAApplicationUser associated with it. You can associate roles on the Weblogic Admin Console under Security Realms.

5. Also set Notification mode to 'Email' from 'SOA Administration' -> 'Workflow Notification Properties' in EM Console.