Cannot Register ESB Using JDEVELOPER if Workspace Name is Changed

I faced this problem recently in my current project.This happens when you change the workspace name for your ESB service and rebuild your project again.Refer metalink note [ID 875558.1].

The problem can be solved by maually editing *.esbsvc  files.Check wsdl urls in *.esbsvc files and give the local reference for the wsdls(.wsdl).If you rebuild your project again,cross check *.esbsvc files again.

AIA architecture

The AIA architecture is evolved upon the loosely coupled approach. To initiate the approach, an architecture that is application neutral is created between the two participating applications say something like the buffer zone. This application neutral buffer zone utilizes the industry standard data layouts and business flows.

In order to enable the applications (both requesting and responding) to interact with the industry standard data process model, we have to use a common vocabulary. To enable the loosely coupled architecture and the ease of enhancing in the future, the data definitions from the requesting and the responding applications should be translated to the standard definitions available in the framework. This translation of data from the requesting and responding applications to the standard definition is carried out by application specific translators placed on each side of the buffer.



In a loosely coupled architecture, there is an occurrence of a no: of objects being created and also there is a need for a technology to maintain these objects. The various objects and processes that are created needs to be managed so that they become visible throughout the architecture and also supports efficient re-use and extensibility.
AIA is a collection of these components and methodology guidance for creating the loosely coupled standard based integration architecture. The basic requirement of AIA is to establish a standard data and processing definition that can be understood across all the system. So AIA has this Enterprise Business Objects (EBO) and Enterprise Business Services (EBS). These EBO‘s are:
1. Application independent,
2. Extensible,
3. Provide the common vocabulary that will be used within the architecture,
4. Provide the necessary abstraction to enable integration.


EBO represent common business entities such as Customer, Sales Order, etc.
EBS is a library of standard processes and operations that interact with the EBO such as query Customer or create Sales Order albeit these services do not understand the operational vocabulary used by specific applications. Likewise the specific applications do not know the vocabulary of services and objects provided by AIA. Therefore, for the end applications to communicate, a translation to a common vocabulary must be performed which is done by AIA through the EBO. The translation from application specific terminology to EBO is done through the Application Business Connector Services (ABCS).
The ABCS process is the key to maintain the loosely coupled architecture throughout. The end applications need not be connected to be tightly coupled. The ABCS communicate with the end applications using the Application Business Messages (ABM).These messages are translated into standard messages (EBM) by the EBS. The EBM will populate all or a part of an EBO based on the message.
Since an Enterprise Business Message is assembly for schema components, extensibility would mean a new EBM. The solution is to create a new EBM xsd containing the required EBM definitions.
For example, let us say there is ItemEBM.xsd which has CreateItemEBM, UpdateItemEBM and QueryItemEBM. There is a need for DeleteItemEBM and ValidateItemEBM. To extend the ItemEBM.xsd, create a CustomItemEBM.xsd and include in it the definitions for DeleteItemEBM and ValidateItemEBM.

Setting and Getting Preferences in Oracle Fusion 11G

 Setting the Preference

As we used preferences in BPEL very often, we expeted to use this in 11g as well. But within the BPEL editor and in the SCA editor there is no button to apply preferences. the function ora:getPreference() is available, but were do we apply this preferences.

The solution is there and writtin in:

http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/bp_app_deploydesc.htm#SOASE11121

Preferences can be set at composite level and these preferences are defined at particular levels; BPEL, Partnerlink.

To use BPEL properties defined the properties in composite.xml.


<component name="BPELProcess1">

    <implementation.bpel src="BPELProcess1.bpel"/>
    <property name="bpel.preference.TestPref">TestValue</property>
 </component>

Now we can use the function ora:getPreference('TestPref') in our bpel process to retrieve the value of the preference.

Note:--This didn’t work for me until I used single quotes in the getPreference function.

Changing the value of preference from enterprise manager

In Oracle SOA Suite 11g things changed a but, we got a new fancy console to manage all the components.
To change to values from the prefences go to the ‘Enterprise Manager’ (http://localhost:7001/em).
On the left go to :
Farm_soa_domain > Weblogic Domain > soa_domain > right mouseclick and select ‘System MBean Browser’.






Navigate to Application Defined MBeans > oracle.soa.config > Server : soa_server1 > SCAComposite > your_project > SCAComposite.SCAComponent > your bpel_process.
Select the Attribute ‘Properties’.



Change the value of our preference and click apply.



 

Refer here for the list of Deployment Descriptor properties

Deployment Descriptor Properties

Setting Web Service and JCA Adapter Endpoints Dynamically in Oracle SOA Suite

Setting Web Service and JCA Adapter Endpoints Dynamically in Oracle SOA Suite (http://www.oracle.com/technetwork/topics/soa/dynamic-endpoints-100390.html).

This article describes how web services and JCA adapter end points in SOA Suite can be changed dynamically at run-time in a very similar way as the dynamic properties of WLI controls are used to change endpoint properties. The article uses the sample of a file adapter in a BPEL process and demonstrates how the output directory and the file name can be changed using header properties in the process or through the Enterprise Manager console.

Thoughts on advanced fault handling

I have a sync [req/response] bpel process that uses a jms adapter with request/reply pattern, and throw a fault based on the response from the adapter call [after the receive from the adapter plnk]. When I invoke this process I don't get the fault but after a certain time a ReceiveTimeoutException from the soa layer. Has this something to do with the threading?"
The short answer is yes it has to do with the threading model.
A jms adapter request / response pattern will cause as other dehydration points do, the original thread to be returned (and subsequently a commit, once it passed through the owner of the transaction) and a second thread [in this case an engine one] to delivery the result and continue the execution of the rest of the process.
So sequence wise - the below happens





Thread (1) -> receive (initial) -> invoke (of jms adapter plnk) -> receive (create the subscription).
Thread (2) [upon result] -> delivery [receive part2] -> throw
In this case the fault is unhandled and the original thread gone, and we don't maintain a conversation id. This is why one gets the ReceiveTimeoutException, because the DeliveryService.getResult (which waits for the result) will timeout w/o getting the fault or a result ever passed back.
In a case like this, one needs to employ the second way of throwing faults - and that's via reply, but this time not just with an output variable but rather with a faultname as well.
With that in place - his process worked.
sca_bpel-106-FaultHandling_rev1.0.jar shows this technique.


After deployment - test the "Test asynccalldurablefaultthrower_client_ep" service, and put "reply" as input. This will trigger a fault to be replied in the detail process. If you go to EM now you will see that the master is in state "recovery needed" because a fault policy kicked in.
If you try again but this time with "fault" as input - and go to EM you will see another exception - that says "Waiting for result - timed out". That originates from the "throw" in the callee process.
If you want to look into the composite yourself - just import the sar in jdeveloper. 

SOA Suite 11g - api tricks part 3 - composite mode / state

The first important piece to understand is that there are two parts to the state
a) active | retired (this setting decides whether new instances can be created [active], or old ones are allowed to finish w/o new ones being allowed to be created [retired] - this is referred to as composite mode
b) on | off (this is the composite state) and overrides (a) in either allowing call access [invoke / callback] to the composite revision [on] or not at all [off]. This is referred to as composite state.



This entry explained how to find a specific instance back via composite sensor values, instance id, or conversation id, yet the starting point is the same.
From oracle.soa.management.facade.Locator one can use getComposite(CompositeDN), which gets you to the composite (an impl of oracle.soa.management.facade.Composite)
In order to retrieve the mode (a) and the state (b) - use the api (and unfortunately the implementation).

System.out.println("Mode: " + composite.getMode() + " state: " + 

   ((oracle.soa.management.internal.facade.CompositeImpl)composite).getState());

This will get you something along the below line Mode: active state: on.

SOA Suite 11g: How to invoke composite services

Another undocumented sample end2end-108-InvokingCompositeServices.zip shows how to invoke composite services via Event, REST, JAX-WS, and Direct Binding. In a nutshell - you can only invoke what you declare to be invocable via a certain binding.



  In the sample you will see
which is the direct, transactional java based binding
which exposes a service via SOAP/http & rest enables it and
which enables an event subscription.
enjoy

SOA Suite 11g - faulthandling

I have updated my sample on faulthandling to show fault-policy usage and how to work with the standard runtime fault - all based on SOA Suite 11g. A few things to note:
a) I had to advertise fault-bindings / fault-policies.xml explicitly in composte.xml via

fault-policies.xml

  fault-bindings.xml 

b) My policy is bound to the MasterCatchRemoteFault process, this is configured in fault-bindings.xml through

     MasterCatchRemoteFault

 

c) The faultPolicy name matches to the id defined in fault-policies.xml. In there I am reacting to a fault that is thrown out of the detail process.

    

         name="custom:aCustomBusinessFault">

         

                <-- rethrow the fault -->

  

 

    

The full sample can be found here.

SOA Suite 11g: weblogic.transaction.internal.TimedOutException: Transaction timed out after 299 seconds

We have a BPEL process that has a couple of DB Adapter invocations in it. The first one calls a stored procedure and takes a long time to execute (over 5 minutes). In the BPEL process are invoked consecutively the respective procedure and then are made a few more invokes to the database for selecting of records in tables (they are passing quickly). When starting this process, after getting the result from the first invoke of DB Adapter (the slow procedure) and make the second Invoke (the quick select) we get error "JTA transaction is not present or the transaction is not in active state."



Everything, whatever you do in SOA suite runs inside a JTA transactions at runtime (read everything that goes through BPEL, Mediator or is initiated by an adapter)
In SOA Suite 10.1.3 on OC4J - there were two knobs that people could tweak to prolong the time of a jta-transaction. The global jta transaction timeout could be set in transaction-manager.xml.
Now BPEL PM overwrote this setting in its own EJBs - e.g. Dispatcher Bean, Cube Engine and Delivery Bean. So the change could be done in $SOA_SUITE_HOME/j2ee\\application-deployments\orabpel\ejb_ob_engine\orion-ejb-jar.xml
As OESB used User Managed Transactions, the setting there was in $SOA_SUITE_HOME\integration\esb\config esb_config.ini - namely through xa_timeout
On weblogic in SOA Suite 11g - the same idea applies, except that the place to set those is little different.
Globally, the transaction timeout can be set via the weblogic console / JTA and for BPEL specific beans, go to deployments / scroll to soa-infra and expand it. Now scroll down to EJBs and find "BPELEngineBean" - in the configuration section, all the way down you find the transaction timeout - set to 300 seconds by default.

SOA Suite 11g-Samples

I was trying to filter through the forums and many emails from customers / partners / and internal people - to come up with a list of samples that illustrate common issues
soa_samples_bpel.zip
The soa_samples_bpel.zip contains



bpel-102-AssignActivities illustrates how to work with advanced activities, such as copyList, or insertBefore
bpel-103-Loops illustrates how to work with arrays and collections, through xsl, flown and while loops
bpel-104-SynchronizationOfProcesses shows how to synchronize processes / or branches with each other (through signals / links & events)
bpel-105-Headers shows the usage of header variables between processes
bpel-106-FaultHandling demonstrates fault handling, with custom faults, and compensation
bpel-107-WorkingWithSDOAndEntities showcased the usage of SDOs and entity variables (in a simpler form than Fusion Order Demo does)
bpel-108-UsingXQuery is a port of the 10.1.3x based XQuery sample - showing how to use xquery for complex operations
bpel-109-UsingSchematronForAdvValidation Illustrates the usage of Schematron for context based validation within a bpel process (via bpelx:exec activity) and
bpel-110-WorkingWithRestillustrates how to call a rest based service (in this case google's robot) and how to invoke a composite via jax-ws http binding
Note that all of these are undocumented samples, so they are only code based. Once they'll go on samplecode.oracle.com - they will be nicely doc'ed and also contain build scripts.

SOA Suite 11g – Oracle BPEL Master and Detail process coordination using signals

A BPEL process can communicate with another BPEL process just like it can communicatie with any Web Service – as BPEL processes expose WebService interfaces to the world – or at least to their fellow components in the same Composite Application. When one process – the master in tis discussion – calls another one – it can have several types of interaction and dependency on that other process – we will call it the detail process for the purpose of this article:

• it is not interested at all in the detail process – its call was a one-way fire and forget
• it is interested in the response and it will wait for the response before it can continue processing (synchronous calls will always do this, asynchronous calls could have some activity going on while the detail process is churning away)
• it is interested in the fact that the detail process has reached a certain stage – but it does not actually need a response (it wants a signal but no data)

Chatting from SOA Suite 11g – how BPEL processes can use the XMPP protocol to notify the world

Various scenarios may require sending email messages or other types of notifications to users as part of the process flow. For example, certain types of exceptions that cannot be handled automatically may require manual intervention. For example, a BPEL process can use the notification service to alert users by voice, IM, SMS, or email.  In a previous article (http://technology.amis.nl/blog/6019/configure-soa-suite-11g-for-sending-email-notifications-with-google-mail) I described recently how the fairly new SOA Suite 11g can use GMail or other public Email servers to send notifications, for example from BPEL processes or the Human Workflow Service. The SOA Suite 11g works with the User Messaging Service (UMS) to perform that feat and the essence of said article is to configure the email driver in UMS to use GMail – or any other email server for that matter.




This article looks at one of the other communication channels available in UMS, and also available to BPEL processes: Instant Messaging or Chat. After configuring the UMS XMPP driver in the Enterprise Manager console, the Chat channel is available to any BPEL process. We will discuss how to configure – and with which configuration details for Jabber.org – and subsequently how to make use of that communication channel from a BPEL process.

Prerequisites

Before you can apply this article, you need to have installed the SOA Suite 11g, configured the SOA Domain and have the AdminServer and the SOA Server running. You also need access to the Oracle Enterprise Manager Fusion Middleware Control Console. You will also need JDeveloper 11g with the SOA extension in order to create a SOA Composite Application through which to test the Chat capabilities.
You also need to have an IM account on an XMPP Driver (or Yahoo, MSN, AOL or ICQ). To try out hooking up SOA Suite 11g to Instant Messaging, you can quickly create an account on a public chat service like jabber.org (takes no more than two minutes).

Deploying the XMPP driver

After the default installation of the SOA Suite 11g, the XMPP driver is not automatically deployed – unlike the Email driver. The drivers for XMPP, SMPP and Voice are installed but not yet deployed. So that is what we need to do first in order to be able to use the chat channel. You can deploy additional drivers in a variety of ways using: WebLogic Server Administration Console, Oracle Enterprise Manager, WLST commands, and through the Oracle Fusion Middleware Configuration Wizard.
We will use the WebLogic Server console in this article. This can be accessed at http://host:7001/console.
In the Domain Structure region of the console (the tree on the left side), select the node Deployments.

The Home page for Deployments appears. Click on the install button.

The Install Application Assistant appears. Use this page to locate the application you want to deploy.
The application you need to deploy is in the SOA Home directory under the Fusion Middleware Home directory created when installing first WebLogic and on top of it the SOA Suite: FMW11g_HOME\SOA_HOME\communications\applications. The XMPP Driver itself is in the file called sdpmessagingdriver-xmpp.ear.

Click Next. You are asked to choose the targeting style. Choose Install this deployment as an application (also the default option).
As a deployment target, choose the server soa_server1.

Press Finish on the summary page. In order for your deployment to be complete, you may need to activate your changes (depending on the mode WebLogic Server is running in); if so, click Activate Changes in the Change Center.

Configure the UMS XMPP Driver

The User Messaging Service comes with a number of drivers that each handle traffic for a specific channel. One of the drivers controls the XMPP (IM) channel. This driver needs to be configured with the properties of the XMPP IM Server (or proprietary network) and the account from which messages are sent.
Go to the Oracle Enterprise Manager Fusion Middleware Control Console (typically http://host:7001/em) and open the User Messaging Service node.

Select the node for the XMPP driver. From the drop down menu, select the item XMPP Driver properties.

The form that is now shown allows you to set various properties on the XMPP  Driver, including the details about the server to be used by the driver for chat operations.
The properties that need to be configured for instant messaging are:

• IMServerHost  – Jabber server host name. For multiple servers, use a comma-delimited list (for example, my1.host.com, my2.host.com). If only one host name is specified, it is used for all accounts. The IMServerHost for Jabber.org is: jabber.org.
• IMServerPort  Corresponding comma-delimited list of Jabber server ports; the Jabber.org Server Port is 5222
• IMServerUsername List of Jabber usernames to login as (these user accounts are automatically created, if necessary, on the corresponding Jabber servers). If you have multiple servers listed above, there must be an equal number of usernames (one username per server). If you have only one server listed above, all usernames listed here use that server. The username you need to enter here for Jabber.org is your Jabber.Org Account name, without the @jabber.org bit – so just johndoe or hanktheknife.
• IMServerPassword  Corresponding comma-delimited list of passwords for each username listed above.

Press Apply. To have these settings take effect, the Server has to be restarted.
Note: the UMS XMPP driver can also be configured to support proprietary IM networks including Yahoo, MSN, AOL or ICQ IM .

Configure the Notification Service

We have to explicitly allow the Notification Service to not only use email but in fact all communication channels for sending notifications.
Navigate to the properties form via the dropdown menu for SOA Infrastructure, under SOA Administration:

The Workflow Notification Properties are shown. Only one is really important at this point: the Notification Mode (default value is None) must be set to All , otherwise any notification for any other channel than email is not really sent onwards by the SOA Suite to UMS!

At this point, the SOA Server needs to be restarted to have the changes take effect.

Create the chatty Composite Application

We will create a very simple composite application to try out the message sending capabilities we should now have at our disposal. Go through the normal steps:
1. Start JDeveloper (choose Default Role if you are prompted to select a role)
2. From the menu option File, choose menu item New. From the New Gallery that is presented next, select the SOA Application item in the Applications Category (under the General node).
You will be prompted to provide a name for the application – for example GoogleTalkFromBpel  – and a name for the project – the same or any other name will do nicely. JDeveloper then asks you what type of composite application this will be; pick ‘Composite with BPEL’ on the Configure SOA settings step. Press Finish to have the application, project and service composite created.
3. The Create BPEL Process dialog comes up next. Specify the name for the new BPEL process – Talkative – and the Template: Synchronous BPEL process. Leave the checkbox Expose as SOAP Service checked and accept other defaults as well. Press OK.
4. The BPEL editor opens up. You will see the basic structure of the BPEL process with a receive and a reply activity, by default configured to receive a single string and return a single string. You need to add one activity to set the value of that string result: drag and Assign activity from the Component palette and drop it between the receive and reply activities already in the process.
Double click the assign activity, to open the editor. Click the green plus icon and select the Copy Operation from the drop down list. The client:result element in the outputVariable is the obvious target for the Copy Operation. Use the client:input element in the inputVariable as the source.
5. Now it gets interesting: drag the IM activity from the component palette and drop it just below the Assign activity. The IM activity editor pops up. We have to specify the address to send the IM message to and the body of the message we want the BPEL process to send.

The To: field is set to: jabber|googleTalkAccount@gmail.com. The part jabber| is used indicate the protocol to use. The value behind the pipe character is an account on some IM server, in this case the googleTalkAccount@gmail.com. Note that the server account that has been configured in the XMPP driver needs to have this account set up as a chat contact – you cannot just start chatting to anyone on Google Talk, Jabber.Org or MSN.
The value in the Body field can be set using hard coded text and expressions that use values from the input message or any BPEL variable. For example:

Hi, 

Message from the Talkative BPEL process via Instant Messaging.

This notifications informs you of the fact that the BPEL process has been invoked and is almost done executing.

The value of the input string was:
<%bpws:getVariableData('inputVariable','payload','/client:process/client:input')%>.

The request was made around <%xpath20:format-dateTime(xpath20:current-dateTime(), '[D1o] [MNn], [Y] at [H01]:[m01]:[s01]')%>

Later!

6. Deploy the Composite Application to the SOA Suite.

Run the Composite Application

Open the Enterprise Manager (http://host:7001/em). Expand the node SOA node under the root node Farm_soa_domain. The node for GoogleTalkFromBpel application should be listed. Select the node. The right side of the page is refreshed to present the details for this composite application. Click on the Test button to call the service exposed by this composite application. Enter a value for the input field – for example your first name – and press the button labeled Test WebService. The web service is invoked. This will create a new instance of the composite application. After a few seconds, the result from the service should be displayed, the same string that went into the service.

As part of the now completed instance of the composite application, a call is supposed to have been made to the Notification Service that in turn engaged the UMS that approached the Jabber.org IM server to send a chat message on behalf of the BPEL process instance. We can see trace of this message on the Message Status page for the User Messaging Service in the Enterprise Manager console.

And it shows up in whatever Chat client we are using:

Note that here we have the BPEL process send a notification of type Instant Messaging to the UMS that links for the IM channel to the configured IM server (Jabber.org) at the configured account (lucas.jellema@jabber.org) and sends the chat message from that account to the addressee (the To: field in the BPEL IM activity), which happens to be a Google Talk account.

Web Services Development

Feature Area	Feature	Description	Screenshot
Service Development	REST Services	REST services can be coded and deployed to the integrated WLS 11g R1 or to standalone WLS 11g R1 servers. It should be noted that (1) the developer needs to install the Jersey REST run-time library on the server to enable this functionality, and (2) no wizard support exists for REST services
Client Development	Developing Relocatable Clients	Client proxies can be moved between different machines by updating the endpoint url in the Catalog file that gets generated for JAX-WS clients (rather than embedding the endpoint in the client code)
	JAX-RPC Client Class	A client class that interacts with the proxy is now generated for JAX-RPC clients. This feature existed previously for OC4J clients, and is now re-enabled for WLS clients
Policy	Wizard for Security Configuration	A wizard has been added that assists the user in installing a keystore, insert the right paths and add various passwords (encryption, signature, ..) on the client and the server. This makes it easier for users to support more advanced security scenarios in service, proxy and http analyzer scenarios
	JAX-WS Client Security	The proxy wizard now automatically configures the correct client security based on the policy defined in the WSDL
UDDI	UDDI Publishing	Functionality has been added to publish the WSDL of a deployed service to any UDDI v.3 compliant repository
HTTP Analyzer	Support for Policy	The developer can now set WS-Policy headers in the HTTP Analyzer, enabling the testing of Web Services that are configured with advanced security protocols (beyond basic username/password)
	REST Support	The content type of the message can be viewed, and syntax feedback is provided for both JSON and XML messages. The analyzer understands HATEOAS and therefore any hyperlink in XML or JSON messages is converted into a clickable link. The analyzer also understands WADL documents so each resource is converted into a clickable link with the correct content type on the request message

XML Development

Feature Area	Feature	Description	Screenshot
XML Documents	XPath Analyzer	Search XML documents using an XPath expression
XML Schema	Redefine	Support Redefine element in visual editor
	Load remote	Load remote XML schema per editor, per session

JDeveloper 11G Core IDE

Feature Area	Feature	Description	Screenshot
Application Overview	Redesigned UI	The Application Overview has been redesigned for improved usability and performance.
	Checklist	A new Checklist tab has been added to the application overview viewer. The Checklist is designed to guide users (especially new users) through typical steps in building an application. Initially, there is a checklist only for new applications based on the "Fusion Web Application" application template.
Application Navigator	Create package	Create and delete packages and folders directly from the Application Navigator
Keymaps	Eclipse Keymap	New Eclipse keymap maps the default Eclipse keymaps to equivalent functionality in JDeveloper
User Feedback	Usage Tracking	Automatically records certain events that occur during the normal usage of the product. If you opt-in to this feature, at specific intervals, JDeveloper can send some summarized information about how you use the product to Oracle. We can then use this information to improve the product.
Extension Development	Multiple Classloaders	Extension developers can now declaratively request a separate classloader. This can help eliminate conflicts that can occur between mutliple extensions needed different versions of the same library.