Jira子任务驱动主任务状态变更

Posted 2023-03-20

参考技术A 实现子任务状态变更时，主任务状态随之变动。如只要有子任务进入开发中时，主任务自动进入开发中；所有子任务提测后，主任务自动进入待测试。

插件： Jira Misc Workflow Extensions(JMWE)

使用Spring+观察者模式处理绩效评定流程状态变更及邮件发送

   绩效评定流程在每月所有员工绩效计划打分结束后，由系统自动按评定关系表（树状结构，父结点是子结点的评定人，各部门总监为最底层评定人）发起任务，将最底层评定人下属的信息组装为表插入审批表单中，平行的最底层评定人为并行的子任务。最后一个平行最底层评定人评定结束后，系统会自动将新建子任务给平行最底层评定人的评定关系上层，并将所有平行最底层评定人的评定信息汇总作为审批表单，由此迭代直至找到平台级最终评定关系为止，流程结束。由于该流程极其特殊，既不是普通的并行或串行，也不是普通的子任务或会签，除发起结点、结束结点外，只有一个评定结点，所有评定人的评定活动均被看作评定结点的子任务，jbpm认为所有子任务均是并行关系，在业务逻辑中使用评定关系表等基础信息标识不同子任务的层级关系。由于无法使用统一的流程流转，在设计好流程及表单后，单独设计引擎驱动该流程，并在流程运转过程中更新基础信息表并负责发送邮件。

  单独的流程引擎设置、员工绩效基础信息表更新及邮件的发送由不同程序员开发。其中流程引擎在驱动流程运转过程中，会根据需要通知相应逻辑更新表及发送邮件。在开发引擎时，我使用观察者模式对流程进行重构使更新员工绩效基础信息和邮件发送逻辑的开发均独立进行，使代码的耦合进一步降低。

    在系统中存在这样的情况：一个功能点触发的动作会引起相关一个或者多个功能点在业务上进行对应的数据处理。而到底有几个功能点要做出相应，要看客户实施了哪些需要作出响应的具体功能点。

      例如：A功能点的某项业务会触发B、C、D三功能点做出回应，而客户订阅了哪些功能点是个未知数，也许客户不需要C功能点，对A功能点业务操作作出响应的仅有B、D。

      根据上面的需求可以得出，设计上要尽量的松散耦合，保持各功能点的独立性。观察者模式责无旁贷的跳了出来。

       我们的系统在整体上采用Spring framework来进行Bean管理。利用Spring通过配置文件来加载具体的类的方式——相当于被包装了的工厂，使得代码更加灵活。同样，观察者模式的应用可以很好的借用Spring framework提供的平台，变得更加灵活。

        首先，我们定义一个抽象的观察者

/**
 * TODO（描述类的职责）
 * @author chao.gao
 * @date 2015年11月30日 上午8:50:59
 * @version <b>1.0.0</b>
 */
public interface BaseObserverHandler extends Observer {

}

 

/**
 * A class can implement the <code>Observer</code> interface when it
 * wants to be informed of changes in observable objects.
 *
 * @author  Chris Warth
 * @version %I%, %G%
 * @see     java.util.Observable
 * @since   JDK1.0
 */
public interface Observer {
    /**
     * This method is called whenever the observed object is changed. An
     * application calls an <tt>Observable</tt> object‘s
     * <code>notifyObservers</code> method to have all the object‘s
     * observers notified of the change.
     *
     * @param   o     the observable object.
     * @param   arg   an argument passed to the <code>notifyObservers</code>
     *                 method.
     */
    void update(Observable o, Object arg);
}

  具体观察者：

public class EndProcessMailSentHandler implements BaseObserverHandler{
//实际update方法，具体实现略
}

   在观察者模式中，目标角色是被客户程序调用，通过目标角色来通知具体观察者角色。在传统观察者模式中，目标角色中维护有一个观察者角色的列表，列表中的观察者角色通过其它程序进行添加维护——这就注定了观察者列表的改变会引起代码的修改。而通过Spring framework的配置方式注册观察者角色则避免了这种情况。

/**
 * TODO（描述类的职责）
 * @author chao.gao
 * @date 2015年11月27日 下午4:15:36
 * @version <b>1.0.0</b>
 */
public abstract class BaseObservedHandler extends Observable {

	private List<BaseObserverHandler> observerHanlers;

	/**
	 * 被观察者进行操作
	 * @author chao.gao
	 * @date 2015年11月27日 下午4:18:56
	 * @param context
	 */
	public void obServedOpertion(EvaluationPorcessContext context) {
		if (observerHanlers == null || observerHanlers.isEmpty())
			return;
		for (BaseObserverHandler baseObserverHandler : observerHanlers) {
			super.addObserver(baseObserverHandler);
		}
		super.notifyObservers(context);
	}

	/**
	 * 获得observerHanlers
	 * @return List<BaseObserverHandler>
	 */
	public List<BaseObserverHandler> getObserverHanlers() {
		return observerHanlers;
	}

	/**
	 * 设置observerHanlers
	 * @param observerHanlers
	 */
	public void setObserverHanlers(List<BaseObserverHandler> observerHanlers) {
		this.observerHanlers = observerHanlers;
	}

}

  下面是Spring framework配置文件的一个片断——它应该出现在用到目标角色的具体客户程序对应的Spring配置文件中。它将具体观察者的别名存放在一个list里面，使用Spring为生成的目标角色注入。

  如下：

<bean id="endProcessService"
		class="com.fx.oa.module.per.evaluation.workflow.server.service.impl.EndProcessService">
		<property name="jbpmOperatorService" ref="jbpmOperatorService" />
		<property name="evaluationProcessService" ref="evaluationProcessService" />
		<property name="observerHanlers">
			<list>
				<ref bean="endProcessHandler"/>
				<ref bean="endProcessMailSentHandler" />
				<ref bean="endProcessSaveFormHandler"/>
			</list>
		</property>
	</bean>

本文出自 “江南矿工技术空间” 博客，请务必保留此出处http://jncumter.blog.51cto.com/812546/1747203