Wednesday, September 10, 2014

Mastering Oracle SOA Suite 12c subprocesses

In Oracle SOA Suite 12c it is now possible to create subprocesses, which are a kind of reusable BPEL procedures or BPEL methods. The nice thing about it is that it is executed in the same thread. 

IBM and SAP have created a BPEL extension (BPEL-SPE) to do the same job but Oracle implemented its own version.

You should know that subprocesses are not part of the BPEL 2.0 standard and added as an extension!

There are to variants of subprocesses:
  • Standalone: Which are created and reused in the composite itself.
  • Inline: Which are created and reused inside a particular BPEL process.
It's not possible to reuse subprocesses between different composites or reuse a inline subprocess by another BPEL process.

As a developer I was expecting that a subprocess have a well defined interface to hide the internals. But this isn't the case. A subprocess is just a call to a bunch of BPEL code. The only way to get something In or Out is by declaring variables inside the subprocess and create a mapping to these.
So what you should remember is that a subprocess doesn't have a service interface or endpoint.

When you create a inline subprocess it isn't possible to transform it into a standalone subprocess or visa versa. So in your design phase you should make the right decision.

You should know that a standalone subprocesses can only be called from BPEL processes and not from a mediator. Later in this blog I will explain how.
 
To be flexible I advise only to create standalone subprocesses because they can be reused by other BPEL processes (inside the composite) and can be reused more than ones in a particular BPEL process as well.


In the picture below you can find an example of the usage of a standalone BPEL subprocess from the composite perspective.



This picture shows three BPEL processes: BPELProces1 is a dispatcher for calling BPELProcess2 and 3. The latter two are using MySubprocess. Notice the grey color of MySubprocess and the dotted wires to it!
In this example does MySubprocess only adding the prefix string 'Hello ' to a input string.
In this example my BPEL's do nothing more except some variable mapping and invokes.
When calling the endpoint of the service with the string 'Gertjan', it will return 'Hello Hello Gertjan' as result of it. The second 'Hello ' is added because BPELProcess2 uses MySubprocess and the first 'Hello ' is added by BPELProcess3 (which reuses MySubprocess).

I the next part of this blog post I will go into the implementation (this is not a step-by-step tutorial).
The example (JDeveloper project) is available in github: Example Sources
 
The following steps are performed:
  1. Create Standalone Subprocess in Composite Editor
  2. Implement subprocess input and output variables
  3. Implement subprocess logic
  4. Create other logic
  5. Create subprocess call
  6. Test

1. Create Standalone Subprocess in Composite Editor

The Standalone Subprocess is created in the Composite Editor by dragging 'Subprocess' from the component pallet to the Components swim-lane.

This will show the 'Create Subprocess' pop-up:

Give the subprocess a proper name.
A subprocess is saved in the BPEL directory.

The Components swim-lane will now look like this:

2. Implement subprocess input and output variables

As stated earlier, the input and output is performed with variables. So you should create at least one input variable which can also be used as output variable. Alternatively you can create a separate output variable.

Double click the just created subprocess and create an input/output variable. In this example I did the following:


3. Implement subprocess logic

MySubprocess just contains one assign having the concat action:

concat('Hello ', $InputOutputVariable)

I looks like this:

4. Create other logic

Now it's time to create your other logic.

Create at lease one BPEL process because only a BPEL process can call a subprocess.


The in this blog post given creation sequence is not a mandatory sequence. In normal live I think the primary logic is created first and during development you decided to separate some BPEL logic in a subprocess because it's used more then once.

In the example here, I created three BPEL processes as show earlier. Up to this point the composite swim-lane should look like this.

5. Create subprocess call

Lets go into BPELProcess2 to see how the call to the subprocess looks like.

In the middle you can find something new: the call to MySubprocess, which is named (by me) as 'CallMySubprocess'.

This isn't an invoke! Its an new added feature which is not part of the BPEL 2.0 standard and added by Oracle. For this the extensionActivity construct (see: extensionActivity for details) is used and the BPEL source code looks as following:



The definition of CallMySubprocess, reflecting this, is shown below:


There you can find the mapping of the InputOutputVariable to variableForCall. The checkbox 'Copy By Value' is deselected indicating that it's a copy-by-reference.
  • Copy By Value selected: The literal value of the variable is copied. This is a one-way action.
  • Copy By Value deselected: The reference to the variable is copied. This is a two-way action. When changing the subprocess variable, the other variable is changed accordingly.
The variableForCall is a global variable of BPELProcess2 which I created to communicate with my subprocess. The types of both variables should be the same.

So the data between MySubprocess and BPELProcess2 are interchanged by referencing InputOutputVariable (which is part of MySubprocess) to VariableForCall (which is part of BPELProcess2).


6. Test

When testing this example you will see the following in EM:


Drill-down into BPELProcess2 will show this (with the CallMySubprocess call!):

The reply is: 'Hello Hello Gertjan' when the input was 'Gertjan' as shown here:


Some remarks you should know

In the SOA Suite 12c Developers Guide the following remarks are made regarding subprocesses:
  • There is no restriction on one BPEL subprocess calling itself recursively. You must determine if you want to recursively call the same BPEL subprocess and the number of times the subprocess calls occur.
  • You can create and successfully deploy a SOA composite application that contains only a standalone subprocess. For example, create a SOA composite application and add a standalone subprocess in which you define two parameters for the subprocess and define an assign activity in the subprocess to swap the values of both parameters. However, while a SOA composite application that contains only a standalone subprocess and no other components can be deployed, it has no practical purpose.
  • A standalone subprocess cannot be shared in the MDS Repository. However, a BPEL process with call activities for calling the subprocess can be shared in the MDS Repository.
  • A standalone subprocess can include an inline subprocess.
  • Creating an inline subprocess within an existing inline subprocess is not supported.

Wednesday, July 30, 2014

What you should know about debugging Oracle SOA Suite 12c


This blog is explaining some features about debugging Oracle SOA Suite 12c from another perspective.

Data perspectives

When you are debugging a composite and run at a particular breakpoint you probably wants to see you data from different data perspectives:
  • The message which was send to you service endpoint.
  • The message which was send to a particular composite component.
  • The global variables inside a BPEL component. 
  • The local variables inside a BPEL scope.
  • The message which was send to an external reference.
JDeveloper is able to show this data in the Data tab page which is part of the debugger GUI as shown below.

Did you notice the normalizedRequestMessage above? Is this the normalized message which is send between service engines? It seems to me so.

The data shown in the Data tab is related to the components you have within you composite and at which point you are in the debugging process. This last point is very important and explained later on. For now you should know that the available data perspectives are related to the point you are in the code.

The debugger builds up a simple Stack which is shown in the Stack frame as part of the Structure Window. The general purpose of this Stack is to show the available data perspectives. They are presented in reverse order. Below you can find an example of this (_client_ep was the initial call).



When clicking on a particular row in the Stack frame, the Data tab is updated accordingly and the corresponding Data perspective is shown.

You should know that it isn't a complete instance flow trace! For example, when you leave a particular BPEL component only the data available at that point can be viewed, so the BPEL variables are gone. The same is true for BPEL scopes, etc.

As stated before: The Stack frame is only showing the data perspectives which are available at a particular point in the debug (walking through) process in reverse order.


When you want the complete picture (of the whole data flow) you should go to the Enterprise Manager and look at the instance flow trace.

When you read the debugging documentation you already are familiar with changing data during the debug process. But something seems not yet implemented. Please read further to know what.


Data Watches

Every debugging solution should provide the ability to update variables, and JDeveloper does so.
You can update messages which are sent between service components and update variables within BPEL. Below you can find an example of the BPEL Global Variables Data perspective.

When expanding a particular variable you are able to drill down to the data inside it. It's all XML bases and you can choose between a tabular or a tree view. The look and feel of the tree view is more intuitive.


One of the nice features is that this data can be changed!!!
This can be very useful because you are able to change the data in case it isn't having the expected value (caused by a bug in the previously executed code).
By double clicking on an element the Modify Value modal window is given as shown below.



Only data elements could be changed, not reference elements (for example a reference to binary data). You should be aware of putting in data of the correct type to be sure not to run into unexpected behaviour.

So far nothing new, but do you have noticed the Smart Data and Watches tabs on both sides of the Data tab? And there are more...
All Debugger Tabs can be made available using Window->Debugger as shown here:


  • Deployment - Log: Showing the startup of the debugger and connection to the to-be debugged process. Here you can check if debugger is started correctly and is attached to the project.
  • Breakpoints: Giving a overview of set breakpoints.
  • Smart Data: Don't know what this is. Documentation isn't saying anything about it.
  • Data: The data as explained in this blog post.
  • Watches: To show the watched messages and variables.
  • Classes: I think this is only used for Java debugging.
  • Threads: Showing the debugging threads. Usually you will put this as part of the Structure Window.
  • Stack: Already talked about in this blog post. Usually you will put this as part of the Structure Window.

Did you tried watches? I did and it doesn't work entirely correct.
The documentation doesn't tell anything about it and when I try to create a Watch for a particular variable, I run into lots of errors.

You create a Watch from the Data tab by right-click a particular variable or message. This variable or message is show in the same way it is shown in the Data tab. But it is very buggy and you sometimes get the following strange watches (notice the ? between the two input variables):


I also was able to add the same watches more than ones and I was not sometimes not able to remove created watches.

You even can't save watches. I tried to find files in my project directory and haven't found one dealing with this information. So, when you restart JDeveloper or your debugger: all watches are gone!
On the other hand, breakpoints are saved locally but are saved within internal configuration files of JDeveloper.

It should be a nice feature when these configuration files (watches and breakpoints) are standardized and made available within JDeveloper itself. Then we have the possibility to define a good debug set with breakpoints and watches which we can reuse every time we made a change.

My conclusion about watches is that it isn't usable at this moment (first 12c release). The Data tab is doing the job well because of its context awareness (as explained in this blog).
 
The last thing I tried was the Inspect feature. Inspecting is nothing more than creating a special kind of watch in a separate modal window. You create a Inspect by right clicking on a variable or message.
This window looks like this:

Because it is a modal window it is always shown on top op JDeveloper anywhere you like. Can also be a on a second monitor.


For now here ends my dive into debugging with Oracle SOA Suite 12c. Next post will focus on other new 12c features.

Wednesday, July 23, 2014

Oracle SOA Suite 12c Debugger Demystified

Oracle SOA Suite 12c Debugger Demystified

A new cool feature of the latest version of Oracle SOA Suite 12c is debugging. Finally we can debug our code at composite and even inside BPEL and OSB levels. Debugging of other service engines is not possible yet. This blog is going through some interesting aspects of debugging and the new world that we are entering.

The debugger can only be performed when the SOA server is in Development mode and debugging is a single user and single server activity. So it isn't possible to share a development environment and do debugging with more than one developer at the same time. You even can't create new instances from the enterprise manager.

You should know that the focus of the debugger is the composite itself. So it's not possible to debug more composites at the same time.

I tried to combine the debugger with the Unit Test Framework and also this is not possible. This is because JDeveloper goes to a special mode (the swim lanes of exposed services and external references are become light yellow) and doing other things, like debugging, is not possible anymore.
I tested this by going to debug mode and after that I ran the test suite. But, when going to test mode a check is performed if the deployed version is equal the working version, which isn't in this case. So the test framework deploys a new version of the composite and debug mode is left.
It would be a cool feature when testing can be combined which debugging or at least you can reuse you input test cases for debugging features. Let's ask product development to at this feature in next patch release. For now we will focus on debugging.

Debugging is implemented by Oracle by using Java Platform Debugging Architecture (JPDA). This standard is structured as following:


JPDA is a multi-tiered debugging architecture that allows tools developers to easily create debugger applications which run portably across platforms, virtual machines (VM) implementations and JDK versions.
JPDA consists of three layers:
  • Java VM Tool Interface (JVM TI): Defines the services a VM must provide for debugging. Includes requests for information (for example, current stack frame), actions (for example, set a breakpoint), and notification (for example, when a breakpoint has been hit). A debugger may make use of VM information other than this (for example, Java Native Interface (JNI)), but this is the source of all debugger specific information. Specifying the VM Interface allows any VM implementor to plug easily into the debugging architecture.
  • Java Debug Wire Protocol (JDWP): Defines the communication between debuggee en debugger processes. It does not define the transport mechanism (socket, serial line, shared memory, ...). The specification of the protocol allows the debuggee and debugger front-end to run under separate VM implementations and/or on separate platforms. It also allows the front-end to be written in a language other than Java, or the debuggee to be non-native (e.g. Java).
  • Java Debug Interface (JDI): Defines a high-level Java language interface which tool developers can easily use to write remote debugger applications. It defines information and requests at a user code level.
JDeveloper is a agent and implements the JVM TI. This agent listens for particular events. One of these events are BREAKPOINTS (what a surprise!):
Breakpoint events are generated whenever a thread reaches a location designated as a breakpoint.
 The JVM TI talks by using JDWP to the engine.

When you start debugging a particular composite a redeployed and the server is started in debug mode. In JDeveloper the composite is set to Read-Only and Debug Mode label is shown as following:



I looked at the deployed code, by searching into the jar, for any hooks but I wasn't able to find any of these. So basically debugging is performed transparent. That is exactly what JPDA promises.


What you should know is that the debugger talks against a special debug port. This can be set in JDeveloper as following: Set Host, Port and Timeout at "Project Properties > Run/Debug > Edit > Tool Settings > Debugger > Remote".

For synchronous services the setting of the Timeout property is sometimes not enough. In this case you will get and HTTP 500 internal server error in the HTTP Analyzer and you will get the following error response:
<?xml version = '1.0' encoding = 'UTF-8'?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Header>
      <tracking:faultId xmlns:tracking="http://oracle.soa.tracking.core.TrackingProperty">1</tracking:faultId>
   </env:Header>
   <env:Body>
      <env:Fault>
         <faultcode>env:Server</faultcode>
         <faultstring>Transaction timed out after 301 seconds
BEA1-33F38DED3BB59E472B1E</faultstring>
         <faultactor/>
         <detail>
            <exception/>
         </detail>
      </env:Fault>
   </env:Body>
</env:Envelope>
 To solve this you should set the following properties accordingly:
  • Increase the SyncMaxWaitTime property in Oracle Enterprise Manager Fusion Middleware Control.
  • Increase the Idle Timeout and Transaction Timeout values for the Enterprise JavaBeans property BPELDeliveryBean in Oracle WebLogic Server Administration Console.
  • Increase the Java Transaction API (JTA) timeout value located under the JTA link on the Oracle WebLogic Server Administration Console home page.
The last thing you should aware about are the debugging guidelines. These guidelines can be found in the Oracle Debugger documentation and are also given below:

  • The SOA composite application name and the Oracle JDeveloper project name must be the same.
  • Any SOA composite application encountered during a debugging session must reside in the currently active workspace in Oracle JDeveloper.
  • Debugging is limited to design view in Oracle JDeveloper. You cannot run the SOA debugger in Oracle Enterprise Manager Fusion Middleware Control.
  • Debugging is a localized user experience. If you want to switch to other tasks (for example, search for instances or initiate new instances of the same composite from Oracle Enterprise Manager Fusion Middleware Control), close the debugging session.
  • You cannot set breakpoints on REST services.
  • The breakpoints that you create for debugging in a SOA composite application in one installation of Oracle JDeveloper are not available to other Oracle JDeveloper installations. You must create the breakpoints again for debugging.
  • During a debugging session in which you are using the embedded Integrated WebLogic Server, you cannot use the version of Oracle Enterprise Manager Fusion Middleware Control included with the embedded server to generate new instances or query instances.
  • You cannot debug cross-language features, such as a Java exec activity, XSLT and XQuery transformations, and so on.
  • You can debug SOA composite applications on servers on which Oracle SOA Suite is installed. For example, if Oracle SOA Suite runs on managed servers, clients must connect using the managed server host and port.
  • Only one client at a time can connect to the SOA debugger.
  • You cannot debug multiple instances of the same SOA composite application at a given time even though Oracle JDeveloper does not restrict you from this action. This is not the correct approach. The SOA debugger is a development tool. It is your responsibility to ensure that only a single instance is debugged at any given time.
  • Adapter endpoint errors are not displayed in the SOA debugger in Oracle JDeveloper. Those errors are logged in the log file.
  • You can only debug if the server is in development mode. Debugging in production mode is not supported.
  • Oracle B2B and Oracle SOA for Healthcare service and reference binding components cannot be debugged with the SOA debugger even though you can set debugging points on both components.
  • SOA composite application-to-SOA composite application debugging is not supported.

Good luck with debugging.



Saturday, June 28, 2014

Quick Start Oracle SOA Suite 12c

Quick Start Oracle SOA Suite 12


Friday 27th Juni Oracle SOA Suite 12c became available for download.
The SOA Community informed me about it by email and send me the following link:

https://soacommunity.wordpress.com/2014/06/26/soa-suite-12c-is-available-for-download/

I can't wait to give it a look and I installed the Suite at Saterday 28th.

Here you can find some notes about this journey.

First of all you need to download the product, as you already thought so :-)
There is a Quick Start Install Guide for developers available and I recommend to use that one when you want quickly start testing the product. This guide can be found here: http://docs.oracle.com/middleware/1213/core/SOAQS/index.html

As stated in the guide we have three different domain configurations available. This means how Oracle SOA Suite is preconfigured. The given domain configurations are:
  • Default Domain: Oracle WLS with SOA Suite and OSB are available as integrated WLS directly from JDeveloper. This options is the quickest and easiest way to start with the product for evaluation purposes.
  • Standalone Domain: Next to JDeveloper you have to install a standalone WLS. This looks like a normal development environment and this was the only way to go with the 11g version. You have to start WLS separately from JDeveloper and you have to create a Application Server connection to it.
  • Compact Domain: I didn't try this one yet (next post?) and you should you this when you want to try the now components like Enterprise Scheduler, Managed File Transfer, B2B or BAM.
Just follow the Quick Guide it will lead you where you want to go.

I took the Standalone Domain installation because I want to use the OSB console without the need to start JDeveloper first.

When everything is running I recommend to create a HelloWorld sample application. I usually create it with a Mediator and a Echo Callback routing rule.

When you want to test 12c with a more advanced sample than I recommend to download the sample from the link below:
https://java.net/projects/oraclesoasuite12c/pages/SOASuite12cQuickStartSampleApplications

The Quick Start Guide also explains how this sample can be deployed and run, see chapter 7 how.
But the guide also talks about a the sample file called SampleOrder.xml and I was not able to find it. So I run the test with the default generated payload and it worked fine.

The next thing to do is creating something more by yourself. For this there is an tutorial available from java.net (at the given link above).
In the next post I will write about my experiences regarding this.