EM – Alerts for stuck BPEL messages
An alert is displayed when there are stuck messages for asynchronous BPEL processes.
A global time threshold is used identify stuck messages.
Alerts displayed at multiple levels:
- Ø soa-infra
- Ø Composite
- Ø Flow Trace (PS4)
System-wide MBean property to enable / disable BPEL message recovery alerts.
3 dimensional view of instance state:
- Ø Execution state
- Ø Fault
- Ø Fault recovery needed
Enhanced search criteria.
Instances list can be filtered to instances with stuck BPEL messages.
Link from “BPEL Recovery Required” alerts to BPEL recovery console.
ECID based search on BPEL recovery console. (PS4)
Testing BPEL Processes
Testing of an individual BPEL process as part of a SOA composite application test suite
- Ø Variable and fault Assertions
- Ø Assert Execution Counts
- Ø Fast Forward for wait activities
New transaction properties for synchronous and one-way BPEL processes
Set the transaction behavior for initiating calls:
- Ø Joins a caller's transaction or creates a new transaction (required)
- Ø Uses the same thread in the same transaction (required)
- Ø Creates a new transaction and existing transaction is suspended (requiresNew)
New delivery properties for asynchronous or one-way BPEL processes
Set the persistence policy in the delivery layer:
Messages into the system are saved before being picked up by the service engine
- Ø In the delivery store (async.persist)
- Ø In memory (async.cache)
- Ø Or not at all (sync)
Property Inspector for Composite properties
New property editor to set and edit composite properties, e.g transaction and delivery properties of BPEL process
Dynamic partner links in a BPEL process
If using a WSDL with multiple services that use the same portType, the dynamic partner link allows to dynamically assigning an endpoint reference to a partner link for use at runtime
Specifying XPath expressions to bypass (skip) activity execution now also in BPEL 2.0
- Ø Skip an activity if an XPath expression evaluates to true
- Ø Provides an alternative to using a switch activity for conditionally executing activities
Throwing faults with assertion conditions now also in BPEL 2.0
Assertion condition is executed upon receipt of a callback message.
- Ø If XPath expression is evaluated to false, BPEL fault will be thrown from the activity
- Ø Pre Assert: Condition is executed before the invoke or reply activity sends out the outbound message
- Ø Post Assert: Condition is executed after an invoke activity, receive activity, or onMessage branch receives the inbound message
Setting Timeouts for Request-Reply and InOnly Operations in Receive Activities now also in BPEL 2.0
Provides a timeout setting for:
- Ø Request-reply (synchronous) operations
- Ø In-only receive (asynchronous) operations
Alternative to using the onMessage and onAlarm branches of a pick activity to specify a timeout duration for partner callbacks.
Copy and paste in a BPEL process.
- Ø Copy and paste activities in the same BPEL project or between BPEL projects
- Ø Design an activity once and use it in multiple places, editing it as necessary
Infrastructure Platform Enhancements
- Ø Reduced Memory Footprint: Lower memory (JVM heap) requirements associated with composite deployments.
- Ø Additional HA capabilities:
· Support for Active GridLink for RAC: No need to define one datasource per RAC instance. Faster failover.
· Multi-data source continues to be supported and more hardened
· DB persistence for Tx logs – Eliminates need for shared disks. Performance impact not assessed at this point.
Purge Enhancements
- Ø Partition based purging: Row movement of active instances of long running processes to enable dropping a partition.
- Ø Hybrid approach: Partition only a subset of high volume tables.
- Ø Purge optimizations: Avoid redundant pruning of data, additional indexes etc.
- Ø Purge by composite name: Purge instances associated with a specific composite name.
Read more: http://www.soabyte.com
No comments:
Post a Comment