Oracle released SOA Suite 12c (12.1.3) bringing a further integration between components and a bunch of new features. This blog is one in a series of new features summaries about SOA Suite 12c to view them all check this blog.
This blog will summaries the features specific to SCA Composites / BPEL and the Enterprise Manager Dashboards. The features are summarised, but most will get an own blog that tells about the full details.
This blog will talk about the following topics:
• Changed project / directory structure • Project / Component en Scope Templates • Updates to the composite editor • Updates to the mediator • Updates to the BPEL component / activities • Fault Policy Editor • SOA Composer refresh in 12c • SOA Suite Debugger •
Disclamer: Screenshots are made in Beta version of SOA Suite 12c, so may differ in final version!
Changed project / directory structure
The structure of the project has changes drastically. All components are now placed in there own sub folder.
• BPEL – Collection of BPEL en SBPEL components
• DVM – Collection of Domain Value Maps
• Mediators – Collection of Mediator components
• Schemas – Collection of XML Schemas (XSD)
• Testsuites – Collection of Composite tests
• Transformations – Collection of XSLT transformations
• WSDLS – Collection of service contracts
The composite.xml carries the same name as in 188.8.131.52, the name of the SOA project.
Kick-start an SCA Composite using templates
In 12c it is easier then ever to re-use at all levels within a SCA composite. Using the build-in template support you can kick-start a SCA Composite or add reusable components. There are three types of templates; SOA Project, Component and Custom Activity template. Templates are fully editable, one you apply them to you SCA Composite or BPEL component it is part of that composite or component. When you create a template all dependencies (partnerlinks) are also part of the template.
With this kind of template you can create/load an entire project. Great example for this template is a skeleton project with default adapters and mediators (without wires) of use it for training purposes so that everybody starts with the same resources. Project templates are accessible at the time of new project creation directly, or when it is part of new application.
With this kind of template you can create/load a component with all his dependencies (resources and components). For example a BPEL process with default invocations to common services. This template can be automatically discovered in the component palette when in the Composite editor.
Custom Activity Templates
Similar to a standalone subprocess, only the code is added to existing BPEL process and dependencies are added to Composite. It can contain variables and activities (assign, invoke, transformation, etc). This template can be automatically discovered in the component palette when in the BPEL Component editor.
Templates will be visible if they’re available in the template path, configured in JDev, but there is also an import wizard available to bring templates in from different system.
Re-use of BPEL code using Sub-processes
Sometimes in BPEL you will do the same thing on multiple places within the same BPEL process. For futher re-use of code this release of SOA Suite 12c introduces BPEL Sub-processes. Sub-processes allow certain business logic to be made reusable. There are two types; standalone and inline. Inline Sub-processes permits access to data (variables) of the parent process, but with a standalone Sub-process the data needs to be assigned. Sub-processes are here to improve performance (faster rendering of only entity in question) and manageability (modular approach) of BPEL processes.
Details about inline sub-process:
- Group activities that can be re-used in the same BPEL process
- It is part of the parent BPEL process code and not visible in composite view.
- There is a new ‘call’ activity in BPEL to call a sub-process
- You can define parameters or use the parent process parameters.
- The inline sub-process is visible in the BPEL palette.
- Activities should be part of a scope to be converted to a sub-process.
- At run-time, the code of the sub-process is reusable and can be parallel used.
Only one copy is stored in the memory, even when it is invoked 20 times.
Details about standalone sub-process:
- It is a fragment of a BPEL process, which includes a set of activities that can be reused by other BPEL processes.
- A standalone sub-process has no interface, and can only be called by another BPEL process, but may have partnerlinks.
- In the composite view, the wire to a sub-process is shown as a dotted line, in order to indicate that there is no interface.
- The ‘call’ activity is used to call standalone sub-processes.
- In the first release of 12c, sub-process can not be called from outside its own Composite, but it may change in the future.
- Sub–processes are visible in the component palette to make them easy to drag into a BPEL process.
Share artifacts within and across applications
In 12c it is now more then ever easy to use the MDS. It is now possible to transfer (local) artifacts from a SOA application to the Design-Time MDS. JDeveloper has a wizard to share design time artifacts such as WSDLs and Schemas across applications. After transfering the artifact the references are automaticly updated with MDS URL.
Updated XSLT mapper and new XQuery support (including own mapper)
The choice for the developer is going to be tough, use XSLT of XQuery. In this release Oracle 100% XQuery 1.0 support with it’s own mapper, but also updated the XSLT mapper with some high requested features. BPEL even has a dedicated activity to use XQuery in your BPEL code for transformations. The XQuery mapper has support for XPath 2.0 and user defined functions. The mapper is really user friendly and it’s made consistent with the XSLT mapper interface. The mapper also has an integrated Test framework and is build for reuse in both SOA & Service Bus. The update XSLT mapper now has a better support for complex stylesheets with multiple templates, user defined functions (also recursive functions) and you can see the XSLT execution sequence.
New design of Component and Properties palette
In JDeveloper 12c the Component and Property palette undergone a metamorphosis. In the Component palette the Components and adapters are now logically separated and it is possible to display the items in a list view.
In 12c the Properties palette is finally used when developing SCA Composites and Service Bus Pipelines. It displays as it were, all the steps in the wizard or tabs of the dialog window of a component activity. Instead of editing the activity using the wizard you can now use the Properties palette to make changes.
Updated Mediator Component
The mediator has some new features in 12c. The overall editor looks similar and current 11g function are still present, but some nifty features are added in this release.
Translate from Native action
At the level of the Java callout an extra action Translate from Native is added. With this action you can transfrom a CSV/JSON/String element of the request to XML using a NXSD transformation. The transformed output can then be used in the routing rules of the Mediator. This action can be done on operation level, but also on a specific routing rule for that operation.
Override Using action
With this action you can override routing rule options using a DVM or Business Rules. Based on a element value of the request you can change the routing rule option dynamically. With the key value you have the possibility to override the XSLT transformation file, Filter expression, Execution Type, Syntax Validation (XSD), Semantic Validation (Schematron) file instead of creating a bunch of static routing rule.
New graphical editor for Assign action
The last noticeable change to the Mediator is that the graphical editor for the Assign action is the same as BPEL uses. You can create multiple copy rules by using drag and drop functionality.
Sensors are already a known feature of the SOA Suite 11g. It’s basically means marking a variable or data field to be traced at runtime. So at runtime you can see the values of this field or variable for a running instance, but also you can search for running instances (e.g. find the running instance of which the field ‘order id’ has value ‘AB12345’). In SOA Suite 11g these sensors had to be defined at design time. In the SOA Suite 12c it also will be possible the define or change them at runtime: Design Time at Run Time (DT@RT). This functionality is added to the existing ‘SOA Composer’ application, which is already used to change other runtime metrics like the Rule Engine and Domain Values Maps (DVMs).
Fault Policy Editor
One feature that surprised me when I was dissecting the Beta version of 12c was the addition of the Fault Policy editor. In 11g Fault Policies were added so that you could easy intervene when a (SOAP/BPEL) fault was thrown. But you could only create them in source mode, there was no graphical editor. In 12c Oracle has added this long awaited request. With the Fault Policy Editor you can now Design and Edit Fault Policies. Besides the already existed functionality a lot of new features are added.
- Graphical editor for creating Fault policies, Alerts, Actions & Property Sets
- New Default actions for invoking a WS and enqueue data (JMS).
- Alerts can be defined to send fault to JMS, Email or Log file.
- Alerts can be assigned to actions if type of Alert is desired to be triggered.
- Fault Policies can be coupled, using the Composite Binding dialog, to different levels:
• composite • component • reference binding and service binding •
Encrypt/Decrypt Personal info
Another new feature in 12c JDeveloper is the – Encrypt/Decrypt Personally-Identifiable Information or (PII). It assists in Protecting sensitive data from appearing in the Admin consoles in clear text. For example a Social Security Number or Credit card Number. Specific Fields in a message can be encrypted when entering the SOA composite application in the service binding component, and decrypted while exiting the application in the reference binding component. It is available for services and adapters in both SOA (SCA Composite) and Service Bus. The PII policy is attached to the SCA Composite. The credentials/encryption to use is configured on WLS and is stored using the Credential Store framework (CSF).
The Enterprise Manager for SOA Management & Monitoring had gotten a major overhaul. Because it is a lot of information there will be separate blogs to discuss all the features and because it is just to much to summaries hereby a short impression below.
Enterprise Manager startpage shows soa-infra expanded:
On the SOA-Infra Dashboard page you can search for instances and create/save searches:
Deployed Composites are show with status and can easily be started and stopped:
Search instances with custom criteria or default filter:
Composite Sensor values are shown directly in the EM dashboard when you click on a instance:
You can also search on these Composite Sensors:
SOA Composite Dashboard
Composite Dashboard shows only components and services:
The Composite definition can be visually displayed:
By default no flow instances are show to give page a much needed performance boost:
When selecting a flow instance more details are show about faults:
And Sensor values:
And Composite dependencies:
The instance flow trace shows adapters in gray and SB integration:
In the SOA composer you can add/edit composite sensor values, DVMs, Business Rules and other artifacts:
In the SOA Composer the Composite Diagram can looked at:
SOA Error Hospital
In the SOA-Infra dashboard (recoverable) faults are visual using a chart:
The flow instances tab shows faults that can be recovered, click on Error Hospital to recover them:
In Error Hospital tab faults can be recovered, with option to Bulk Recover:
During the recover attempt the number decreases:
Recovered Faults are shown in Green: