Page History

...

• 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. The important fields would be the service instance id, requester id, date/time for filtering.***
  • *** Note 3: we can add a new field, Proc_Inst-ID varchar(64) to the Infra_Active_Requests database table, to associate it (as a top-level process instance id) with the service instance id
  • 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)

...

• • Service Statistic Widget (stretch goal)
    • 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.
    • Design
      • Query for service list data for a given search criteria. 
        • Use a REST API, getServiceList with search criteria parameters based on a new getServiceStatic(...) based on the  getInfraRequest(...)
      • Count the total number per status (Finished, Processing, Error)
      • Status Total / total number

...

• 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; currently, it is set to FULL
      • ProcessEngine processEngine = ProcessEngineConfiguration.createProcessEngineConfigurationFromResourceDefault().setHistory(ProcessEngineConfiguration.HISTORY_FULL).buildProcessEngine()
    • 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...)
   1. getServiceStatistic(Map searchCriteria, String status);            // get the statistic percentage for the status
2. getProcessInstanceId(String serviceInstanceId);                               // get the processInstanceId through GET /history/variable-instance/{id}
3. getprocessDiagramXML(String processInstanceId);                          // get a process instance, get a process definition id, and get diagram
4. getprocessInstanceDetail(String processInstanceId); 
5. getHistoryActivityInstance(String processInstanceId);                       // GET /history/activity-instance?processInstanceId={processInstanceId}
6. getProcessInstanceParent (String processInstanceId);
7. getProcessInstanceChildren(String processInstanceId);
8. getProcessTaskDetail(String processInstanceId, String taskId);
9. getProcessTaskType(String processInstanceId, String taskid);        // query if this task type is "Call Activity" for drilling down
10. getServiceStatistic(Map searchCriteria, String status);                     // get the statistic percentage
11. 
    
    • The following diagram depicts the API interaction.

• Custom History Event Producer  (stretch goal)
  • Populate additional data in history with extensibility
  • It is an optional component. We plan to use it when the default Camunda process and history data is not sufficient.

...