EDI Processing with B2B in hybrid SOA Cloud Cluster integrating On-Premise Endpoints

Executive Overview SOA Cloud Service (SOACS) can be used to support the B2B commerce requirements of many large corporations. This article discusses a common use case of EDI processing with Oracle B2B within SOA Cloud Service in a hybrid cloud architecture. The documents are received and sent from on-premise endpoints using SFTP channels configured using […]

SOA Cloud Service – Quick and Simple Setup of an SSH Tunnel for On-Premises Database Connectivity

Executive Overview With the current release of SOA Cloud Service (SOACS) a common requirement often requested is to connect to an on-premise  database from the cloud SOACS instance. This article outlines a quick and simple method to establish the connectivity between the single-node SOACS instance and the on-premise database server using an SSH tunnel. Solution […]

HCM Atom Feed Subscriber using SOA Cloud Service

Introduction HCM Atom feeds provide notifications of Oracle Fusion Human Capital Management (HCM) events and are tightly integrated with REST services. When an event occurs in Oracle Fusion HCM, the corresponding Atom feed is delivered automatically to the Atom server. The feed contains details of the REST resource on which the event occurred. Subscribers who consume these […]

Fusion Applications WebCenter Content Integration – Automating File Import/Export

Introduction Oracle WebCenter Content, a component of Fusion Middleware, is a strategic solution for the management, security, and distribution of unstructured content such as documents, spreadsheets, presentations, and video. Oracle Fusion Applications leverages Oracle WebCenter Content to store all marketing collateral as well as all attachments. Import flow also uses it to stage the CSV files […]

Custom Message Data Encryption of Payload in SOA 11g

Introduction This article explains how to encrypt sensitive data (such as ssn, credit card number, etc ) in the incoming payload and decrypt the data back to clear text (or original form) in the outgoing message. The purpose is to hide the sensitive data in the payload, in the audit trail, console and logs. Main […]

How to Recover Initial Messages (Payload) from SOA Audit for Mediator and BPEL components

Introduction In Fusion Applications, the status of SOA composite instances are either running, completed, faulted or staled. The composite instances become staled immediately (irrespective of current status) when the respective composite is redeployed with the same version. The messages (payload) are stored in SOA audit tables until they are purged. The users can go through Enterprise […]

Web Service Transactions Part 2: WS-AtomicTransaction with SOA Composite calling EJB-Web Service

In the first part we have looked at web service transactions between JAX-WS web services without any SOA composite/component.

The next scenario where we will look at is a SOA composite calling the web service WsatBankTransferService deployed in part 1. (click on each image to display in full quality):

image

Enable WS-AT on the SOA domain

The installation of the 11.1.1.3 Patch Set of Oracle SOA unfortunately does not update the file policy-accessor-config.xml in the created domain or WLS instance to the required WS-AT settings.

The definition of policy interceptors is however mandatory for WS-AT to work. If you did not configure anything in policy-accessor-config.xml yourself, this means that you will need to replace your version of the file with this version. (The original file can the found here for comparison).

Rename you file to .old and copy the downloaded file to the directory. Restart the Weblogic server.

Design and Deploy the Composite

First start the Weblogic samples server and use a port different than the SOA instance. I use port 8001 for the examples WLS domain and port 7001 for the admin server where the soa domain is deployed.

Then start TcpMon – to be able to monitor the SOAP request lateron and tunnel all request from port 8081 to port 8001:

image

We will create a BPEL based SOA composite with the SOA designer.

Create a new SOA project and a new composite with a BPEL component. Choose a synchronous BPEL process type and name it like you want. 

After that, drop a web service from the resource palette into the right part of the composite editor to create a reference. Fill in the details of the WsatBankTransferService but use the port set with TcpMon. Paste the WSDL URL of the WsatBankTransferService into the form and select MANDATORY and DEFAULT for WS-AT transaction propagation and version

image

Next edit the bpel process to include a Invoke activity for “CreateAccount” using the newly created Partnerlink and pass the input parameter with an Assign activity to the invoke:

image

The result should look like:

image

Now you can deploy and test the composite, right?

No, because at this point, the BPEL component would not automatically start a transaction. To achieve this, edit the composite.xml and insert the bpel.config.transaction property like:

<component name=”WSATBPELClient”>
  <implementation.bpel src=”WSATBPELClient.bpel”/>
  <property name=”bpel.config.transaction”
       many=”false” type=”xs:string”>requiresNew</property>
</component>
<reference name=”BankAccountService”
           ui:wsdlLocation=”http://192.168.56.110:8081/WsatBankTransferService/WsatBankTransferService?WSDL”>
  <interface.wsdl interface=”http://tempuri.org/#wsdl.interface(WsatBankTransferService)”/>
  <binding.ws port=”http://tempuri.org/#wsdl.endpoint(WsatBankTransferService/WSHttpBindingIService)”
              location=”http://192.168.56.110:8081/WsatBankTransferService/WsatBankTransferService?WSDL”
              soapVersion=”1.1″>
    <property name=”weblogic.wsee.wsat.transaction.flowOption”
              type=”xs:string” many=”false”>MANDATORY</property>
    <property name=”weblogic.wsee.wsat.transaction.version” type=”xs:string”
              many=”false”>DEFAULT</property>
  </binding.ws>
</reference>

At this point it does not matter if you used “RequiresNew” or “Required”, any of the two will start a new transaction because we do not pass any to the inbound “client” partnerlink.

Now you can deploy the composite to the SOA domain.

Testing and Debugging WS-Atomic Transactions

Execute the composite in the EM Test page (http://host:7001/em)

You should see a successfully completed instance and several SOAP or https calls in TcpMon. The latest should be the SOAP request to create the account – with the same WS-Coordination Context as seen in part 1:

<env:Envelope xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”
              xmlns:wsa=”http://www.w3.org/2005/08/addressing”>
  <env:Header>
    <wsa:To>http://127.0.0.1:8081/WsatBankTransferService/WsatBankTransferService</wsa:To>
    <wsa:Action>http://tempuri.org/WsatBankTransferService/createAccountRequest</wsa:Action>
    <wsa:MessageID>urn:73432EF0A5E911DFBFAC43B9B866DC33</wsa:MessageID>
    <wsa:RelatesTo>urn:73432EF0A5E911DFBFAC43B9B866DC33</wsa:RelatesTo>
    <wsa:ReplyTo>
      <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
      <wsa:ReferenceParameters>
        <instra:tracking.ecid xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>0000Id_N1rj3n3WjLxZR8A1COuk800001X</instra:tracking.ecid>
        <instra:tracking.conversationId xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>urn:73432EF0A5E911DFBFAC43B9B866DC33</instra:tracking.conversationId>
        <instra:tracking.parentComponentInstanceId xmlns:instra=”http://xmlns.oracle.com/sca/tracking/1.0″>reference:50001</instra:tracking.parentComponentInstanceId>
      </wsa:ReferenceParameters>
    </wsa:ReplyTo>
    <ns3:CoordinationContext xmlns:ns3=”http://schemas.xmlsoap.org/ws/2004/10/wscoor”
                             xmlns:ns4=”http://schemas.xmlsoap.org/ws/2004/08/addressing”
                             env:mustUnderstand=”1″>
      <ns3:Identifier>urn:uuid:BEA1-02783739A26FB5C280E1</ns3:Identifier>
      <ns3:Expires>298000</ns3:Expires>
      <ns3:CoordinationType>http://schemas.xmlsoap.org/ws/2004/10/wsat</ns3:CoordinationType>
      <ns3:RegistrationService>
        <ns4:Address>http://192.168.56.110:7001/wls-wsat/RegistrationPortTypeRPC</ns4:Address>
        <ns4:ReferenceParameters>
          <wls-wsat:txId xmlns:wls-wsat=”http://weblogic.wsee.wstx.wsat/ws/2008/10/wsat”>BEA1-02783739A26FB5C280E1</wls-wsat:txId>
          <wls-wsat:routing xmlns:wls-wsat=”http://weblogic.wsee.wstx.wsat/ws/2008/10/wsat”>AdminServer</wls-wsat:routing>
        </ns4:ReferenceParameters>
      </ns3:RegistrationService>
    </ns3:CoordinationContext>
  </env:Header>
  <env:Body>
    <createAccount xmlns=”http://tempuri.org/”>wwewe</createAccount>
  </env:Body>
</env:Envelope>

Debugging of all WS-AT related actions on server-side can be switched on with the java command line flag

-Dweblogic.debug.DebugWSAT=true

You will see a lot of 2PC handshake requests like for example:

<WseeWsat> <BEA-224575> <WS-AT transaction id is BEA1-45D0D4EFBBE0B5C280E1 and time to live is 299,000 for transaction Name=…

<WseeWsat> <BEA-224504> <registerOperation entered with …

<WseeWsat> <BEA-224503> <Registering Durable2PC Participant

<WseeWsat> <BEA-224538> <Durable2PC WS-AT Participant created for Address

<WseeWsat> <BEA-224539> <Prepare called for Address

<WseeWsat> <BEA-224603> <Successfully created participant port

<WseeWsat> <BEA-224602> <Durable participant port placed in cache for

 

<WseeWsat> <BEA-224510> <preparedOperation Xid:

<WseeWsat> <BEA-224511> <preparedOperation exited with Notification

<WseeWsat> <BEA-224546> <Commit called for Address

<WseeWsat> <BEA-224590> <About to send commit for durable participant with Xid

<WseeWsat> <BEA-224518> <committedOperation entered with Notification

<WseeWsat> <BEA-224591> <Commit sent for durable participant with Xid

<WseeWsat> <BEA-224547> <Commit call received reply COMMITTED before wait was entered for Address

<WseeWsat> <BEA-224583> <Durable participant port removed from cache

<WseeWsat> <BEA-224584> <Durable participant XAResource removed from cache

Monitoring and Management

In the SOA Control web administration frontend, you can set or change the WS-AT settings for all endpoints. Right-click on the SOA composite and select “Service/Reference Properties”:

image

In our case, we only see the client-side composite endpoint because we do not have a SOA on the callee side.

Under “Properties” you have access to the Transaction Flow and WS-AT Version settings.

image

For the JAX-WS Webservice published on the Samples Server you can see the settings in the WLS console:

image

Navigate to the webservicesWsatSimpleEar deployment, expand the WsatBankTransferService web service and click on it. You will see the WS-AT setting under “Configuration”, “Ports”:

image

Click on any operation or the whole web service to modify this:

image

You can also verify the WS-AT setting in the WSDL on the web service:

If you look at the WSDL then you see for every binding the attached WS-AT policy:

<operation name=”createAccount”>
   <wsp:PolicyReference URI=”#WSAT10″/>

This scenario was a single operation “CreateAccount”. In the next part we will create a sample using 2 SOA composites being called by another composite in one atomic transactions. Both callees use DBAdapter, so we can play around with rollbacks easily.

Stay tuned!

Troubleshooting

If you receive the following exception when testing the composite, then you did not copy the new policy-accessor-config.xml

Caused by: javax.xml.ws.soap.SOAPFaultException: transaction context is required to be inflowed at oracle.j2ee.ws.client.jaxws.DispatchImpl.throwJAXWSSoapFaultException(DispatchImpl.java:955) at oracle.j2ee.ws.client.jaxws.DispatchImpl.invoke(DispatchImpl.java:750) at oracle.j2ee.ws.client.jaxws.OracleDispatchImpl.synchronousInvocationWithRetry(OracleDispatchImpl.java:234) at …