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).

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?

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).