Index Changes

Difference between version and version     

Back to Extended Management Actions, or Extended Management Actions Info

At line 1 added 5 lines.
__Refer the design tab for the design and architecture of the extended management actions__
At line 7 added 31 lines.
BPEL SE supports [persistence |] and [monitoring|]. Usage of BPEL SE over time would result in the accumulation of the data in the persistence store.
! Purging scripts:
Users would like to have more free space by deleting old and unwanted records. This applies to both persistence data store and monitoring data store. It's relevance and importance is felt more for monitoring, since monitoring records a whole lot more events than persistence. 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. Primarily persistence data is used to recover instances from events such as system crashes. 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 cluster support. It is only applicable for single engine users and is provided conveniently from the NB runtime GUI.
! Quick Walk Through:
When a user right clicks on a component say BPEL-SE in the NB runtime, user sees the following actions.
[{Image src='' width='' height='' align='left|center|right' }]
The actions are enabled depending on the state of the BPEL-SE. Purge data action for persistence is enabled if the engine's persistence is turned on. Likewise for purging monitoring data.
At line 67 changed 2 lines.
(__Important__: components need to consider internationalizing the UI aspect of this, namely DisplayName and Description values.)
At line 71 changed 1 line.
Even though the scope doesn't include clustering, the common management API has been designed keeping cluster scenario in view.
Even though the scope doesn't include clustering, the common management API has been designed keeping cluster scenario in view. This API is also designed keeping in mind future requirements where the MBean operations may take parameters.
At line 129 added 5 lines.
! __Quick Walk Through__: \\
When a user right clicks on a component say BPEL-SE in the NB runtime, NB will query the component MBean using the common management API mentioned above.
At line 103 changed 1 line.
At line 113 changed 1 line.
At line 131 changed 1 line.
When the user clicks on the action, "Purge Data", NB will query the MBean using the same common management API. NB will query corresponding component MBean and the operation specified in the corresponding xml section associated with the "Purge Data" action.
<ns0:DisplayName>Purge persistence data</ns0:DisplayName>
<ns0:Description>Deletes persistence data</ns0:Description>
! __Feed back__: \\
Feedback and Todos to consider in future.
* Some components may not keep the state (JBI component states, init, shutdown, started). It will be useful to accommodate those components by passing in a "state" value as part of the getAction() API. How do we support custom states? Perhaps a simple "string" parameter is sufficient. Please note that the common management API is already designed to take in parameters.
* Involve HIE for their inputs on how to display the actions consistently across all components.
* command line/scripting option should be made available
* Could there be cases where we want to mix the configuration display with an action related to that configuration? If we want to address this case, we may need to enhance the configuration MBean support to take in actions associated with property changes.
* Back to [SystemicQualities.Monitoring]

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