New features in BPEL 10.1.3.4 includes
1.Improved visibility of Engine Threading Model
Current:
a. Dispatcher page is static
b.Difficult to use when monitoring messages under load
c.Needs to be manually refreshed
d.Lack of messages details in a queue
10.1.3.4:
a.Dynamic, updated in real-time
b.Shows information about
i.Running threads
ii.New invocations that are queued
iii.Incoming calls that are queued.
c.Drill down on each thread to get process id , to see which process messages are coming from
2.Improved Statistics Collection
Current:
a.Statistics collection aggregates the times across all requests, regardless of process or instance
b.Many users find the current statistics page difficult to use for pinpointing bottlenecks, due to aggregation
c.Users need to flip between audit trail and statistics pages
d.Intended to be used by engineering
10.1.3.4
a.Statistics are aggregated on a per-process basis
b.Statistics are displayed on the process map
c.Easy to identify bottlenecks
post 10.1.3.4 (10.1.3.5)
a.Overlay following on process map:
• Transaction boundaries
• XML payload sizes
• Service invocation times
b.Persist statistics
3.Minimize XML Coding Errors
10.1.3.4
a.Test compliance of payload with schemas defined in process/WSDL
b.Reduce debugging effort when incorrect payloads are received by BPEL
c.Only starting invocations in 10.1.3.4
post 10.1.3.4 (10.1.3.5)
a.Validate XML against other schemas from project
b.Test XML against XPath from process
c.Enable unit testing of custom XPath functions
4.Rescuing Lost instances
current
A BPEL instance was started. But nothing appeared in the BPEL
Console or audit trail.Caused by a transaction rollback in certain
circumstances.Analogous to a database rollback
10.1.3.4
a.Detect 3rd party manipulation of the JTA transaction
b.Move audit trail persistence to an asynchronous thread (to increase visibility of errors within the process)
5.Automated Recovery agent
10.1.3.4
a.Implement automated recovery agent for failed activities/messages
b.Improve visibility of errors encountered during recovery by writing them out to the instance audit trail asynchronously
c.Agent can be triggered manually or via schedule
• Schedule during non-busy periods
d.Allow batch limits for each recovery attempt
6.Collection of Support information
10.1.3.4
a.Cut down on round-trips between customer and support/development for debugging information
b.Make BPEL Console single tool admins need to consult
c.Bundles:
• JVM thread dump
• JVM heap statistics
• Dispatcher statistics
• BPEL domain logs
• Request statistics
• Dehydration statistics
d.Can also export BPEL process
7. Deployment Plan
Current
a. Deploying a BPEL project to a different environment (e.g.,
dev, test, production) requires various changes to the project.
For example:
• Location of services
• Port numbers of services
• Location of hosted WSDLs
• Location of hosted XSDs
b.Changes have to be made in various files
c.Changes have to be made manually
d.Often need a different BPEL suitcase for each environment
10.1.3.4
Deployment plan
a.allows users to develop in one environment and then - without touching the source code - deploy the suitcase to another environment
b.holds the configuration for one environment.Instead of managing separate suitcase files, the user generates a deployment plan from a suitcase and modifies the configuration for each environment
c.eliminates the need to provide customized suitcases for each environment
Things to Come in 10.1.3.5
a.BPEL debugger
• Set breakpoints
• Step-by-step
• Introspect and modify XML variables
b.Log viewer
• Search and filter on particular instance
c.Notification
• Engine events like startup, shutdown
• Auto-recovery agents fails to recover
• Process state changes (active to stale, etc)
d.Improve XML validation
• Validate XML against other schemas
• Test process or customer XPath expressions
e.Import/Export instances runtime data
• Offline re-creation
