Versions Compared

Key

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

...

  • Widget Requirements and Design
    • *** Note 1: actual screen layout and display can be changed based on implementation decisions. ***
    • *** Note 2: the service list panel columns can be changed based on the database table columns. ***
    • 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 (e.g., so-monitoring-config.yaml). So, they can be customized and support internationalization.
        • Based on the fields and buttons configuration, the Service List widget will render the corresponding fields and buttons.
        • The search criteria fields support the field validation based on the field type; e.g., length, date format, time format.
        • The Service List panel supports pagination, which will be controlled by the Navigation buttons.
        • Queries a service list from the SO Request DB through the Monitoring REST APIs.
        • Action buttons are enabled/disabled based on data population and/or context.
        • The wild characters are supported for the Search fields.
        • Note: for security (who, when and how access info), the requester info (User Id) is needed. It could be a future requirement.
          • The flexible filtering expression could be a stretch goal (it depends the BE Request DB query capabilities)

...

        • The Close button is always enabled.

    • The following is a possible alternative service instance rendering based on the Camunda Cockpit screen. If we go this path, the Camunda Cockpit customized plugin would be used. 



    • Task Drill-Down/Drill-Up and Detail View
      • Capabilities
        • 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.
      • Design
        • When a selected/clicked task activity type is the Call Activity, the Drill-Down button is enabled.
          • if (activityType.equals('CallActivity') {enableDrillDown();}

        • If the current process instance has its parent process instance (from the activity tree), the Drill-Up button is enabled.
          • if (parentActivityInstanceId != null) {enableDrillUp();}

...

  • REST APIs for providing data to UIs
    • Capabilities
      • Provides REST services, by utilzing 1) Camunda REST APIs, such as BPMN XML string, process activity data, process variable, statistic, and 2) SO Request DB APIs for a service list.
      • Consolidate data responses from multple Camunda calls (both from process and history database) and feed them to UIs.
      • Use of HistoryService APIs, example, processEngine.getHistoryService().createHistoricProcessVariableQuery().xyz
      • Set a History level to ACTIVITY as a minimum; AUDIT (default) level for process variable tracing
      • Provides workflow tracing (between parent-child workflows, interaction with other services; service task in and out); example,
        • processEngine.getRuntimeService().createExecutionQuery().processVariableValueEquals("serviceInstanceId", serviceInstanceId).singleResult();
      • Custom Query
        • Custom Query against History ACT_HI_DETAIL database table, as needed
      • Create a REST API, getServiceList with search criteria
        • Enhance MsoRequestsDbAdapter and MsoRequestsDbAdapterImpl to implement getInfraRequest(...) with additional parameters
        • invoke getInfraRequest(...) to collect service list data based on search criteria.
        • or use the RequestDB adapter directly.
    • Design
      • Write REST APIs in the new mso-api-handlers/mso-api-handler-monitoring
        1. getServiceList(Map searchCriteria...) invokes new getInfraRequest(Map searchCriteria...)
        2. getProcessInstanceId(String serviceInstanceId);
        3. getprocessDiagram(String processInstanceId);
        4. getprocessInstanceDetail(String processInstanceId); 
        5. getProcessInstanceActivity(String processInstanceId); 
        6. getProcessTaskDetail(String processInstanceId, String taskId);
        7. getProcessTaskType(String processInstanceId, String taskid);
    • The following diagram depicts the API interaction.

...