- A design idea
- Why not Camunda Cockpit as is: current Camunda Cockpit was designed from a BPMN process management perspective (note: need to study for TOSCA cases).
- It does not meet service-level orchestration monitoring.
- It is designed for BPMN definition/execution monitoring; require process knowledge for monitoring.
- We need higher-level monitoring abstraction for both BPMN.
- Associate Request Id / Service Instance Id (or other keys) to the top-level process instance id. For the association,
- Could use a process variable holding the Request Id / Service Instance id (or other keys), or
- Could use a database holding the association
- Allow VID, UUI or external apps monitor process workflow process (graphically and text-based) based on extensible search keys.
- We need a platform level run-time and history process activity report capabilities out of the box.
- Regardless use of Camunda Enterprise Edition or Community Edition.
- Query to Camunda/ARIA database to extract activities.
- The following diagram depicts the high-level concept.
- Why not Camunda Cockpit as is: current Camunda Cockpit was designed from a BPMN process management perspective (note: need to study for TOSCA cases).
- Rationale
- Search is an Camunda enterprise feature, but we need to provide searching capabilitiy for non-enterprise edition.
- Finding right process instance(s) for a NS/VNF service request is tedious and hassle.
- To facilitate monitoring, we need more than what Camunda Community/Enterprise edition supports.
- provides the process monitoring (instance-search) hyperlink to the SO clients for launching process monitoring.
- Automates tedious manual steps for finding target process instance(s), bypassing tedious search starting from the process defintions.
- Access customized SO Monitoring Service List (or Camunda Cockpit widgets) from VID, UUI and external API users.
- If a service provider uses Camunda Enterprise edition, they can still utilize this SO monitoring on top of Camunda enterprise edition features.
- Many of Camunda enterprise features such as CRUDV and version control of process definitions would be part of SDC.
- ONAP separated workflow design and runtime.
- Several enterprise features are not part of SO monitoring features and are not applicable.
What are current TOSCA orchestrator monitoring capabilities? - SO monitoring should cover both imperative and declarative orchestration. Question: can we have a kind of uniform way of monitoring?Rationale
- Search is an Camunda enterprise feature, but we need to provide searching capabilitiy for non-enterprise edition.
- Finding right process instance(s) for a NS/VNF service request is tedious and hassle.
- To facilitate monitoring, we need more than what Camunda Community/Enterprise edition supports.
- provides the process monitoring (instance-search) hyperlink to the SO clients for launching process monitoring.
- Automates tedious manual steps for finding target process instance(s), bypassing tedious search starting from the process defintions.
- Access customized SO Monitoring Service List (or Camunda Cockpit widgets) from VID, UUI and external API users.
- If a service provider uses Camunda Enterprise edition, they can still utilize this SO monitoring on top of Camunda enterprise edition features.
- Many of Camunda enterprise features such as CRUDV and version control of process definitions would be part of SDC.
- ONAP separated workflow design and runtime.
- Several enterprise features are not part of SO monitoring features and are not applicable.
- What are current TOSCA orchestrator monitoring capabilities?
- SO monitoring should cover both imperative and declarative orchestration.
- Question: can we have a kind of uniform way of monitoring?
- A design idea
- Why not Camunda Cockpit as is: current Camunda Cockpit was designed from a BPMN process management perspective (note: need to study for TOSCA cases).
- It does not meet service-level orchestration monitoring.
- It is designed for BPMN definition/execution monitoring; require process knowledge for monitoring.
- We need higher-level monitoring abstraction for both BPMN.
- Associate Request Id / Service Instance Id (or other keys) to the top-level process instance id. For the association,
- Could use a process variable holding the Request Id / Service Instance id (or other keys), or
- Could use a database holding the association
- Allow VID, UUI or external apps monitor process workflow process (graphically and text-based) based on extensible search keys.
- We need a platform level run-time and history process activity report capabilities out of the box.
- Regardless use of Camunda Enterprise Edition or Community Edition.
- Query to Camunda/ARIA database to extract activities.
- The following diagram depicts the high-level concept.
- Why not Camunda Cockpit as is: current Camunda Cockpit was designed from a BPMN process management perspective (note: need to study for TOSCA cases).
- High-Level Requirements
- Dashboard views of Service lists
- Filtering capabilities based on search criteria
- Configurable search criteria
- Dashboard views of statistics (donuts, pie charts, etc.) for filtered request/service instances
- Process / Service Instance Rendering and detail panel views
- with sub-process/service instance drill-drown and drill-up capabilities
- A process/service instance could be realized by multiple process instances
- with process / task detail
- Topology (workflow) views during/after orchestration
- with sub-process/service instance drill-drown and drill-up capabilities
- Input/output data views for process/task/service task (messages, parameters)
- Display on service / task detail panel
- Provide message log views (could be on a pop-up widget)
- Color coding/visual indication of statistic and service type and status
- Troubleshooting capabilities by manipulating the workflow during orchestration for troubleshooting and retry from the current location (stretch goal)
- TOSCA orchestration monitoring (stretch goal)
- Dashboard views of Service lists
...