Dtgov List processes. Audit information

[virchete]

Related jira issue:

https://issues.jboss.org/browse/DTGOV-117

We need to list all the active dtgov processes, displaying the current status and being able to stop the workflow process.

For obtaining the information firstly we tried to see the data that is stored in the ProcessInstanceDesc:

I took a look to the listProcessInstances method inside of the org.overlord.dtgov.jbpm.ProcessBean and this is the info we can take for every process that is running.

(org.jbpm.kie.services.impl.model.ProcessInstanceDesc) ProcessInstanceDesc{id=1, processId=overlord.demo.SimplifiedProjectLifeCycle, processName=Simplified ProjectLifeCycle Demo, processVersion=1, state=1, deploymentId=org.overlord.dtgovtgov-workflows:1.2.1-SNAPSHOT:SRAMPPackage:ksessionSRAMP, initiator=dummy, dataTimeStamp=2014-06-25 17:29:14.138}

We can take the processName and the state, that is a number. Is this enough for the development? I was expecting the status as a String.

Also for the development was required a stop process action. Taking a look to the ProcessEngineService class, it does not have a method like stopProcess, the only method that i have seen could accomplish this is the processEngineService.undeployUnit(KModuleDeploymentUnit unit);

This information is not enough.

The solution provided by Eric is to store the workflow data in another s-ramp artifact. Right now the workflow information is being stored in a custom property of the artifact being processed.

Then Gary proposed also to make an implementation that take in consideration auditing the information. But it is important that the audit information is not directly dependent with s-ramp.

To consider:

• Audit information --> Do we store the audit information in s-ramp as artifacts, one artifact by audit entry? Or maybe we could store this information in a dtgov table, having a reference to the uuid that they belong to?
• Current workflow information? I consider that we should remove the workflow custom property and create an artifact with this information. This artifact will include the current active workflow information. It would be derived of the artifact processed.
• How to stop the process --> I think this is the code to be used:

        RuntimeManager runtimeManager = kieSrampUtil.getRuntimeManager(processEngineService, deploymentId);

        RuntimeEngine runtime = runtimeManager.getRuntimeEngine(ProcessInstanceIdContext.get(processInstanceId));

        KieSession ksession = runtime.getKieSession();

        ksession.abortProcessInstance(processInstance);

I see this actions, as 2 separate functionalities, for two different pages:

• ListProcesses View. --> we see a table of all the processes,and also it will contain a stop button per process.
• ViewProcess View --> here we can see all the audit information and also will be capable of stopping the process.

[objectiser]

David virgil naranjo wrote:

• Current workflow information? I consider that we should remove the workflow custom property and create an artifact with this information. This artifact will include the current active workflow information. It would be derived of the artifact processed.

Yes, definitely remove the workflow custom property.

What I would like us to consider is rather than create a specific sramp artifact for this information, that we should leverage the audit capability - and even if this is implemented using another sramp artifact, then it shouldn't be derived from the artifact - there should only be loose coupling between the workflow information and the artifact(s) it relates to, in case we want to store the audit/workflow information elsewhere (i.e. gives us that flexibility) - but primarily because in the future, the "artifact" (i.e. the subject of the workflow) may not actually be in sramp, it may be related to an artifact in github, etc.

We will need an audit capability to record what triggers have occurred and the steps that were taken by DTGov in response to those triggers. Although this mechanism does not currently exist, I believe the capability of listing currently active process instances could leverage this audit information.

So rather than create two sets of information, one specific to the active workflow process instances, and the other general audit information, I think it may be better to just define the initial audit mechanism and store audit events for "workflow started" and "workflow finished", with the events having properties referencing the artifact(s) and jBPM process instances involved.

The main benefit of storing a separate list of active process instances is it saves time building up the info from the audit log - but possibly that can be overcome using caching of results?

Just want to avoid duplication of information if possible. But depends how much of a pain it will be to derive the information from the audit log. As the architecture becomes more event driven, then it should be easier to update this type of derived information as changes occur (i.e. processes are started/stopped).

[eric.wittmann]

As we are considering moving dtgov to become a much more generic platform (not particularly tied to s-ramp) which is able to perform governance across multiple event sources, we certainly will need some sort of audit log of what governance actions were taken based on what events.  Those audit events will need to be sufficiently realized so that we can make sensible correlations between them - since ultimately we need to present that information to the user in reasonable ways.  In other words, we will want to show the user (for example) how a particular artifact moved through the various phases of its lifecycle.

I don't think we've thought enough about how this will work for me to even begin considering an appropriate implementation.

It seems like a difficult task for David to implement a generic Audit log that will solve the immediate problem of listing the currently running processes but would also server as the generic Dtgov 2.0 audit log.

Does this mean we defer the process instance work until we have sorted out dtgov 2.0?

[objectiser]

Good point - it may depend if we are happy to consider any current persistence representation of the active process instances to be a stepping stone to a more generic mechanism - and whether this will involve migration of any kind?

As this will be a useful feature to have for the current version, then I guess we need to provide a short term solution for storing the information - but believe it should be decoupled from the current sramp artfiacts, and not made publicly visible (with the exception of through the process instances UI).

[virchete]

And then this means, that we go for a short term solution.

Then let's define how do we want the short term solution to be implemented. Storing all the workflow status data in a separate s-ramp artifact?