Overview of Oracle FMW release 12.1.3 in general and about SOA Suite and BPM Suite 12c in particular. Highlights important new features and cross product themes (such as productivity, industrialization, ease of getting started and more). Some topics: Service Bus Pipeline, Native Format transformation, XQuery support, BAM new style, Key Performance and Risk Indicators,…. Presented at the AMIS & Oracle launch event, 17th July 2014
Routing Rules in a Mediator component carry several attributes that govern the routing rule run time behavior. These include: XSLT or XQuery used for transformation, the filter expression, target operation, the parallel or sequential indicator, the Schematron document used for validation, the native validation and the value assignment (for example for header properties).
In SOA Suite 12c, we can conditionally set overriding values for each of these attributes. That means that at run time, based on the evaluation of some expression against the contents of the request message (or the time of the day, day of the week,…) , we can use a different transformation stylesheet or assign a different header value. This dynamic override of the static rule definition is configured using the Override Using option – shown last in the figure overhead.
An in-line sub process can best be thought of as a callable scope. It is a scope that is not part of the normal process flow, but rather a unit of encapsulated logic that can be called zero, one or multiple times from anywhere within the BPEL process – even recursively from within itself. It is in effect very similar to a private member function in a Java Class or a procedure in the body of a PL/SQL package. Just like private member methods or functions help structuring a Java Class or PL/SQL package, so can subprocesses help organize a large BPEL process – even more than scopes already can.
An in-line sub process can define arguments to be passed in. These can be passed by reference, which means the sub process can alter their values as well. Additionally, the in-line sub process can access all global process variables. The in-line sub process is a scope which as such can define local variables and nested scopes, use partner links, have event handlers etcetera. At run-time, the subprocess code is re-entrant and re-usable – only one copy is stored in memory, even if it is called multiple times. However, on each call, it has a private scope for local and passed-by-value variables.
In SOA Suite 12c, the Service Bus specific run time browser interface is not intended for administration activities: all administration around SOA Suite 12c is consolidated into Enterprise Manager Fusion Middleware Control. So a valid question now becomes: how to locate pipeline alerts produced in 12c Service Bus run time environments? These are of course to be found in EM FMW Control. But where and how exactly?
Let’s start with a very simple 12c Service Bus project. This project – was first introduced in an earlier article.
![image_thumb[1]](http://blog.soasuitehandbook.org/wp-content/uploads/2014/06/image_thumb110.png "image_thumb[1]")
The pipeline receives a fairly simple request message, performs an XQuery transformation on the contents of the $body and returns the result.
Create a new Alert Destination – to later on send the alerts to:
Set the name for Alert Destination then press Finish:
Configure the Alert Destination – ensure that Alert Logging is on (this means that alerts are save to the operational Service Bus infrastructure data store):
Open the Pipeline editor. Add an Alert activity to the Request pipeline:
Configure the Alert activity as shown here:
Most important is the link to the Alert Destination.
The next step is to run the pipeline or the proxy service. In both instances, the service is deployed to the Service Bus run time engine in the Integrated WLS.
In the Enterprise Manager FMW Control, the Pipelines Alerts can be inspected in the home page for the Service Bus node (that takes the place of the Operations tab in the 11g Service Bus Console). The first tab provides an overview of various types of (recent and aggregate) information.
The second tab provides details on recent as well as not so recent Alerts. On this tab can selected alerts also be purged.
When you click on the alert summary link, a pop up appears with the alert details:
On the home page for the Service Bus Project can we check the services in the project.
We can switch to the Operations tab get a more detailed overview per operation of what operational settings have been made. On this page, the pipeline needs to have Pipeline Alerts enabled in order for pipeline alerts to be produced from it:
By clicking on an operation (service, pipeline, split join), we can drill down to the next detail page where largely the same information is presented and can be manipulated.
If we enable monitoring, the Service Bus will start to collect aggregate information about the number of messages, errors, alerts etc. This information can be reviewed on the Dashboard tab for the Pipeline:
Clearly we have made some additional test calls to the service – already six alerts have been counted!
The MDS repository is an important mechanism for SOA Suite 12c, both at design time during development as well as at run time. At design time, MDS is used to host shared resources such as WSDL and XSD documents that are referenced in many different places. Instead of copying these resources between applications and projects, or creating central shared folders that are managed manually and at file system level, MDS is concept that is native to JDeveloper and therefore much easier to use with these shared resources.
In SOA Suite 12c, a design time, file based MDS repository is part of the development environment – out of the box. You can create your own file based MDS repositories in addition to this out-of-the-box instance.
When you open the Resource window, under IDE Connections | SOA-MDS, you will find the connection to this local, file based repository – that is initially empty.
Resources can be added to the MDS, for example by transferring them from SOA composite or Service Bus projects. Resources can also be transferred from the MDS to Service Bus projects. I am not sure yet how to transfer resources from MDS to a SOA composite application.
However, as stated before, this out of the box file based design time MDS repository is local. Resources added to it, are not shared with MDS repositories in some other location. SOA composites that contain references that start with oramds: cannot be shared unless the sharing partners all have the referenced resources in their local MDS repositories. That’s why it is very convenient to be able to export selected resources from a design time file based MDS environment – to a jar-file – and import resources from this jar-file to MDS repositories in other environments. I just used this mechanism to bring resources across from one VM to another.
SOA composites as well as Service Bus projects typically consist of fair number of artifacts that hang together in ways that are sometimes not so easy to track down. Through import statements, hard coded references and other direct or indirect definitions, dependencies are registered between the many files that make up the application. From BPEL component to WSDL to XSD to other XSD is a not too uncommon path. However, for developers it can be quite a challenge to get a good grasp on these dependency paths. Inspired by – and perhaps more than just inspired – the App XRay feature in OEPE (Eclipse), JDeveloper 12c ships with the Dependency Explorer. This is a tool that can be set upon almost any artifact in SOA composites or Service Bus projects. It will leverage all its built in knowledge about potential dependencies and it will visualize these dependencies.
For example, let’s look at this simple Service Bus project. Right click on the pipeline definition in the navigator window and select the option Explore Dependencies:
The dependencies for this simple case are shown like this:
In the Dependency Explorer itself, we can right click all components listed and drill further down, list the reference details, select the component in the navigator or bring up the editor for the component.
Here is the drilled down overview of dependencies, starting from the WSDL document ProxyService.wsdl and backtracking what are the references to the WSDL document.
In a previous article, we introduced the SOA Suite 12c support for XQuery library modules.
We can open the dependency explorer for an XQuery library
and learn where it is used:
This overview tells us that we will indirectly impact the ProxyService if we do something wrong with the TimeAndDateLibrary.xqy.
An even more impressive overview is produced by exploring the dependencies for a BPEL component, as is shown here:
This results – in this particular example – in:
One final example shows how a Database Adapter was analyzed – both the usage from the SB Business Service and the reference to the WSDL and indirectly the XSD:
