This post is all about how to access the SOAP headers using the mediator component in the oracle soa suite 11g.

Before looking at the steps to be followed to access the SOAP headers, first we need to understand the following things.

• SOAP Message structure (This is required to understand where actually the SOAP body message and SOAP headers reside in the entire message).
• Constructing WSDL to specify that SOAP headers will be accessed. (Without this jdeveloper design time cannot help you to build expressions using which you can access SOAP headers at run time).
• Way to populate the SOAP headers ( We will be using BPEL component to achieve this)
• Accessing the SOAP header value (We will be suing the Mediator component to achieve this).

 SOAP message structure
A SOAP message is made of an envelope and zero or more attachments..

A SOAP envelope is made of optional header and mandatory body parts..

Headers are always handled (or processed) by the intermediaries...and the
body is always handled (or processed) by the ultimate receiver..

The header is generally used for providing some contextual information, like, providing authentication related information, or providing transaction related information  etc...
 
Headers are used to represent that some special processing is required. Most of the WS-* standards use the header section to represent the special processing required . For example WS-Addresssing using this header section to represent where the ReplyTo message has to be sent.

Constructing WSDL


The following video shows how to construct the WSDL..It uses the jdeveloper tool to create and edit the WSDL file.

Way to populate SOAP headers


The following video shows how to use BPEL component to populate SOAP headers in the SOAP message.

Accessing SOAP header values
The following video shows how to access the SOAP header values in mediator.

http://jobinesh.blogspot.com/2011/03/overriding-rowqualifies-for-in-memory.html

Just run the following plsql block.

BEGIN
  FOR c IN
  (SELECT c.owner, c.table_name, c.constraint_name
   FROM user_constraints c, user_tables t
   WHERE c.table_name = t.table_name
   AND c.status = 'ENABLED'
   ORDER BY c.constraint_type DESC)
  LOOP
    dbms_utility.exec_ddl_statement('alter table ' || c.owner || '.' || c.table_name || ' disable  constraint ' || c.constraint_name|| ' cascade');
  END LOOP;
END;
/

What is the fail over feature provided by the Application Module?

The fail over feature decides when and how often passivation happens. When this feature is turned on, the application module state is turned on everytime an application module instance is returned back to the AM pool by the data control.

The advantage of this feature is that the user application state (model state), remains intact.

When should this feature be enabled/used?
This feature should be enabled only in the applications where its absolutely critical not to lose the data entered by the users at any cost.
Mostly it should be enabled, when we are dealing with a clustered environment.

When should we keep away from using this feature?
When this feature is enabled, passivation/activation happens for every request. This brings down the performance of the system . So in applications where its not critical to lose data, do no enable this feature. Especially when we are not dealing with a clustered environment then do not enable this feature.

How to enable/disable it?
This feature can be enabled or disabled by selection appropriate properties in the application module configuration on the Pooling and Scalability tab of the Business Components Configuration dialog.

 What is the default configuration?
This feature is disabled by default.