Index Changes
Page Difference

Difference between version and version     

Back to Extended Management Actions, or Extended Management Actions Info


At line 4 added 1 line.
__Refer the design tab for the design and architecture of the extended management actions__
At line 6 added 20 lines.
\\
BPEL SE supports [persistence |http://wiki.open-esb.java.net/Wiki.jsp?page=BPELSEPersistenceAndRecovery] and [monitoring|http://wiki.open-esb.java.net/Wiki.jsp?page=BPELMonitor]. Usage of BPEL SE over time would result in the accumulation of the data in the persistence store.
! Purging scripts:
Users would like to create more space by deleting old and unwanted records. This applies to both persistence data store and monitoring data store. Providing out of the box scripts to do purging will take out the hassle from end users to write such scripts. The hassle is more pronounced for persistence data since persistence schema is not exposed like monitoring schema.
! Archiving scripts:
''Post Sierra release. Sierra release is scheduled somewhere around 2nd quarter of 2008''.
Users would like to back up their data before purging or back up their data for various reasons such as auditing or providing analytics. While we recognize that providing out of the box archiving scripts would be useful, we had to drop it for Sierra due to time constraints. At the same time since the monitoring schema is exposed to the users, it is expected that monitoring users writing archival scripts on the exposed schema is not unreasonable. Persistence data is used to recover instances in the unlikely events such as crash of BPEL SE. It is not directly used by the end user and hence is felt that there won't be a requirement to archive the persistence data.
! Scope:
This feature is provided as a developer version of the feature. We would like to get more feedback before we proceed with more advanced requirements which provide options such as parameters to the purging and archiving scripts. Some such parameters could be; date, state of instances, type of instances and so on.
Would the users appreciate such an out of box solution or would they prefer writing their own scripts as DB ownership issues pop up in enterprise deployments?
Hence the scope of this feature doesn't include clustering support. It is only applicable for single engine users and is provided conveniently from the NB runtime GUI.
G'day, Anonymous Guest

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-15) was last changed on 03-Mar-09 02:31 AM, -0800 by Gopalan Suresh Raj