Page History

...

• 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 and TOSCA.
    • Associate Service Instance Id (or other keys) to the top-level process instance id. For the association, 
    • Could use a process variable holding the 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 runtime and history process activity report capabilties 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. 

• 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)
      • Access customized SO Service List / Camunda Cockpit widgets from VID, UUI and external APIs.

SO Scalability Requirements

...