You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

  • 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.
    • 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?
  • 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 service instances
    • Service Instance Rendering and detail panel views
      • with sub-service instance drill-drown and drill-up capabilities
        • A service instance could be realized by multiple process instances
      • with process / task detail
      • Topology (workflow) views during/after orchestration
    • 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)
  • Widget Requirements
    • Service List Widget 
      • Capabilities
        • Provides monitoring capabilities for processed services based on search criteria
          • Configurable Search Criteria filtering: Service ID, Operation Type, Status, User Id, Date/Time range
          • Actual filtering criteria fields could be changed based on configuration
        • The Service List panel will display the filtered Service list.
        • This widget can be triggered from other UIs (VID, UUI, external applications).
      • Design
        • The search criteria fields will be defined in a search criteria field configuration file. So, they can be customized and support internationalization.
        • Queries a service list from the SO Request DB. 

    • Search Operations:
      • Utilizes SO existing Request DB APIs to get the Service List.
      • Provides filtering, Service ID, Operation Type, Status User Id, Date/Time range (actual criteria could be configured).
      • Click the Search button, and the filtered service list will be displayed.


  • Service List Get Service Instance Monitoring
    • Select a row and click the Monitor button. Then, it will go to the Service instance (= process instance in Camunda) monitoring widge for the selected Service instance.


  • Service Statistic Widget
    • When, the static button is clicked, the Service Statistic dashboard will be shown. 
    • Collect and display Service Instance statistic per filtered service list, for the filtered service range.



  • Service Instance Rendering and Detail View
    • Get a process definition XML through the Service Id and Process instance association.
      • use Camunda REST API, get/process-defintion/{id}xml
    • Get the state of a process instance from the activity-instances
      • Use Camunda REST API, get/process-instance/{id}/activity-instances
    • Render the BPMN XML with bpmn.io and places markers on top of it, and provide Service instance detail views.


  • Task Drill-Down/Drill-Up and Detail View
    • Support Task (CAll Activity) drill-down/drill-up capabilties.
      • When a call activity task is selected, the Drill-Down button will be enabled.
    • Provide detail views for the selected Task.
      • When a task is selected including the call activity, the Detail view panel will display details for the selected task.


  • Sub-Service Instance Rendering and Detail View
    • Get a sub process defintion XML through the Service Id and Process Instance association.
      • Use Camunda REST API, get/process-definition/{sub-id}/xml
    • Get the state of a sub-process instance from the activity-instances.
      • Use Camunda REST API, get/process-instance/{sub-id}/activity-instances
    • Render the BPMN XML with bpmn.io and places markers on top of it, and provides service instance detail views.
    • This widget uses the same code of the Service Instance Rendering and Detail View with the sub-process instance id. 
    • The Drill-Up button will be enabled.



  • x









  • No labels