Page History

• Rationale

  • The BPMN Monitoring has been defined as a pain point since the Amsterdam release. Camunda cockpit regardless community or enterprise editions were designed from a BPMN process management perspective. Camunda is not an OSS vendor, and they don’t have a reason to cover service-level monitoring. As a result, it does not meet service-level orchestration monitoring from the OSS perspective.

  • Search is an Camunda enterprise feature, but we need to provide searching capability for non-enterprise edition.
    • Finding right process instance(s) for a NS/VNF service request is tedious and hassle.
      • a service request could invoke many sub-process workflows.
      • Needs drill down and drill up to cover sub-process instances.
    • 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), orCould use a database holding the association
    • Allow VID, UUI or external apps application users 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. 

...