2 Replies Latest reply on May 23, 2014 7:50 AM by Eric Wittmann

    Design time governance - short vs long running workflows and other thoughts.....

    Gary Brown Master

      In the future we are going to want to include some additional validation capabilities, such as impact analysis on services that use a changed api. This will be local within a 'stage', rather than concerned with moving artifacts between stages - but could be a pre-condition to the artifact being considered for promotion to the next stage.

       

      Is this the way we want to handle such validation? The advantage is that the workflow controls the ordering in which the validation is performed, what type of validation is performed, and what action to take if a validation failure occurs. If in the initial stage (e.g. dev), then stopping the workflow would be reasonable, as once the issue was fixed, the updated artifact would be saved triggering another workflow.

       

      An alternative may be to have separate validation modules that are triggered by specific artifact change events, where those validations could be performed using bpmn workflows or rules. However then we potentially loose the dependency between the rules - i.e. preventing promotion of the artifact unless it passes all validations. This may be resolved by treating the validation modules as a necessary step before optionally triggering the workflow (i.e. the workflow trigger configured to determine whether validation issues should prevent it from running). This also implies the validation results should be stored somewhere - most logical target would be the artifact itself.

       

      I think having the workflow control the validation steps seems most straightforward for now - but should try integrating rules to perform the actual validation steps.

       

      The other issue is the scope of the workflow. We currently provide an example of a single workflow for the full lifecycle. This is good from the perspective of showing/documenting an overall workflow, but from a runtime perspective, it means instances of this workflow could be very long running - which means they cannot be updated once running.

       

      Wondering whether it is better to have a workflow per stage - that way they are very localised, and short running - their only responsibility is to define what should happen to move an artifact from one stage to the next. This means that from a workflow maintenance perspective, it is much easier to introduce changes without worrying about existing running process instances.

       

      The disadvantage is that potentially the context from previous stages would be lost - although this could always be stored as properties on the artifact.

        • 1. Re: Design time governance - short vs long running workflows and other thoughts.....
          Gary Brown Master

          One reason why I like the idea of the short lived workflows is that it may actually fit better with the roles responsible for defining/maintaining the workflow.

           

          For example, the person who should define the governance steps (e.g. validation) that should happen determine if an artifact moves from dev to test is the Test Manager - potentially in collaboration with the Development Manager. Whereas decisions about what steps should occur for an artifact to move from Test to Production should probably be the responsibility of the Product environment manager.

           

          Although the workflows can use human tasks to get authorisation from such managers on an artifact by artfact basis, those managers should also have control over the governance process that moves an artifact into their realm of responsibility.

          • 2. Re: Design time governance - short vs long running workflows and other thoughts.....
            Eric Wittmann Apprentice

            I have a couple of general thoughts on this.  First, I'm not a fan of short running workflows.  I think the whole point of modeling a business process using a workflow technology is so that the entire flow can be represented and thus documented.  If we start breaking up a single business process into its component parts, why are we using workflows?  We could simply trigger something else instead of workflows (e.g. a java handler) and implement functionality that way.  That said, I do understand the issues involved with upgrading instances of workflows that are long running.  I'm worked with/on workflow products in the past that could upgrade live instances, but my understanding is that jbpm cannot.