BPEL Persistence Properties – 11g

BPEL Persistance properties are used to control, when a process need to dehydrate. Below are the properties which we can use to control it for BPEL Component in a Composite.

inMemoryOptimization

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 (process type does not incur any intermediate dehydration points during execution).

false (default): instances are persisted completely and recorded in the dehydration store database for a synchronous BPEL process.

true: Oracle BPEL Process Manager keeps instances in memory only.

completionPersistPolicy

This property controls if and when to persist instances. If an instance is not saved, it does not appear in Oracle BPEL Console. This property is applicable to transient BPEL processes (process type does not incur any intermediate dehydration points during execution).

This property is only used when inMemoryOptimization is set to true.

This parameter strongly impacts the amount of data stored in the database (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput.

on (default): The completed instance is saved normally.

deferred: The completed instance is saved, but with a different thread and in another transaction, If a server fails, some instances may not be saved.

faulted: Only the faulted instances are saved.

off: No instances of this process are saved.

<component name="mybpelproc">

...

<property name="bpel.config.completionPersistPolicy">faulted</property>

<property name="bpel.config.inMemoryOptimization">true</property>

...

</component>

oneWayDeliveryPolicy

This property controls database persistence of messages entering Oracle BPEL Server. Its used when we need to have a sync-type call based on a one way operation. This is mainly used when we need to make an adapter synchronous to the BPEL Process.

By default, incoming requests are saved in the following delivery service database tables: dlv_message

async.persist: Messages are persisted in the database.

sync.cache: Messages are stored in memory.

sync: Direct invocation occurs on the same thread.

<component name="UnitOfOrderConsumerBPELProcess">

...

<property name="bpel.config.transaction" >required</property>

<property name="bpel.config.oneWayDeliveryPolicy">sync</property>

...

</component>

General Recommendations:

1. If your Synchronous process exceed, say 1000 instances per hour, then its better to set inMemoryOptimization to true and completionPersistPolicyto faulted, So that we can get better throughput, only faulted instances gets dehydrated in the database, its goes easy on the purge (purging historical instance data from database)

2. Do not include any settings to persist your process such as (Dehydrate, mid process receive, wait or Onmessage)

3. Have good logging on your BPEL Process, so that you can see log messages in the diagnostic log files for troubleshooting.

Listening Channel vs. Host TP Channel in Oracle B2B 11g

In 10g era of Oracle B2B, we had two kinds of channels to send/receive documents –


1. Internal Delivery Channel – IDC’s (Internal Delivery Channels) are used to enable Oracle B2B to communicate with backend applications. When I say backend, then it may be any application/product running behind Oracle B2B within same enterprise network. 

In case of an outbound flow, Oracle B2B receives documents from backend applications through an IDC and sends it to the targeted remote trading partner after required processing. 

In case of an inbound flow, Oracle B2B receives documents from remote trading partners through a Delivery Channel and sends it to backend application through an IDC. 

In Oracle B2B 10g, there were only two default IDC’s - IP_IN_QUEUE and IP_OUT_QUEUE(both are AQ’s) where as in Oracle B2B 11g, we have two more default IDC’s which are B2B_IN_Queue and B2B_Out_Queue (both are JMS) however at a time either of JMS or AQ IDC’s may be active.

2. Delivery Channel – DC’s (Delivery Channels) are used to enable Oracle B2B to communicate with remote trading partners. 

In case of an outbound flow, Oracle B2B sends the document to remote trading partner using the remote TP’s DC selected in the agreement, however in case of an inbound flow, Oracle B2B receives a document through a Host TP delivery channel. 

In Oracle B2B 10g, there is one default Host TP delivery channel – http://host:port/b2b/transportServlet and similarly in Oracle B2B 11g, we have one default Host TP delivery channel – http://host:soa_server_port/b2b/httpReceiver 



Now after brief introduction of IDC and DC let’s come back to our topic – Listening Channel vs. Host TP channel. 



Host TP Channels – Channels defined under host TP configuration can be either used as an IDC (if “internal” checkbox is checked) or it can be used as a shared delivery channel for all remote TP’s (if “internal” checkbox is NOT checked).



The first use is something which you are very familiar with, but second one is a new feature. If you mark a channel, defined under host TP configuration, as external then it serves as a common delivery channel that all remote trading partners can use as their delivery endpoints and will appear in the list of channels under the remote trading partner in the agreement(as this is considered outbound delivery channel).



Listening Channels – A listening channel listens on an endpoint for messages from remote trading partner or backend applications hence it can be used as an IDC or as a DC, depending upon the “internal” checkbox selection but in both the cases it is used to send messages to your Oracle B2B system. When a Listening Channel is marked as External (Internal checkbox not selected in the channel attributes), then it can be used by Remote Trading Partner(s) to send messages to your B2B system (Inbound). 



When a Listening Channel is marked as Internal, then it can be used by backend application(s) to send messages to your B2B system (Outbound). 



A listening channel never participates in any agreement hence it can be modified or deleted without affecting any existing deployments.



There is one more thing very important here that the channel’s marked as internal can be of “Generic Protocols” only. No internal channel can use any other protocol except “Generic” ones however Oracle B2B allows to select any protocol for an internal channel.

http://anuj-dwivedi.blogspot.sg/2010/10/listening-channel-vs-host-tp-channel-in.html

MQ Adapter Adding xmlns="" to XML

Issues:

1)   Empty namespace tags in output XML

2)   Remove encoding=”UTF-8″ (or any)

Information From Oracle Docs:

Oracle® Fusion Middleware Release Notes Section 20.1.14, "Receiving an Empty Namespace Tag in an Output Message" 20.1.14 Receiving an Empty Namespace Tag in an Output Message The XML representation from an XSL file may differ from that used in a scenario in which a message is passed through with a transformation being performed or in which an assign activity is used, even though the XMLs are syntactically and semantically the same. For example, if you use a mediator service component to map an inbound payload that includes an element without a namespace to an outbound payload, you may receive an empty namespace tag in the output message. <Country xmlns="">US</Country> This is the correct behavior. A blank namespace, xmlns="", is automatically added.  
Solution: 

 1)      In outbound XSD introduce nxsd namespace and nxsd version as well as nxsd  encoding as shown 
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:version="DTD" nxsd:encoding="UTF-8" elementFormDefault="unqualified" attributeFormDefault="unqualified">  <xsd:complexType name="SampleName"> 

2)      In outbound XSD introduce nxsd namespace and nxsd version as shown 
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:version="DTD"             elementFormDefault="unqualified" attributeFormDefault="unqualified">  <xsd:complexType name="SampleName">

RemovaNamespace XSLT

<?xml version='1.0' encoding='windows-1252'?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" exclude-result-prefixes="xsl">
   <xsl:output cdata-section-elements="WORK_ORDER_COMMENTS TASK_DESCRIPTION"/>
   <xsl:template match="comment()|processing-instruction()|/">
      <xsl:copy>
         <xsl:apply-templates/>
      </xsl:copy>
   </xsl:template>
   <xsl:template match="*">
      <xsl:element name="{local-name()}" namespace="">
         <xsl:apply-templates select="@*|node()"/>
      </xsl:element>
   </xsl:template>
   <xsl:template match="@*">
      <xsl:choose>
         <xsl:when test="name() != 'xmlns'">
            <xsl:attribute name="{local-name()}">
               <xsl:value-of select="."/>
            </xsl:attribute>
         </xsl:when>
      </xsl:choose>
   </xsl:template>
</xsl:stylesheet>