Unique Request ID in XPath

I had a requirement to generate unique 10 char ids as Request Ids. The Oracle out of the box UID’s are long 32 char ids. The longer it is, the difficult it becomes.

Custom XPath function in java which did the work for me.

  public static String getRandomUniqueId(){

    SecureRandom random = new SecureRandom();

    String id = "";

    while (id.length() !=10)

     id = new BigInteger(50, random).toString(32).toUpperCase();

  return id;

  }

Compilation error - java.lang.IllegalArgumentException: Choice Pattern incorrect,1=null,2={2},3={3},4={4},5={5}

error: !!BPELC_PA__OMIT! [0=java.lang.IllegalArgumentException: Choice Pattern incorrect,1=null,2={2},3={3},4={4},5={5}]

  

This is a generic error which gets thrown during compilation time, due to the changes in the WSDL.

In one of the scenarios if we changed the WSDL or selected DB adapter with a different but similar operation, it will automatically recreate the wsdl, which may remove any custom changes that has been added to the WSDL’s.

The wsdl earlier was a sync operation and it was modified to be an async operation. So in case you haven’t regenerated the invoke or removed the extra variable it will throw compilation error.

For eg:-

        <invoke name="Invoke1"

                partnerLink="DBRequestService"

                portType="ns10:DBRequestService_ptt" operation="insert"

                inputVariable="Invoke1_insert_InputVariable"

                bpelx:invokeAsDetail="no"/>

       

        <!--<invoke name="invokeCreateRequest" partnerLink="DBRequestService"

                portType="ns10:DBRequestService_ptt" operation="insert"

                inputVariable="inCreateRequest"

                outputVariable="outCreateRequest" bpelx:invokeAsDetail="no"/>-->

OnEvent functionality of Oracle BPEL 2.0 for parallel processing

                           One of my recent projects involved automation of account creation in multiple systems, using multiple workflow process. There was a main process which was controlling the rest of the flow. One of the requirements was to give option to admins or the super user to cancel the workflow or process flow at any point of time during their execution.

This feature was required so that in case if the Admin see’s foul play or someone trying to create a suspicious account, the support team or admins should be able to cancel or terminate the request and invalidate the changes performed by the request.

  This was an interesting use case where we can leverage the OnEvent functionality of BPEL 2.0 .In BPEL 1.1 there was option of OnMessage which has been replaced with OnEvent. Even though the name is OnEvent it is more of a service call with separate one way operation defined as part of the main service.

So if you have a Service, you can define multiple operations which can be used as part the OnEvent.

In case you want to know the status of the long running process, you can define a getProcessStatus operation which should ideally check the status parallel in the flow and send notification or asynchronous callback to return you the status. The OnEvents are all async in nature.

Couple of use cases would be to update the request details on the fly using an onEvent. Canceling and terminating the request, and in case if compensation needs to be done can handled in the onEventHandler.

   <wsdl:operation name="request">

            <wsdl:input message="client:EventTestRequestMessage"/>

        </wsdl:operation>

        <wsdl:operation name="getStatus">

            <wsdl:input message="client:EventTestStatusRequestMessage"/>

        </wsdl:operation>

        <wsdl:operation name="cancelRequest">

            <wsdl:input message="client:EventTestCancelRequestMessage"/>

        </wsdl:operation>

        <wsdl:operation name="updateRequest">

            <wsdl:input message="client:EventTestRequestMessage"/>

        </wsdl:operation>

When you select onEvent, you expectation will be to see a partnerlink which will accept a service operation or an event subscription. But in BPEL 2.0 Oracle implementation it’s only the service operation option that is available. I am not sure why they didn’t want to have event subscribers also in the parallel scope. It would have given us more options to play with EDN and have event created for different processes.

The only tricky part here is to correlate the instances, so you will need to add a unique identifier like a requestId, or combination of UserId and requestId to correlate the instances and can trigger the events.

You can always define onEvent on different scopes, so if you divide your process into multiple scopes and define OnEvents you will get multiple parallel entry points into your existing /running process, which gives you a lot of flexibility in terms of cleaning up or handling different complex scenarios.

If we design a solution with an onEvent flow for reprocessing, then the flow will come in handy for re-processing the scope again for the instances based on run time decisions. So plan ahead and have a handler for defining the logic which can interfere with the existing process flow and reach a different state of completion.

So our solution had terminate Request service exposed to the application which will trigger cancel Request OnEvent of all the participating processes there by terminating the particular request.

Hope this helps J

References:-

http://www.oracle.com/technetwork/articles/soa/jellema-events-soasuite-1902429.html

BPEL calling web services with http basic authentication+authotrization.

Recently my team had an issue where they are easily able to connect to a third party web service protected with basic authentication from SOAP UI and from OSB business service, but not from BPEL-SOA.

Whenever the service is invoked, it throws authorization error.

bpelFault><faultType>0</faultType><remoteFault xmlns="http://schemas.oracle.com/bpel/extension"><part name="summary"><summary>oracle.fabric.common.FabricException: oracle.fabric.common.FabricException: Error in getting XML input stream: https://xxxxxxx.com/incident.do?wsdl: Response: '401: Unauthorized' for url: 'https://xxxxxxx.com/incident.do?wsdl': Error in getting XML input stream: https://xxxxxxx.com/incident.do?wsdl: Response: '401: Unauthorized' for url: 'https://xxxxxxx.com/incident.do?wsdl'</summary></part><part name="detail"><detail>Response: '401: Unauthorized' for url: 'https://xxxxxxx.com/incident.do?wsdl'</detail></part></remoteFault></bpelFault>

OSB

In OSB you can create service account and in the business service add a service account which will have the service account username and password. It will work.

BPEL

In composite.xml , couple of options that were tried . The oracle.webservices.auth usually works, but in this scenario it was failing.

      <property name="oracle.webservices.auth.password" type="xs:string" many="false"> geotho </property>

      <property name="oracle.webservices.auth.username"  type="xs:string" many="false">xxxxx </property>    

or

 The below option doesn’t look like it’s supported.

      <property name="httpBasicPassword"   type="xs:string" many="false"> geotho </property>

      <property name="httpBasicUsername" type="xs:string" many="false">xxxxx </property>

Solution

But the option that worked was to set the javax.xml.ws.security.auth parameters in composite.xml for the reference.

  <property  name="oracle.webservices.preemptiveBasicAuth"  many="false"  override="may">true</property>

<property  name="javax.xml.ws.security.auth.username"  many="false"  override="may"> geotho</property>

  <property  name="javax.xml.ws.security.auth.password"  many="false"  override="may"> xxxxxxxx</property>

 <property  name="weblogic.wsee.wsat.transaction.version"  type="xs:string"  many="false">DEFAULT</property>

Eg implementation:-

 <reference name="ExternalService" ui:wsdlLocation=" ExternalService.wsdl">

    <interface.wsdl interface="http://www.geo.com#wsdl.interface(ExternalService Soap)"/>

    <binding.ws port="http://www.geo.com#wsdl.endpoint(ExternalService _incident/ExternalServiceSoap)"

                location=" ExternalService.wsdl" soapVersion="1.1">

      <property name="weblogic.wsee.wsat.transaction.flowOption" type="xs:string" many="false">WSDLDriven</property>

      <property  name="oracle.webservices.preemptiveBasicAuth"  many="false"  override="may">true</property>

      <property  name="javax.xml.ws.security.auth.username"  many="false"  override="may">geotho</property>

      <property  name="javax.xml.ws.security.auth.password"  many="false"  override="may">xxxxxxx</property>

      <property  name="weblogic.wsee.wsat.transaction.version"  type="xs:string"  many="false">DEFAULT</property>

    </binding.ws>

  </reference>

This will set the values in HTTP AUTH in soa composite reference .

Hope it helps J

Book review- Oracle SOA Suite 11g Performance Tuning Cookbook

This book covers almost all aspects of the performance tuning starting from the weblogic server to different SOA components. The highlight being detailed steps on different options available to analyze and troubleshoot the issues.

The modularization of the book is really good. The book starts with the soa infrastructure, listing the different options of monitoring the JVM’s, SOA suite and different components like bpel, rules, mediator which are actually really good. BPEL and BPMN tuning tips are already available as part of the performance guides/blogs ,but the authors have captured that as well in this book, which is good in one way so as it helps to bring all the performance tuning options together. Monitoring SOA suite, JVM Garbage collections, Platform tuning are very well covered in the book.  It was good to learn we could leverage multiple available options mentioned in the book  to monitor/troubleshoot different JVM/server issues.

          The book also covers the tuning aspects from process perspective as well as at environment level with equal importance. I recommend this book as a must read for SOA server Administrators as well as SOA Consultants, this book will help you to get most out of the SOA infrastructure. The book will make an interesting read for those people who love to take it the next level.

Link to the book @ http://bit.ly/12lrajU

Modelling osb error handling for synchronous services

Recently one of the queries I got was regarding the OSB error handling, how errors should be handled. The error handling will differ based on the communication pattern, whether the call is synchronous or asynchronous.

If the services are modeled to be synchronous it will be always useful to return a consistent error structure with a minimum of the error occurring service information, unique id w.r.t message so as to track it, unique error code, summary/details of the error. This needs to be defined properly and laid out before we start on a project. If the services are more asynchronous in nature, then it makes sense to have a common Error logging/handling/auditing framework which will receive the errors and based on any business rules can persist /notify the errors. In both approaches it is mandatory to define the Error message structure. The asynchronous can have more information whereas synchronous can be a subset of this since the caller or consumer need not be given a lot of unnecessary information related to error. The synchronous response should be more formatted to be humanly readable and no stack trace.

  In case of OSB there can be multiple proxies and you will need to control the response message flow and track it. Instead of having multiple reply points from error catch blocks it will be better to have multiple catch blocks which will Raise an Error with the error payload populated into the body. The Global catch block will do a reply with success to the caller Proxy with the body

OSB Implementation

The different stages in OSB should be segregated and defined properly. And each stage should be having Error Handler-catch block. In each catch block

Catch the error globally and Reply with success

An error should contain minimum of below listed information so that it helps in identifying/tracking the error.

ResponseStatus: "-1"

ErrorSource: Atomic service

MessageDate: "2013-08-08T15:48:13.013-07:00",

ServiceName: "Validation Service",

OperationName: ": validateRequest",

Code: "VALIDATION_ERROR-ERR103",

Summary: "Validation Failure ",

Details: "BEA-382515: oops!!! Duplicate Request Signature",

SeverityLevel: "1"

If we are having a Gateway architecture then we can evaluate the error response at the gateway, see the error code and based on that can work out appropriate error handling mechanisms.