How to Set a Timeout for a Web Service in SOA 11g ?

In 11g SOA we don't have anymore the "Timeout" property that we can put in Web Service invocations to set a maximum wait time in a sync BPEL invocation - so the solution presented inSetting a Timeout for a WebService invocation in BPELwill not work anymore in BPEL 11g.

I will explain below how to set a TIMEOUT on a Web Service invocation when using SOA 11g . This can only be used when only Web Service invocation is made through HTTP.

1. For a process that invokes a Web Service, we want to set a timeout of maximum 10 seconds that the SOA application will wait for the answer. If no response is received within the specified timeout, then we want to catch the timeout error and perform a series of other activities.

The sample below is for a BPEL in a SOA Composite - it will work the same way with Mediator as the timeout is set incomposite.xml file and not in some specific BPEL file .

2. Let's say the SOA composite looks like this:

3. Click on "Service1" and note that the property inspector will open in the lower right side of your JDeveloper window. Here set the property :

oracle.webservices.httpReadTimeout = 10000 (in MiliSeconds)
If the Web Service is on the same domain as the SOA Composite , you will also have to set :

oracle.webservices.local.optimization = false

By default the local optimization is TRUE and when a SOA composite invokes another SOA composite within the same Weblogic (WLS) server or cluster of WLS servers bypasses the whole SOAP stack, and makes a direct java call to optimize the invocation .

You may set these properties directly in composite.xml

<reference name="Service1"
ui:wsdlLocation="http://localhost:8001/soa-infra/services/default/Child!1.0/Child.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/test/Child/Child#wsdl.interface(Child)"/>
<binding.ws port="http://xmlns.oracle.com/test/Child/Child#wsdl.endpoint(child_client_ep/Child_pt)"
location="http://localhost:8001/soa-infra/services/default/Child!1.0/child_client_ep?WSDL">
<property name="oracle.webservices.local.optimization">false</property>
<property name="oracle.webservices.httpReadTimeout" type="xs:string" many="false">10000</property>
</binding.ws>
</reference>

4. This timeout will throw a RemoteFault - so you can easily add a Catch to your BPEL code to catch this error.

5.Now deploy the composite and run it from EM page . The Web Service we are calling takes 40 seconds to complete , but we set the timeout to 10 seconds - note that the Remote Fault occurs after 10 seconds.

XSLT LOOKUP

Loopup info



<xsl:stylesheet version="1.0" xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20" xmlns:mhdr="http://www.oracle.com/XSL/Transform/java/oracle.tip.mediator.service.common.functions.MediatorExtnFunction" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable" xmlns:oraext="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dvm="http://www.oracle.com/XSL/Transform/java/oracle.tip.dvm.LookupValue" xmlns:tns="http://com.ge.cis.oraclesoa/UP_Inbound_Poller" xmlns:hwf="http://xmlns.oracle.com/bpel/workflow/xpath" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ns0="http://com.ge.cis.oraclesoa/validate/xml" xmlns:med="http://schemas.oracle.com/mediator/xpath" xmlns:ids="http://xmlns.oracle.com/bpel/services/IdentityService/xpath" xmlns:bpm="http://xmlns.oracle.com/bpmn20/extensions" xmlns:xdk="http://schemas.oracle.com/bpel/extension/xpath/function/xdk" xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" xmlns:xref="http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ora="http://schemas.oracle.com/xpath/extension" xmlns:ns1="http://www.com.ge.cis.oraclesoa/validation/nxml" xmlns:lookup="http://www.com.ge.cis.oraclesoa/sampletype/lookup" xmlns:socket="http://www.oracle.com/XSL/Transform/java/oracle.tip.adapter.socket.ProtocolTranslator" xmlns:ldap="http://schemas.oracle.com/xpath/extension/ldap" exclude-result-prefixes="xsi xsl tns nxsd xsd ns0 bpws xp20 mhdr bpel oraext dvm hwf med ids bpm xdk xref ora socket ldap lookup">
   <lookup:definitions>
      <term name="UP4S">OIL</term>
      <term name="UP2S">OIL</term>
      <term name="UPAC">AIR_COMPRESSOR</term>
      <term name="UPCW">COOLANT_WATER</term>
      <term name="UPGL">GLYCOLE_BASED_COOLANT</term>
   </lookup:definitions>
   <xsl:key name="sampletype_lookup" match="lookup:definitions/term" use="@name"/>
   <xsl:variable name="definitions" select="document(&quot;&quot;)//lookup:definitions"/>
   <xsl:template match="/">

.....
...
.....



Function to be used is


                  <SAMPLE_TYPE>
                     <xsl:variable name="sampletype">
                        <xsl:value-of select="/tns:SMTP/tns:Data/tns:SAMPLE_TYPE10"/>
                     </xsl:variable>
                     <xsl:for-each select="$definitions">
                        <xsl:value-of select="key(&quot;sampletype_lookup&quot;, $sampletype)"/>
                     </xsl:for-each>
                  </SAMPLE_TYPE>

Using JDeveloper with Subversion

Introduction

Subversion is a powerful, open source version control system designed as a replacement for the popular Concurrent Versions System (CVS).  It offers many enhancements to CVS, such as versioned directories and metadata, and is architected for simpler, more flexible network access.  Oracle offers an extension to the JDeveloper IDE, which automates much of the manual work involved with interacting with Subversion.  For a rigorous introduction to Subversion, consult "Version Control with Subversion" at http://svnbook.red-bean.com/.

This guide takes you through the necessary steps to install Subversion and configure JDeveloper for use with it.  You will then be taken through some common scenarios encountered when working with Subversion in JDeveloper.

Installing the JDeveloper Subversion VCS extension

The JDeveloper Subversion VCS extension is based on JDeveloper production version 10.1.3.0.4.  You will need either the J2EE or Studio Edition; the Java edition will be supported in a future version.  If you have not already done so, download and install JDeveloper 10.1.3 (J2EE or Studio) fromhttp://otn.oracle.com/products/jdev.

The JDeveloper Subversion VCS extension is available via the official Oracle update center. You install updates using the Check for Updates feature available from the Help menu:

Using the Check for Updates wizard, search the Official Oracle Extensions and Updates center:

Locate and select the Subversion VCS Extension entry.  Selecting this will automatically select the VCS Framework Extension update too.

Proceed to the download stage:

After downloading the updates, you will see a summary page with information similar to the following:

On completion of this wizard, you may be asked whether you want to automatically restart JDeveloper:

Choose "Yes".

When JDeveloper has restarted, open the Versioning menu, choose Select Version System and then Subversion.

If configuration was successful, you will see a status message below the structure pane:

Assuming success, view the preferences for Subversion to check that the JavaSVN client library has been installed as expected: Open the Preferences dialog ( Tools > Preferences) and in the left pane select Versioning | Subversion.

With the extension correctly installed, you will see something like:

Connecting to a Subversion repository

The Subversion repository holds all of your versioned data.

If you have previously been using Subversion as your versioning system, you will already have a repository that you can connect to through JDeveloper. In the Subversion Navigator ( View > Subversion Navigator), right-click the Subversion node and select New Repository Connection. In the Create Subversion Connection dialog, enter the repository location, using an appropriate access method protocol ( http://, https://, svn://, svn+ssh://). You can also use the file:/// protocol, but to do so you will need to install additional software, as explained in Appendix B.

TIP: If you want to follow the examples given in this Developer's Guide, you will need to install a local Subversion repository named c:/svn-repos and connect to it using the svn:// protocol. The JDeveloper Subversion VCS extension will allow you to install a local repository if you also have separate Subversion client software installed. See Creating a local Subversion repository.

If you want to save the details of your Subversion repository connections so that you can use them later or on another machine, you can export them to a text file. You can then recreate the connections by importing the details from the file. To export, right-click the Subversion node in the Subversion Navigator and choose Export Connections. Complete the Export Subversion Connections dialog, then click OK. To reimport connection details from a file, right-click the Subversion node and chooseImport Connections. Through the Import Subversion Connections dialog, browse to the file that contains the connection details that you wish to import, then click OK.

Importing JDeveloper projects into Subversion

To provide examples to use with this guide, create a new Java application and project, with one Java package and two simple Java classes. Specify the location of the project as c:\jdev1013\jdev\mywork\test.

Files (such as these) that you have created in JDeveloper before using Subversion control must be imported into the Subversion repository, and then checked out from it. These checked out files become your "working copies".

You import existing JDeveloper projects using JDeveloper's Import to Subversion wizard.

Before you begin, you need to know the location of the Subversion repository where you would like to store your JDeveloper projects. For the example used in this guide, a URL is used, as follows:

svn://localhost/

Another piece of information that could be useful is the location of the directory that holds your JDeveloper application, although this will be set from the context in which you invoke the wizard. For the example used in this guide, this is:

c:\jdev1013\jdev\mywork\test

Launch the wizard by right-clicking the JDeveloper application or project that you want to import (in this example, TestApplication), then selecting Versioning > Import Files. This opens the Import to Subversion wizard .

On the Destination page, make sure that the Repository Connection box contains the URL (or connection name, if you gave it one) for the repository that you created earlier:

In general, you should select the location in the repository you want to import to. For the purposes of this guide, you created a new, empty, repository so for now you can leave the Path selection as 'root'.

On the Source page, make sure that the Source Directory box contains the location of the directory that holds your JDeveloper application which, for the example in this guide, should be:

You do not have to make any changes on the Filters page.

On the Options page make sure that the Perform Checkout box is selected:

Complete the import by clicking Finish.

Unfold the TestApplication node and the nodes beneath it to see this view.

Because you allowed the wizard to check out the imported files, the files are shown in the navigator, and they have a version number next to them.

In Subversion, the version number refers to the entire repository, not to individual files within it. A version number next to a file therefore represents the latest revision in which that file was modified. Upon import into a new, empty repository, all files will have their version number set to "1". When importing into a prepopulated repository, a version number will be assigned depending on the existing contents of the repository, but will be the same for all the newly imported files.

In JDeveloper, you can see the version information for a file by right-clicking it in the Application Navigator and choosing Versioning > Properties.

If you have set the preference to show navigator state overlay icons (see Tools > Preferences | Versioning | Subversion | General) you will also see small symbols indicating the version status of the files. For example, an orange circle indicates that a file is unmodified since it was last updated from the repository.

The files now visible in the Application Navigator are your Subversion "working copy" files and are ready to be worked on.

Checking out files

"Checking out" is a task you perform when you wish to create the initial local copies of files and folders that are being stored within a Subversion repository. It is these local copies, stored outside the Subversion repository, that you work on.

If you have used the Import to Subversion wizard with the Perform Checkout wizard selected, the imported files will already have been checked out.

As an example of checking out files independently of the import operation, in the Subversion Navigator, right-click the connection node (in the example, svn://localhost) and select Check Out. Confirm that you want to check out from the root. A location for the checked out files is suggested. To avoid confusion with the files checked out as part of the import operation, change the destination to c:/work and click OK.

The files that you checked out of the Subversion repository will now appear in the Application Navigator, with a version number next to them.

Adding and committing files

When you create new files within JDeveloper, you must add them to Subversion control if you want to use versioning features with them and if you want to make them available to other developers. You do this by using JDeveloper's Add command, followed by the Commit command.

In the Application Navigator, create a new Java file, Class3.java, as part of your versioned application.

You will see that the navigator icon for the new file is a diagonal white cross on a blue background. This indicates that the file is currently unknown to the version control system and that you should add it.

Before doing so, take a look at a JDeveloper tool that will help you keep track of any changes that should be made to the repository. If you do not already have the Pending Changes window open, open it by selecting Versioning > Pending Changes. The Candidates tab of this window will be orange, indicating that it contains a change that you have not yet seen. Click on the tab and note that the file you created, Class3.java, is listed with the status of "Not versioned".

You can add Class3.java to Subversion control from here. In a future release, the Pending Changes window will also tell you whether changes have been made to the file in the repository, giving you the chance to update your local copy if you wish to.

To add Class3.java to Subversion control, do one of the following:

• Select it in the Application Navigator and choose Versioning > Add.
• Right-click it in the Pending Changes window and choose Add.
• Select it in the Pending Changes window and click the Add icon .

Any of these methods will open a dialog box through which you confirm that the file should be added. Once added, the navigator icon changes to a small black cross:

This indicates that the file is known to Subversion but is not yet part of the repository. To make the file part of the repository you use JDeveloper's Commit command: select Class3.java in the Application Navigator and choose Versioning > Commit. This opens the Commit Resources dialog. You should definitely use the Comments box in this dialog to describe actions that you carry out on the file. In this case, you could add the comment "Initial commit of Class3.java". These comments will be visible when you view the versioning history of a file, and will help you and other developers on the project to identify one version from another.

TIP: In a live development environment, to avoid unnecessary conflicts and the subsequent work in resolving them, you should update your files before committing them.

Updating files

"Updating" is the process of bringing your local files up to date with those in the Subversion repository. You would do this because another developer has committed his changes to the repository. You can update your files using JDeveloper's Update command.

You will know that there is a more up-to-date version of a file in the repository when you attempt to commit your local version of it. A message will be shown and you will not be able to proceed with the commit.

You can update your entire working copy, single directories or packages, or individual files.

To update files, select them or their parent directory in the Application Navigator, then choose Versioning > Update.

• If a file can be updated without causing a conflict, the navigator icon will change to an orange circle  and the file content will be updated with content from the repository version.
• If, when a file is updated, there is a conflict, the navigator icon will change to an exclamation point and the file content will be changed to show both the original content and the content from the repository. The conflicting content will be separated by conflict markers (see Resolving Conflicts).

Editing files

You can edit files from your working copy directly in JDeveloper, or by using an external editing tool. Both binary and text files can be processed by the versioning system, so you can use text editors, word processors, graphics programs, or any other tool that you would normally use.

You do not need to register that you wish to edit a file (in other words, you do not have to "obtain an edit" as you would in other versioning systems). When you make changes, Subversion automatically detects that the file has been changed, and the versioning status of the file will be updated in JDeveloper to reflect this.

TIP: To be certain that you are seeing the most up-to-date status of files in JDeveloper, click the Refresh button  on the Application Navigator toolbar.

Where more than one developer is going to be working on the same file, there has to be a system to prevent one developer's work unintentionally overwriting another's. The preferred solution to this with Subversion is the copy-modify-merge model. In this model, each developer working on a file takes a copy of it, modifies it, then merges it with the other developers' copies. This may sound as if it would cause frequent conflicts in the content, but in practice this is rarely the case. When conflicts do occur, there is an efficient process for resolving them (see Resolving Conflicts).

An alternative to the above is the lock-modify-unlock model, in which a developer locks a file, modifies it, adds it back to the repository, then unlocks it. Locking a file does not prevent another developer from working on a copy of the file: it prevents the content of that copy from being returned to the repository until the lock is removed. So there is still potential for wasted effort in this model.

The lock-modify-unlock model is more suitable for working with files in binary formats, where it is impossible to merge conflicting changes. It ensures that developers take it in strict turns to submit changes to a file.

In this release of JDeveloper, support for locking is limited to retaining locks on files that you are about to commit. You must previously have locked the files using the Subversion lock command. In a future release, locking and unlocking will be fully supported.

Retaining a lock will mean that other developers will still not be able to commit changes they made to their copies of the files.

To lock a file using the Subversion lock command, enter the following at a command prompt:

svn lock [file name] -m "[message]"

To unlock a file, use:

svn unlock [file name]

For more info please refer
http://www.oracle.com/technetwork/developer-tools/jdev/subversion-085144.html