关于业务和IT

    偶尔翻开《程序员》杂志2007年6月刊,看到一些关于SOA与业务敏捷的文章,提醒我,我们的软件设计忽略了一些很重要的东西。
    我们在AnyData的设计过程中,实现了对数据表现方式的灵活应变,在某种程度上实现了流程上的应变,但是很多东西都是由专业的IT人员对系统进行调整实现的,因此如果客户的业务出现变化,则必须通知我们的技术工程师,然后由我们的工程师对系统进行调整,从而保证IT的变化,以适应业务的变化。这个过程不是很好,因为这需要我们工程师的参与,也就是说,客户业务的变化时,需要通知我们的工程师,工程师对IT系统进行调整,以适应客户业务的变化。
    这个过程中出现了我们的工程师,而且出现的几率过于频繁了,我们应该想办法减少工程师的在客户业务变化过程中出现的几率,或者尽量不出现,客户自己就可以根据业务的变化调整IT系统。或许我们需要对客户自己的工程师进行培训。
    对于流程命令的添加比较复杂,因为这需要我们的开发工程师参与,在开发部编写流程命令,然后对流程命令进行测试,测试通过之后交给我们的服务工程师,由服务工程师给客户升级。如果可以通过脚本的方式添加新的流程命令,则服务工程师可以非常方便的客户哪里添加一个流程命令。
    这实现起来完全没有困难。流程命令是显示在程序界面上,供用户操作数据时用的,一般需要一个对话框,提醒用户要进行的操作,并且在操作之后给出一个提示,是否成功等等。由于我们的AnyData中支持自定义的对话框,这个对话框可以在流程命令中被引用。在对话框中添加按钮的消息响应函数完全可以通过脚本实现。所有的脚本和自定义对话框都保存在服务器上。
    还有一种办法完全也可以实现流程命令的现场编写。那就是在客户的环境中增加一个业务管理工作站,可以通过C#Express在创建新的流程命令。当然这需要工程师具备简单的编程能力。通过这种方式编写的程序代码也应该保存在服务器上,具体的说应该是保存在流程设计器中,流程命令的代码都被保存在流程命令表中。
   流程命令保证了我们可以随时给业务数据增加新的操作,但是如果需要增加新的事件处理规则怎么办?例如在打印结束之后,我们应该在通知HIS系统,某个数据打印完成。如果我们把打印操作也作为流程命令来处理,也没有问题,因为我们可以现场调整流程命令。如果将已经将打印内置到应用程序当中了,则只能通过脚本编程来处理打印完成事件。
    上面的事件是系统内部的事件,如果有来自系统外部的事件怎么办?例如在HIS系统中刚刚创建一个新的检查申请,HIS系统发出一个消息,则需要在我们的系统中处理处理这个消息,怎么办?
    我们在程序中有系统事件接口,可以将外部的消息转换为内部的消息。消息的处理函数完全可以通过脚本实现。
    我们的AnyData客户端本身就是一个宿主程序,可以允许.NET脚本在其中运行,也提供了编辑脚本的功能。不过,目前这个功能没有得到足够的重视,而且使用起来比较的不方便。我们只是在程序中有一个脚本编辑器,可以编辑系统的所有可能的事件,但是这种脚本编辑器给人的印象不是很深刻,或许我应该重新给它起个名字,例如叫“系统事件管理器”,通过AnyData处理用户的业务规则,有两个非常重要的功能,一个是流程命令,一个是系统事件。
    另外,流程和系统事件都应该可以在流程设计器中进行编辑。并且将用户自定义对话框(只能在AnyData宿主程序中被创建和编辑)可以作为流程命令被调用。

你可能感兴趣的:(编程,脚本,服务器,测试,敏捷,SOA)