关于业务和IT

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