Weblogic SAF Configuration

Weblogic SAF agents allow us to store the message  in local persistence , in case the remote server is not available.

Once the remote server is up , the SAF agents will forward the message to destination.

This will overcome the message loss issues when the destination is not available.

 Following configurations needs to be done to achieve SAF mechanism.

At Destination side.
    1. Create a JMS server
    2.  Create a JMS Module
    3. Create a Sub-deployment. Targeting to JMS server
    4. Create a JMS Topic or Queue targeting to Sub-Deployment
    5. Create a Connection Factory.

At Source Side.

   1. Create a JMS server
   2. Create a JMS Module
   3. Create a Subdeployment - Targeting to SAF Agent
   4. Create a Connection Factory
   5. Create a SAF Remote Context  (This will have a remote server URL, Login Id and Password)
   6. Create SAF Imported Destination (Use SAF Remote Context here)
   7. Create a Topic /Queue under SAF Imported Destination.
            a.  Give remote JNDI name - JNDI name of remote destination
            b.  Local JNDI Name - Local name and can be any name Ex: SAFisGood
   8.  Create a SAF Agent
             a. Select a persistence store
             b. Select Agent Type


After Completing the configuration test using following URL.

jms://host:port/SourceCF/Suffix_LocalJNDIName

SOA - FTP Adapter

SOA File / FTP Adapters enable BPEL process to exchange the files on local or remote file systems. 

Steps to Create File Adapter

• Drag and drop the file adapter component  to component pallet.
• Provide the File adapter name under Service Name
• Select Define from operation and schema (specified later) option
• select the Operation
• Read File
• Write File
• Synchronous Read file
• List Files
• Mention the physical or logical path in the next page
• Mention the Archive path if the file needs to the archived after reading 
• Select Delete file after successful retrieval option if we  need to delete the file after successful read
• Mention the type of files which needs to be processed
• Mention the file polling frequency 
• Create a schema file using existing file in the message window by clicking the settings icon
• After creating schema select finish

Difference between Read File and Synchronous Read File Operation 

Synchronous Read :  It is a synchronous operation and follow request - response paradigm.   File read is initiated by a INVOKE process.   If the file is not found then response will have null value. 

Before invoking file read , file should be present. 

Read File :  It is a waiting call and  process will be invoked by a RECEIVE process and will be polling for a file at regular interval. 

File Processing :

If we have many inbound files to process or very large files of more than 1 MB, we may need to increase the config timeout value in the transaction-manager.xml file as shown in the following example:

<transaction-timeout="30000"/>

NOTE:

• The Oracle File and FTP Adapters can also treat file contents as an opaque object and pass the contents in their original format (without performing translation). The opaque option handles binary data such as JPGs and GIFs, whose structure cannot be captured in an XSD or data you do not want to have translated.

• The Oracle File and FTP Adapters support polling multiple directories within a single activation. You can specify multiple directories in J-Developer as opposed to a single directory. This is applicable to both physical and logical directories.

• The Oracle File Adapter provides support for transferring large files as attachments. To use this feature, select the Read File As Attachment check box in the JDeveloper wizard while configuring the "Read operation." This option opaquely transfers a large amount of data from one place to another as attachments. For example, you can transfer large MS Word documents, images, and PDFs without processing their content within the composite application.

SOA Dehydration Process

Oracle BPEL Process Manager uses the dehydration store database to maintain long-running asynchronous processes and their current state information in a database while they wait for asynchronous callbacks. Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. There are two types of processes in Oracle BPEL Process Manager. These processes impact the dehydration store database in different ways.

• Transient processes: this process type does not incur any intermediate dehydration points during process execution. If there are unhandled faults or there is system downtime during process execution, the instances of a transient process do not leave a trace in the system. Instances of transient processes cannot be saved in-flight (whether they complete normally or abnormally). Transient processes are typically short-lived, request-response style processes.

• Durable processes: this process type incurs one or more dehydration points in the database during execution because of the following activities:
  • Receive activity
  • OnMessage branch in a pick activity
  • OnAlarm branch in a pick activity
  • Wait activity
  Instances of durable processes can be saved in-flight (whether they complete normally or abnormally). These processes are typically long-living and initiated through a one-way invocation. Because of out-of-memory and system downtime issues, durable processes cannot be memory-optimized. 

• An idempotent activity is an activity that can be retried (for example, an assign activity or an invoke activity). Oracle BPEL Server saves the instance after a nonidempotent activity.

Idempotent BPEL Property

A BPEL invoke activity is by default an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke activity executes, Oracle BPEL Server performs the invoke again after restarting. This is because no record exists that the invoke activity has executed. This property is applicable to both durable and transient processes.

If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated, because Oracle BPEL Process Manager sees that the invoke already executed.

When idempotent is set to false, it provides better failover protection, but at the cost of some performance, since the BPEL process accesses the dehydration store much more frequently. This setting can be configured for each partner link in the bpel.xml file.

Setting this parameter to true can significantly improve throughput. However, as mentioned previously, you must ensure that the partner's service can be safely retried in the case of a server failure. Some examples of where this property can be set to true are read-only services (for example, CreditRatingService) or local EJB/WSIF invocations that share the instance's transaction

This property has the following values:

false: activity is dehydrated immediately after execution and recorded in the dehydration store

true (default): If Oracle BPEL Server fails, it performs the activity again after restarting. This is because the server does not dehydrate immediately after the invoke and no record exists that the activity executed.

inMemoryOptimization BPEL Property

This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to true, Oracle BPEL Server keeps the instances of this process in memory only during the course of execution. This property can only be set to true for transient processes (that is, those that do not contain any middle process receive, pick, or wait activities).

The default for this property is false, which means that instances are persisted completely and recorded in the dehydration store database for a synchronous BPEL process.

When inMemoryOptimization is set to true, dehydration is deactivated, and Oracle BPEL Process Manager keeps instances in memory only. The settings for the completionPersistPolicy and completionPersistLevel properties are also examined to determine persistence behavior. The inMemoryOptimization property can improve throughput when set to true and, in conjunction with these two other properties, can minimize database growth.

BPEL - CallBack Message Handling

BPEL engine maintains all Async call back messages into database table called dlv_message. Wecan see such all messages in BPEL console call-back manual recovery area.The query being used by bpel console is joined on dlv_message and work_item tables.This query simply picks up all call back messages which are undelivered and have not been modified with in certain threshold time.

Call-back messages are processed in following steps

• BPEL engine assigns the call-back message to delivery service
• Delivery service saves the message into dlv_message table with state 'UNDELIVERED-0'
• Delivery service schedules a dispatcher thread to process message asynchronously
• Dispatcher thread enqueues message into JMS queue
• Message is picked up by MDB
• MDB delivers the message to actual BPEL process  waiting for call-back and changes state to 'HANDLED=2'

So given above steps, there is always possibility that message is available in dlv_message table but MDB is failed in delivering it to BPEL process which keeps message always in state= 0.