Pseudo column's In Oracle

Definition:
Pseudocolumns are not actual columns in a table, but they behave like columns. They can be thought of as special-purpose data elements that can be used in SQL statements just as if they were part of the table, but are not actually contained in a table. Essentially, a pseudo-column is an Oracle assigned value used in the same context as an Oracle Database column, but not stored on disk. 
You can select values from a pseudocolumn but you cannot INSERT INTO, UPDATE, or DELETE from a pseudo-column. Pseudocolumns are allowed in SQL statements, but not in procedural statements. SQL and PL/SQL recognize the following SQL pseudocolumns, which return specific data items (this is a partial list):

• ROWID
• ROWNUM
• SYSDATE
• SYSTIMESTAMP
• UID
• USER
• LEVEL
• CURRVAL
• NEXTVAL

ROWID: For each row in the database, the ROWID pseudocolumn returns the address of the row. Oracle Database rowid values contain information necessary to locate a row:

• The data object number of the object
• The data block in the data file in which the row resides
• The position of the row in the data block (first row is 0)
• The data file in which the row resides (first file is 1). The file number is relative to the tablespace.

Usually, a rowid value uniquely identifies a row in the database. However, rows in different tables that are stored together in the same cluster can have the same rowid.
NOTE:

 You should not use ROWID as the primary key of a table. If you delete and reinsert a row with the Import and Export utilities, for example, then its rowid may change. If you delete a row, then Oracle may reassign its rowid to a new row inserted later.

Fault-policy frame work in SOA 11g

Fault-policy frame work in SOA 11g

In this post we will discuss the fault-policy framework in SOA 11g.
Conceptual wise no changes in this release when compare to 10g. But some changes are there in placing these files and etc.

First of all this framework will work only for the faults at invoke activity.
To implement fault-policy framework we have to have two xml files called fault-bindings.xmland fault-policies.xml.

A fault policy bindings file associates the policies defined in a fault policy file with the SOA composite application or the component.

A fault policy file defines fault conditions and their corresponding fault recovery actions. Each fault condition specifies a particular fault or group of faults, which it attempts to handle, and the corresponding action for it.

And these files should be created based on below XML schema.

http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/med_faulthandling.htm#BABJGAEI

We can have these xml files in the same directory as the composite.xml file of the SOA composite application or we can place it in a different location and access those by using below properties in composite.xml

oracle.composite.faultPolicyFile
oracle.composite.faultBindingFile
Ex:
<property name="oracle.composite.faultPolicyFile">oramds:/apps/components/faultpolicies/fault-Policies.xml
</property>

<property

name="oracle.composite.faultBindingFile">oramds://apps/components/faultpolicyfiles/fault-bindings.xml

</property>
Below diagram shows how BPEL process behaves when we use fault-policy frame-work.

So when we are using this framework, it takes precedence over catch and catchAll blocks in BPEL. 

Below are the sample fault-policies and fault-bindings.xml

fault-policies.xml :

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<faultPolicy version="2.0.1" id="PannPolicy1">
<Conditions>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault">
<condition>
<action ref="ora-terminate"/>
</condition>
</faultName>
<faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<action ref="ora-retry"/>
</condition>
<condition>
<action ref="ora-human-intervention"/>
</condition>
</faultName>
</Conditions>
<Actions>
<Action id="ora-terminate">
<abort/>
</Action>
<Action id="ora-retry">
<retry>
<retryCount>2</retryCount>
<retryInterval>2</retryInterval>
<exponentialBackoff/>
</retry>
</Action>
<Action id="ora-human-intervention">
<humanIntervention/>
</Action>
</Actions>
</faultPolicy>
</faultPolicies>

 fault-bindings.xml:

<?xml version="1.0" encoding="UTF-8"?>

<faultPolicyBindings version="2.0.1" xmlns="http://schemas.oracle.com/bpel/faultpolicy"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

<composite faultPolicy=" PannPolicy 1"/>

<component faultPolicy=" PannPolicy 1 ">

<name>TestProcess</name>

</component>

<component faultPolicy=" PannPolicy 1 ">

<name>SecondProcess</name>

</component>

</faultPolicyBindings>

Infault-policies.xml condition section, we can have actions based on the evaluation of fault-variable available on the fault. Like below.

<condition>

<test>$fault.code="ABC Error"</test>

<action ref="ora-terminate"/>

</condition>

Some predefind actions were provided by oracle are:

retry

human-intervention

replay

rethrow

terminate

javaAction

We will see how to use custom java code in fault-policy framework in coming posts.