In the BPEL console, we've introduced a BPAF model for the information that needed by Execution History chart. But right now, it just maps the following BPEL events.
We've had many more events in the ODE, here is the table of those events. http://ode.apache.org/ode-execution-events.html
In the BPEL_EVENT model, we've stored the whole object into one column, meanwhile, we've stored a string version of this BPEL_EVENT model into another column (noted that this column length is 254 at most, means big data will be truncated), the problem of having it kept as a whole is that the information is NOT searchable. In order to make them searchable, we will need to get the data that we are trying to make them searchable into a separate column in our BPAF model. Currenlty in the BPAF model, we have just kept the line number, which is needed for the bpel2svg module.
So the question here is that: what other events that we are intereted, and what corresponding data that we intend to make them searchable.
Here is the one we discussed: combinations of (1) correlation key/value (possibly value range?), (2) date/time range and (3) process instance status.
What is your thought? After we define the searchable information, we need to compile a list of events that get mapped to BPAF model in our user guide.
Other events I think we should handle are:
CorrelationSetWriteEvent - to be able to get notification of the correlation key/value associated with a process instance, which should then be stored as separate properties. We need to make sure BPEL processes with multiple correlation keys are catered for. This is also one of the specified search criteria above - if the value is numeric (for example), then it might be useful to specify a query based on a range of numbers. If this is problematic, then just handling equality for now is a good start.
ExpressionEvaluationFailedEvent and ExpressionEvaluationSuccessEvent - it may be useful to understand if an expression was evaluated, especially if it failed - during debugging.
PartnerLinkModificationEvent - for example if a dynamic endpoint reference is assigned to a partner link
ProcessMessageExchangeEvent - when a process instance receives a message - not sure about this one, depends whether it contains any interesting information. Usually a process will store an incoming message into a variable, so if we are recording the variable modification events, then this may do.
ScopeCompletionEvent, ScopeFaultEvent and ScopeStartEvent - from a debug perspective, I think these are required.
VariableModificationEvent - definitely required, and should probably make the variable name and value searchable?