本发明属于软件信息化领域，具体涉及一种通过流程引擎配置快速开发新业务软件程序的方法。
背景技术：
目前所有的医疗信息化管理软件都是使用直接编码的形式来确定任务流转和数据流转，虽然可以满足医疗机构的信息化管理需求，但是在实际应用过程中，对于医疗机构的信息化管理经常出现业务变动或调整的情况，如此需要对任务流转和数据流转进行相应的修改，存在软件程序修改难度大、方式复杂和开发周期长的问题，急需提供一种针对业务发生变动或调整的情况，能够快速开发新业务软件程序的方法。
技术实现要素：
为了解决现有技术存在的上述问题，本发明目的在于提供一种通过流程引擎配置快速开发新业务软件程序的方法。
本发明所采用的技术方案为：
一种通过流程引擎配置快速开发新业务型软件程序的方法，包括如下步骤：
s101.针对原业务型软件程序，创建一个流程引擎配置文件，其中，所述流程引擎配置文件包含有在原业务型软件程序中所有流程引擎的属性信息；
s102.根据业务变动或调整需要，在所述流程引擎配置文件中，对相应流程引擎的属性信息进行修改；
s103.将修改后的流程引擎配置文件加载到原业务型软件程序中；
s104.根据流程引擎配置文件中流程引擎的属性信息逐一地更新原业务型软件程序中相应流程引擎的属性信息，得到新业务型软件程序。
优化的，在所述步骤s101之前，还包括如下步骤：
s100.将原业务型软件程序中所有与流程引擎对应的功能封装成一个公共函数。
优化的，在所述步骤s104中，按照如下步骤逐一地更新原业务型软件程序中相应流程引擎的属性信息：
s401.对比原业务型软件程序中与流程引擎配置文件中相同流程引擎的相同属性信息是否一致，若一致则不更新，否则将原业务型软件程序中流程引擎的属性信息替换为流程引擎配置文件中相应流程引擎的属性信息。
优化的，所述属性信息包含allowtaskreparenting属性、alwaysretaintaskstate属性、cleartaskonlaunch属性、multiprocess属性、name属性、nohistory属性、permission属性、process属性、statenotneeded属性和/或launchmode属性。
优化的，所述属性信息还包含screenorientation属性和launchmode属性。
优化的，所述原业务型软件程序和所述新业务型软件程序均为用于医疗信息化管理的安卓软件程序。
优化的，所述流程引擎配置文件为xml格式文件。
本发明的有益效果为：
(1)本发明创造提供了一种通过修改流程引擎配置文件来达成任务流转及数据流转修改的新方法，即先针对原业务型软件程序创建一个流程引擎配置文件，然后根据业务变动或调整需要，在该流程引擎配置文件中对相应流程引擎的属性进行修改，最后将修改后的流程引擎配置文件加载到原业务型软件程序中，通过流程引擎属性的更新，得到可以驱动新业务或实现新任务流转及数据流转的新业务型软件程序，从而可以大大降低新业务型软件程序的开发周期，灵活适应在诸如医疗信息化管理等中所出现的业务发生变动或调整的情况，便于实际推广和应用。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明提供的通过流程引擎配置快速开发新业务软件程序的方法流程示意图。
具体实施方式
下面结合附图及具体实施例对本发明作进一步阐述。在此需要说明的是，对于这些实施例方式的说明用于帮助理解本发明，但并不构成对本发明的限定。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，单独存在b，同时存在a和b三种情况，本文中术语“/和”是描述另一种关联对象关系，表示可以存在两种关系，例如，a/和b，可以表示：单独存在a，单独存在a和b两种情况，另外，本文中字符“/”，一般表示前后关联对象是一种“或”关系。
实施例一
如图1所示，本实施例提供的所述通过流程引擎配置快速开发新业务型软件程序的方法，包括如下步骤。
s101.针对原业务型软件程序，创建一个流程引擎配置文件，其中，所述流程引擎配置文件包含有在原业务型软件程序中所有流程引擎的属性信息。
在所述步骤s101中，所述原业务型软件程序用于实现在业务信息化管理中任务流转和数据流转的功能，其可以但不限于为用于医疗信息化管理的安卓软件程序。所述流程引擎也称为工作流引擎，是指作为应用系统的一部分，为之提供对各应用系统有决定作用的且根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案，其包括了任务流转或数据流转过程中的节点管理、流向管理、流程样例管理等重要功能。
在所述步骤s101之前，优化的，还包括如下步骤：s100.将原业务型软件程序中所有与流程引擎对应的功能封装成一个公共函数。由于所述原业务型软件程序可以包含几百个用于实现任务流转或数据流转功能的流程引擎，通过前述对所有功能进行封装，可以实现大量流程引擎的自由拼接，以便在更新流程引擎的属性后，可以构建起新的业务或新的任务流转及数据流转。所述流程引擎配置文件可以但不限于为xml格式文件，其优选在开发原业务型软件程序时一并创建，其中，所述属性信息可以但不限于包含allowtaskreparenting属性、alwaysretaintaskstate属性、cleartaskonlaunch属性、multiprocess属性、name属性、nohistory属性、permission属性、process属性、statenotneeded属性和/或launchmode属性等。
所述allowtaskreparenting属性为在现有流程引擎中的基本属性之一，用于设定流程引擎是否能够从启动它的任务中转移到另一个与启动它的任务有亲缘关系(流程引擎的亲缘关系是由taskaffinity属性定义的，可通过读取任务的根流程引擎的亲缘关系来判断任务的亲缘关系，因此通过定义，可识别任务中的根流程引擎与任务有着相同的亲缘关系：带有singletask或singleinstance启动模式的流程引擎只能是任务的根节点，流程引擎的任务归属受限于standard和singletop模式)的任务中，转移时机是在这个有亲缘关系的任务被带到前台的时候，如果设置为“true”，则能够转移，如果设置为“false”，则这个流程引擎必须要保留在启动它的那个任务中，而如果这个属性没有设置，那么其对应的<application>元素(用于声明流程的开始)的allowtaskreparenting属性值就会应用到这个流程引擎上，它的默认值是“false”。通常，当流程引擎被启动时，它会跟启动它的任务关联，并在它的整个生命周期都会保持在那个任务中。但是当流程引擎的当前任务不再显示时，可以使用这个属性来强制流程引擎转移到与当前任务有亲缘关系的任务中。这种情况的典型应用就是把应用程序的流程引擎转移到与这个应用程序相关联的主任务中。例如，如果一个电子邮件消息中包含了一个网页的链接，点击这个链接会启动一个显示这个网页的流程引擎。但是，由e-mail任务部分启动的这个流程引擎是由浏览器应用程序定义的。如果把它放到浏览器的任务中，那么在浏览器下次启动到前台时，这个网页会被显示，并且在e-mail任务再次显示时，这个流程引擎有会消失。
所述alwaysretaintaskstate属性为在现有流程引擎中的基本属性之一，用于设置流程引擎所属的任务状态是否始终由系统来维护，如果设置为“true”，则由系统来维护状态，若设置为“false”，那么在某些情况下，系统会允许重设任务的初始状态，其默认值是“false”。这个属性只对任务根节点的流程引擎有意义，其他所有的流程引擎都会被忽略。通常，在某些情况中，当用户从主屏中重新启动一个任务时，系统会先清除任务(即从堆栈中删除根节点流程引擎之上的所有流程引擎)。但是，当这个属性被设置为“true”时，用户会始终返回到这个任务的最后状态，而不管中间经历了哪些操作。例如，web浏览器的应用就会保留很多用户不想丢失的状态，如多个被打开的标签页。
所述cleartaskonlaunch属性为在现有流程引擎中的基本属性之一，用于设定在从主屏中重启任务时，处理根节点的流程引擎以外，任务中的其他所有的流程引擎是否要被删除，如果设置为“true”，那么任务根节点的流程引擎之上的所有流程引擎都要被清除，如果设置为“false”，就不会被清除，其默认设置为“false”。这个属性只对启动新任务(或根流程引擎)的那些流程引擎有意义，任务中其他所有的流程引擎都会被忽略。当这个属性被设置为“true”且用户再次启动任务时，任务根节点的流程引擎就会被显示，而不管在任务的最后做了什么，也不管任务是使用back按钮还是使用home离开的。当这个属性被设置为“false”时，在某些情况中这个任务的流程引擎可以被清除，但不总是这样的。例如，假设某人从主屏中启动了流程引擎p，并且又从流程引擎p中启动了流程引擎q。接下来用户按下了home按钮，然后又返回到流程引擎p。通常用户会看到流程引擎q，因为这是在流程引擎p的任务中所做的最后的事情。但是，如果流程引擎p的这个属性设置为“true”，那么在用户按下home按钮使任务被挂起时，流程引擎p之上的所有流程引擎(包括本例中流程引擎q)都会被删除。因此当用户再次返回到本任务时，用户只能看到流程引擎p。此外，如果这个属性和allowtaskreparenting属性都被设置为“true”，那些被设置了亲缘关系的流程引擎会被转移到它们共享的亲缘任务中，然后把剩下的流程引擎都给删除。
所述multiprocess属性为在现有流程引擎中的基本属性之一，用于设置流程引擎的实例能否被加载到与启动它的那个组件所在的进程中，如果设置为“true”，则可以，否则不可以，其默认值是“false”。通常，一个新的流程引擎实例会被加载到定义它的应用程序的进程中，以便应用程序的所有流程引擎都运行在同一个进程中。但是，如果这个属性被设置为“true”，那么这个流程引擎的实例就可以运行在多个进程中，允许系统在使用它们的进程中来创建实例(权限许可的情况下)，这几乎是从来都不需要的事情。
所述name属性为在现有流程引擎中的基本属性之一，用于设置流程引擎的实现类(流程引擎的子类)的名字。这个属性值应该是完整的java类名，如：com.example.project.extracurricular流程引擎。但是也可以用简写的方式，名字第一个字符用“.”符号，如：.extracurricular流程引擎。它对应的包名是在<manifest>元素中指定的。一旦发布了应用程序，就不应该改变这个名称(除非设置了exported＝”false”)。此外，这个属性没有默认值，名称必须被指定。
所述nohistory属性为在现有流程引擎中的基本属性之一，用于设置当用户离开该流程引擎，并且它在屏幕上不再可见的时候，它是否应该从流程引擎的堆栈被删除，如果设置为“true”，则要删除，否则不删除，其默认值是“false”。如果设置为“true”，则意味着流程引擎不会保留历史轨迹。也就是说，它不会保留在任务的流程引擎堆栈中，因此用户不能够在返回到这个流程引擎。
所述permission属性为在现有流程引擎中的基本属性之一，用于设定启动流程引擎的客户端或者是响应一个intent对象的请求所必须要有的权限。如果start流程引擎()方法或start流程引擎forresult()方法的调用者没有被授予指定的权限，那么它的intent对象就不会发送给对应的流程引擎。如果这个属性没有设置，那么<application>元素中的permission属性的设置就应用到流程引擎元素上。如果<application>元素也没有设置，那么这个流程引擎就不会受到权限的保护。
所述process属性为在现有流程引擎中的基本属性之一，用于设置流程引擎应该运行的那个进程的名字。通常，应用程序的所有组件都运行在为这个程序所创建的一个默认的进程中。它跟应用程序的包有相同的名字。<application>元素的process属性能够给所有的组件设置一个不同的默认值。但是每个组件都能够覆盖这个默认设置，允许把应用程序分离到多个进程中。如果这个属性名的值是用“:”开始，那么在需要的时候，就会创建一个应用程序私有的新的进程，这个流程引擎就会运行在这个进程中。如果进程名使用小写字母开头，那么在权限许可的情况下，该流程引擎会运行在用它命名的全局进程中。这样就运行不同应用程序的组件能够共享一个进程，从而减少资源的使用。
所述statenotneeded属性为在现有流程引擎中的基本属性之一，用于设置在没有保存流程引擎状态的情况下，它能否被销毁且成功地重启，如果设置为“true”，则不引用流程引擎之前的状态就能够被重启，如果设置为“false”，重启流程引擎时，则需要它之前的状态，其默认值是“false”。通常，流程引擎在最终被关掉之前，会调用onsaveinstancestate()方法来保存资源。这个方法会用一个bundle对象来保存流程引擎的当前状态，然后在这个流程引擎被重启时，再把这个bundle对象传递给oncreate()方法。如果这个属性设置为“true”，onsaveinstancestate()方法就可以不被调用，并且调用oncreate()方法时，会用null来代替bundle对象，就像流程引擎被第一次重启一样。若设置为“true”，会确保流程引擎在缺省状态下能够被重启。例如，在主屏显示的流程引擎如果使用这个设置，即使由于某些原因导致流程引擎崩溃，也会确保它不会被删除。
此外，进一步优化的，为了拓展流程引擎的属性修改范围，所述属性信息还可以但不限于包含screenorientation属性和launchmode属性。其中，所述screenorientation属性为在现有流程引擎中的基本属性之一，用于设置流程引擎在设备上显示的方向，其属性值包括：“unspecified”，“user”，“behind”，“landscape”，“portrait”，“reverselandscape”，“reverseportrait”，“sensorlandscape”，“sensorportrait”，“sensor”，“fullsensor”和“nosensor”。所述launchmode属性也为在现有流程引擎中的基本属性之一，用于定义应该如何启动流程引擎的一个指令。有四种工作模式会跟intent对象中的流程引擎标记(flag_流程引擎_*常量)结合在一起用来决定被调用流程引擎在处理intent对象时应该发生的事情，这四种模式是：“standard”，“singletop”，“singletask”和“singleinstance”，默认的模式是“standard”。
s102.根据业务变动或调整需要，在所述流程引擎配置文件中，对相应流程引擎的属性信息进行修改。
s103.将修改后的流程引擎配置文件加载到原业务型软件程序中。
s104.根据流程引擎配置文件中流程引擎的属性信息逐一地更新原业务型软件程序中相应流程引擎的属性信息，得到新业务型软件程序。
在所述步骤s104中，优化的，按照如下步骤逐一地更新原业务型软件程序中相应流程引擎的属性信息：s401.对比原业务型软件程序中与流程引擎配置文件中相同流程引擎的相同属性信息是否一致，若一致则不更新，否则将原业务型软件程序中流程引擎的属性信息替换为流程引擎配置文件中相应流程引擎的属性信息。此外，当所述原业务型软件程序为用于医疗信息化管理的安卓软件程序时，所述新业务型软件程序也为用于医疗信息化管理的安卓软件程序，但可以适应在医疗信息化管理中所出现的业务发生变动或调整的情况。
如此根据前述步骤s101～s104，可通过修改流程引擎配置文件来达成任务流转及数据流转修改，得到可以驱动新业务或实现新任务流转及数据流转的新业务型软件程序，从而可以大大降低新业务型软件程序的开发周期，实现在中大型医疗系统中提高软件适应性，减少业务流程变动需求的修改时间等特性。
综上，采用本实施例所提供的通过流程引擎配置快速开发新业务型软件程序的方法，具有如下技术效果：
(1)本实施例提供了一种通过修改流程引擎配置文件来达成任务流转及数据流转修改的新方法，即先针对原业务型软件程序创建一个流程引擎配置文件，然后根据业务变动或调整需要，在该流程引擎配置文件中对相应流程引擎的属性进行修改，最后将修改后的流程引擎配置文件加载到原业务型软件程序中，通过流程引擎属性的更新，得到可以驱动新业务或实现新任务流转及数据流转的新业务型软件程序，从而可以大大降低新业务型软件程序的开发周期，灵活适应在诸如医疗信息化管理等中所出现的业务发生变动或调整的情况，便于实际推广和应用。
本发明不局限于上述可选的实施方式，任何人在本发明的启示下都可得出其他各种形式的产品。上述具体实施方式不应理解成对本发明的保护范围的限制，本发明的保护范围应当以权利要求书中界定的为准，并且说明书可以用于解释权利要求书。