Versions Compared

Old Version 32

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version 33

changes.mady.by.user Byung-Woo Jun

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
  • Rationale

    • The From the service/network operator perspective, the BPMN Monitoring has been defined realized as a pain point since the Amsterdam release. Camunda cockpit regardless community or enterprise editions were designed from a BPMN process management perspective. Finding right process instance(s) and data for the  service / resource request is tedious and hassle.

    • 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 don't have any business value to cover the OSS opearator-friendly monitoring.

    • There is Camunda cockpit, but regardless community or enterprise editions, they were designed from a BPMN process management perspective. 

      • They require the user BPMN definition and design knowledge for monitoring.
      • The user needs to know which service invokes which BPMN process definitions and how those process definitions are related to each other.
      • There could be thousands process instances daily, and a top-level process instance can have multiple sub-process instances (call activity instances).
        • It is not easy to find right process instances and data
    • We 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
    • editions offer to
      • Facilitate the finding of associated process instances and data 
        • Allow VID, UUI or external application users monitor process workflow process (graphically and text-based) based on their search criteria.
      • Bypassing all the tedious manual search through process definitions and instances
      • Eliminating prerequisite knowledge of process definition relationships for monitoring - learn as you drill down and up
        • Needs drill down and drill up to cover sub-process instances graphically and text-based.
    • 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
      • Allow VID, UUI or external 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. 

Image Modified

  • 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
    • 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)
  • High-Level Design
    • Collect a service list based on search criteria
    • Associate the service instance /request ids with the process instances without manual intervention
    • Provide a hyperlink to launch process instances, which provide
      • process workflow diagram rendering
      • process instance activity paths (color coded) on the diagram and text panels
      • This provides where the process instance executions are.
      • process variables panel
      • drill down and up for child-parent processes (call activities)
    •  Provide the statistic report page for the collected service list.
      • widget)
    • Color coding/visual indication of statistic and task execution trails


    Completed, in_progress, failed, pending
  • Design
    • Collect a service list based on search criteria through the REQUEST Database table.
      • Service Instance Id,
      • Request Id
      • Service Name
      • Status
      • Date
    • Display service list statistic (COMPLETED, IN_PROGRESS, FAILED, PENDING) for the selected service list.
    • Provides the hyperlinks between the service list to Camunda Process instances to
      • Automate tedious manual steps for finding target process instance(s), bypassing tedious search starting from the process definitions
      • Allow VID, UUI and external API users monitor their process instances and data
    • Use Camunda REST APIs to: 
      • Associate the Request Id / Service Instance Id (and other search criteria) to the top-level process instance without manual intervention
      • Use a process variable holding the Request Id for the process instance search
      • Get the process definition XML for workflow rendering
      • Get the process instance details such as activities and variables
      • User process activity data for 1) execution trail, 2) drill-down and drill-up.
    • Display and render collected process instance data on the pages
      • Workflow Diagram canvas (zoom in/out and scrolling)
      • Process Information panel
      • Activity Instances and Process variable panels


  • UI Widgets
    • Service List 
    • Service Statistic
    • Process/Service Instance Rendering and Detail

...