Demystifying getActiveUnitofWork property of DB Adpater

Here in this I am going to discuss one of the interaction options available in Database adapter configuration, getActiveUnitofWork

The property is defined in Oracle Adapter guide as below

GetActiveUnitOfWork is an advanced JCA property you can set on any DBInteractionSpec. 

It causes the invoke to register itself with the two-phase commit callbacks, and all writes to the database are performed as part of the two-phase commit. By setting this property on any failure, the transaction is automatically rolled back, as there is no way to handle a fault at this late stage. Similarly, the same underlying TopLink session is used for both invokes, meaning if you merge the same object twice, it is inserted/updated once. All merge invokes that set GetActiveUnitOfWork as true are cumulative.

Set GetActiveUnitOfWork to true when making multiple incremental changes to the same record across multiple invokes in the same SOA instance.GetActiveUnitOfWork ensures that all Database Adapter invokes which participate by setting the option to true, and which are within the same JTA transaction, and to the same eis/DB/ instance, use the same EclipseLink session for all operations. For EclipseLink-based operations (excluding stored procedures and pure SQL) all writes are deferred until JTA before Completion.

This means if you insert/merge the same object in two invokes, it is written once. Since EclipseLink-based writes are deferred, a select all may not conform to previous invokes which did writes. Selects by primary key conform, however. As writes happen inside the JTA callbacks, there is no way to handle exceptions which occur at that time and BPEL's global transaction will unexpectedly fail.GetActiveUnitOfWork is frequently used to guarantee that operations on two invokes used the same physical SQL connection.

I have performed some POCs to check the behaviour of this property and below are some scenarios

Case 1- Here in this scenario, two consecutive insert operations insert1, and insert2 are being performed to insert data in tables of a XA data source. Both operations are being performed in the same BPEL and hence the same transaction.

If getActiveUnitOfWork=false, insert1 will be committed even when insert2 fails

If getActiveUnitOfWork=true, insert1 will be rolled back when insert2 fails. As roll back fault can’t be handled using catch or catchall, instance audit trail will not be visible on em .

Note- Rollback fault in the callee BPEL can only be handled in caller BPEL if both exist in different transactions. In case of different transactions, this fault will be captured in the caller BPEL as a remote fault which can then be handled using catch block.

Case 2- In this scenario, BPEL1 has the logic of insert1, to insert data in table of a XA data source, followed by an invocation to BPEL2. BPEL2 has insert2 to insert data in table of a XA data source. Both operations are being performed in the different BPELs which can participate in both different/same transaction. Following are the possibilities explored by me-

      1)     When, bpel.config.transaction=RequiresNew

       bpel.config.oneWayDeliveryPolicy=sync

       getActiveUnitOfWork=true

       Faults are handled in both BPEL1 and BPEL2

As both BPEL 1 and BPEL2 execute in different transactions, when INSERT2 fails INSERT1 gets committed. Fault is not caught in BPPEL2. Remote fault is thrown to BPEL1 which is handled

     2)     When, bpel.config.transaction=Required

      bpel.config.oneWayDeliveryPolicy=sync

      getActiveUnitOfWork=true

      Faults are handled in both BPEL1 and BPEL2

When INSERT2 fails, INSERT1 is automatically rolled back. The rollback error can’t be handled in BPEL1 as both BPEL1 and BPEL2 are in same transaction.

     3)    When, bpel.config.transaction=Required

     bpel.config.oneWayDeliveryPolicy=sync

     getActiveUnitOfWork=false

When INSERT2 fails, INSERT1 gets committed.

If fault is not handled in BPEL2, fault of BPEL2 gets promoted to BPEL1 and can be handled in BPEL1.

I fault is caught in BPEL2, both BPEL1 and BPEL2 gets completed with only INSERT1 executed successfully.

   

   4)    When, bpel.config.transaction=RequiresNew

    bpel.config.oneWayDeliveryPolicy=sync

    getActiveUnitOfWork=false

When INSERT2 fails, INSERT1 gets committed.

If fault is not handled in BPEL2, fault of BPEL2 gets promoted to BPEL1 and can be handled in BPEL1.

If fault is caught in BPEL2, both BPEL1 and BPEL2 gets completed with only INSERT1 executed successfully.

 HAPPY LEARNING!!!!

Concept of Namespace, Default and target namespace, use of prefix

Namespace in XSD

This blog explains the concept of namespace in XML schema with help of some java concepts. I personally found that relating the concept  of namespace to java packages makes it easier to grasp and remember.

1)  Namespace in XSD and Package in java

  

The concept of namespace in XSD is very similar to the use of package in java. Package in java is used to group related classes in a single unit, to avoid naming conflicts or ambiguity.

Similarly in XSD, Namespace is used to group all the elements in that XSD as a single unit to avoid any kind of ambiguity.

According to w3 standards, A namespace should start with a protocol.

Generally http is used

eg- http://Class.school.com

2)  TargetNamespace in XSD and package declaration  in java

Package declaration in java is simple as below

Package com.school.class;

Public class Student{

}

Here Class Student belongs to the package com.school.class

similar to package declaration in java, targetNamespace in XSD is used to group all entities in that XSD in a single namespace. Placing the targetNamespace attribute at the top of your XSD schema means that all entities defined in XSD are part of this namespace. In short It is a unique identifier. Here all the entities are part of http://Class.School.com namespace.

<schema targetNamespace="http://Class.School.com"

            xmlns="http://www.w3.org/2001/XMLSchema">

            <element name="Student">

                        <complexType>

                                    <sequence>

                                         <element name="RollNo" type="int"/>

                                         <element name="Name" type="string"/>

                                    </sequence>

                        </complexType>

            </element>

</schema>

3)  Import in java and namespace declaration in XSD

When a class belongs to a package, at the time of using that class we need to use fully qualified namespace.

e.g.   Com.school.class.Student

,This however increases the overhead of using fully qualified name for the class whenever it is used. That is when import is used.

import  java.lang.*;    

class Student{  

  public static void main(String args[]){  

     

   system.out.println("Hello”);

  

 }   

}      

Similarly in XSD xmlns is used. This can be explained as below

All the entities used in an xsd (element, sequence, complexType  etc) belong to a w3 namespace "http://www.w3.org/2001/XMLSchema-instance".

Hence while writing an xsd we need to import the namespace http://www.w3.org/2001/XMLSchema-instance into the XSDas below.

<schema targetNamespace="http://Class.school.com"

            xmlns="http://www.w3.org/2001/XMLSchema">

so here http://www.w3.org/2001/XMLSchema is similar to a built in package in java e.g. java.lang. Importing this namespace enables us to use the entities declared in the namespace in our xsd. We can similarly import more than one namespace in an XSD as per our requirement.

1)  Use of prefix in XSD

Importing namespace gives birth to another concept of prefix in XSD.

A namespace declared without a prefix is called default namespace, there can be one or no default namespace in an XSD. In the above example http://www.w3.org/2001/XMLSchema is the default namespace. However the same XSDcan be modified as below

Here xs is the prefix for namespace http://www.w3.org/2001/XMLSchema .So all the entities in this namespace should be used with that prefix.

<xs:schema targetNamespace="http://Class.school.com"

            xmlns:xs="http://www.w3.org/2001/XMLSchema">

            < xs:element name="Student">

                        < xs:complexType>

                                    < xs:sequence>

                                                < xs:element name="RollNo" type="int"/>

                                                < xs:element name="name" type="string"/>

                                    </ xs:sequence>

                        </ xs:complexType>

            </ xs:element>

 </ xs:schema>

 HAPPY LEARNING!!!!

query() and queryMore() operations in Salesforce

Here in this tutorial, I am going to discuss query() and queryMore() operations in salesforce and how to invoke the same in a BPEL.

In my previous tutorials I have already discussed interaction with salesforce API using enterprise wsdl. Please refer those if you are new to use cases where salesforce has to be invoked directly.

I came across a scenario where I needed to retrieve data from a salesforce object. Query operation is a very easy way to do the same. Just a select query on the object and that is all. Please note that * is not used in sql query here. Specify all necessary field names that you want.

The query result object contains up to 500 rows of data by default. If the query results exceed 500 rows, then the client application uses the queryMore() call and a server-side cursor to retrieve additional rows in 500-row chunks.Moreover if  you are querying for fields of type Base64, both query and query more returns a single record.

query()

Executes a query against the specified object and returns data that matches the specified criteria.

query() call is used to retrieve data from an object and below are the parameters

INPUT-

   1)  queryString a query expression that specifies the object to query, the fields to retrieve, and any conditions that determine whether a given object qualifies.

 Upon invocation, the API executes the query against the specified object, caches the results of the query on the API, and returns a query response object to the client application

OUTPUT-

  1)  done

type- Boolean

value-(true/false)

Description- Indicates whether additional rows need to be retrieved from the query results (false) using queryMore(), or not (true). Your client application can use this value as a loop condition while iterating through the query results.

  2)  queryLocator

Description- A specialized string, similar to ID. Used in queryMore() for retrieving subsequent sets of objects from the query results, if applicable. 

  3)  Records

Type- sObjects []

Description- Array of sObjects representing individual objects of the specified object and containing data defined in the field list specified in the queryString

  4)  Size

Type- int

Description-Total number of rows retrieved in the query.

queryMore()

Retrieves the next batch of objects from a query()

INPUT-

  1)  queryLocator

OUTPUT-

Is same as that of query() operation.

Steps.

1) Create a SOA project with a BPEL and a reference with salesforce enterprise wsdl.

2) Invoke login operation and assign username and password 

use session id, URL retrieved as response of login operation in subsequent operations as discussed in previous tutorials

3) Invoke query operation and create input and output variables. Input and Output of query operation looks like below

4) Assign sql query as input to query() operation

5) Create variables done,QueryLocator as string. Assign done and QueryLocator returned as response of query() operation to these variables.

6) Drop a While activity and enter the condition as done='false'.

7)  Inside the while loop drop Invoke activity for queryMore operation and create input and output variables. Input and Output of query operation looks like below.

8) Assign value from QueryLocator variable to the input of queryMore operation.

9) After invoke assign done and QueryLocator returned as response of query() operation to these variables. 

Deploy and test your composite.

HAPPY LEARNING!!!!

Interact directly with Salesforce API using the Enterprise WSDL in BPEL 2.0

In my previous tutorial, I discussed the way to interact directly with Salesforce API using the Enterprise WSDL. The BPEL in the tutorial was in 1.1 version.

When I try to implement the same in BPEL version 2.0, it does not work. BPEl fault ‘fromvalue is not a sref:service-ref element’ is thrown at runtime. 

This error is related to PartnerReference variable (of enpointReference type ) which is directly assigned to the partner link. Though rest of the steps and logic remains the same,changes are only required for PartnerReference variable. Below are few changes related to this variable when trying to implement the same in BPEL 2.0

     1)  Download the ws-bpel_serviceref.xsd  and add it to your project

2) Create a variable PartnerReference of element type service-ref , which is defined in the above xsd.

3) Using append xml fragment option the following xml snippet to the above variable  PartnerReference

 <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
    <wsa:Address/>
</wsa:EndpointReference>

Make sure to declare xmlns:wsa=http://schemas.xmlsoap.org/ws/2003/03/addressing namespace in BPEL as well.

4) Now assign  the server url received as a response of login operation to, PartnerReference/ wsa:EndpointReference/ wsa:Address

5) Now assign PartnerReference variable to the partner link that is to be invoked.

HAPPY LEARNING!!!!

Interact directly with Salesforce API using the Enterprise WSDL- No Salesforce adapter

As part of Oracle Fusion Middleware 11.1.1.7, Oracle introduced the Cloud Adapter for Salesforce.com integration.

However, for complex scenarios it might be better to interact directly with Salesforce API using the Enterprise WSDL. You will need to manage the sessions (login/logout) in your custom code, but it allows you more flexibility to create a generic approach and reuse it.

Before you call the service to query or change objects, you need to call the Login operation and handle the Session ID received back, that needs to be included in any subsequent requests

Here in this tutorial I am sharing a way to interact directly with Salesforce API using the Enterprise WSDL instead of salesforce adapter.

Prerequisites:

1)  Credentials to your Salesforce.com account

     Username (in the form of an e-mail address)

     Password + Security token.

2) Download Enterprise WSDL file form Salesforce.com

3)  Import Salesforce.com Certificate into Client/Server

The Salesforce.com Client certificate has to be downloaded from the Salesforce.com application user interface. This certificate has to be imported into the client server for successful handshaking with Salesforce.com

For more information on the prerequisites, please refer to the user guide for salesforce adapter.

http://www.oracle.com/technetwork/middleware/adapters/documentation/ug-sfdcadapter-ps6-2104970-2262659.html

Create a BPEL process to invoke Salesforce

1    1) Create a SOA project with sync BPEL

 2)Another component that would be brought into the composite is a Web Service Adapter. Create it on the basis of enterprise WSDL. On the composite.xml, provide wiring between both the component.

3) Click on the BPEL to write the logic

4) In Salesforce the first operation that is invoked is the login operation. This process takes 2 inputs: ‘user name’ and ‘password’ via payload. The password is a combination of Salesforce password and the security token. Only when we are successfully able to invoke the login operation we would be able to invoke the other operations on Salesforce.

Drop an invoke activity and select Login operation from the drop down. Create input/output variables for the invocation.

5) Dropassign activity assigning values to username and password parameters, prior to the Invoke activity.

6) The output payload provides two important details using which we would precede with the subsequent operations. These are as follows:

Session ID: This ID needs to be sent as part of header information for all operations post login

ServerURL: This is the URL that needs to be called for all subsequent operations (query, update etc.) for this user.

The output of login operation provides Session ID that needs to be included in any subsequent requests to maintain the sessions.Create a SessionHeader variable of type Header.Map the session id retrieved from the login operation into this variable.

7) Configuration for Server URL: Create one PartnerReference variable in BPEL project of ‘EndpointReference’ type defined in ws addressing xsd http://schemas.xmlsoap.org/ws/20 03/03/addressing. Map the server URL received as a response of login operation to this variable, and then subsequently assign this variable PartnerReference directly to the partner link prior to invoking the second operation.

8) Drop an invoke activity and select the next operation you want to perform (create in this case).

9) In the invoke activity, select Header tab and select SessionHeader.

10) In order to assign input to CREATE operation, drop an XSLT activity to map input variable to Invoke_CreateTestObject. 

Salesforce WSDL exhibits polymorphic behavior. Records need to be substituted as actual Salesforce object as shown below

So this is how the BPEL looks like. Deploy and test the composite

HAPPY LEARNING!!!!