CN102082772A - 资源信息访问的实现方法和系统 - Google Patents

Abstract

一种资源信息访问的实现方法和系统，该系统包括资源系统和流程系统，流程系统用于向用户提供资源访问的界面，并根据用户对界面的操作访问资源系统中存储的资源信息；资源系统与流程系统之间设置有消息控制接口和内容服务接口，消息控制接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程系统之间的控制类消息，内容服务接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程系统之间的服务数据。本发明能够解决人工驱动带来的数据管理过程和数据质量不可控的问题，降低管理成本和人力成本，提高资源管理效率；并且能够避免流程分级分割带来的复杂的处理机制，解决处理跨系统的流程转接和数据交换问题，简化了接口设计。

Description

资源信息访问的实现方法和系统

技术领域

本发明涉及通信领域，尤其涉及一种资源信息访问的实现方法和系统。

背景技术

资源管理是通信网络运营支撑的重要环节。通常，企业运营都需要建立统一的全局资源管理系统平台，以便时刻掌握企业资源整体状况、运营能力，并借助资源管理系统的服务来达成企业资源调配、更迭和运作的科学、高效、节约和协同。因此，从企业运营服务的质量和效率来看，资源管理系统平台是至关重要的一个系统。

资源管理平台只是一个IT系统，该系统管理的资源数据信息是企业的重要资源。因此，资源管理平台的重要目标就是保证资源数据和信息的完整、准确、一致，并在需要调配和更迭资源的时候提供科学合理的方案。但这个目标仅仅靠资源管理平台这个IT系统是无法完成的。因为企业资源的变更与客户需求、外部要求、企业自身发展状况、新技术的引入、不同领域的资源生命周期的情况等等多种因素有关，有的变更是主动行为、有的则是被动行为；有的变更是全局性的，牵连的范围很广，有的则是局部的，不会带来扩散影响；有的变更是粗粒度的，有的则是细粒度的。虽然，资源变更的情况看起来很复杂、很主观和难以把握，但从根本上说，资源变更是与企业业务发展紧密相关的，而业务发展是由企业组织和人来决策和推进的，所以，要想把握资源变更的方式、跟踪资源变化的情况，最佳的方式就是跟随业务流程管理资源的变更问题。

对于如何通过跟踪业务流程来管理资源信息的变化，目前主要有两种解决方案：方式(1)在资源管理系统内对用户角色和权限进行分割，明确不同用户的职责和分工，之后再通过管理手段和制度建设，强制推行同一个系统内的分工与合作，从而达到资源数据和信息的变更在约定前提下进行协同，而这些约定前提是遵循业务流程要求的，是由组织行为和人为来决策和制定的；方式(2)，该方式主要存在于业务流程自动化程度较高的企业，通过(或部分通过)电子流程系统来驱动资源系统中数据和信息的变化，对于企业信息化来说，业务流程系统通常也是统一的全局平台，该系统承载着企业内部的业务逻辑和协作机制，这样的全局平台不仅要处理资源相关流程，还要处理企业内其他的流程，所以流程系统是按照业务流程维度构建的，它不应该也不可能与企业的资源管理平台集成在一起，所以，在采用这种方式时就会涉及到流程系统和资源系统之间的接口互动方式。

如上，在上述方式(2)中，需要开发资源系统与流程系统间的接口，这样才能达到流程驱动资源管理的自动化，进而保证资源数据准确、及时更新。目前，资源系统和流程系统间接口的实现方式有如下两种。

第一中实现方式通常是在流程系统中携带部分资源信息流转，而这些资源信息采用文件附件(如Excel文件附件)作为载体，流程本身的交互仍然沿用流程系统固有的技术实现方式，文件附件一般采用类似文件传输协议(如FTP)的方式交互。在流程流转的过程中，每一环节的用户按照规范的文件模板填写和更新数据，完成数据维护工作，流程结束后，再通过系统间接口，由流程系统转发给资源系统处理文件数据，如此完成流程驱动的资源变化。

第二种实现方式是根据业务关系将流程分级，分别在流程系统和资源系统实现，不同层级流程之间是嵌套和调用/返回关系。具体来讲，大的全局的流程在统一流程系统实现(如系统跨部门的资源调度流程)，局部的业务规则明确并易于自动化的流程在资源管理系统实现(如一个具体领域内部的资源方案设计、配置等)，不同层级流程之间建立接口，这种接口要实现流程逻辑的控制，还要交互数据，并处理数据的同步和变更跟踪。一个典型的例子是资源内部流程处理完成后，将资源的变化实时记录，生成静态的资源调度结果表单反馈给流程系统，由流程系统继续流转。

但是，以上描述的方案存在多种问题，具体如下：

上述的方式(1)本质上是通过限制人的行为来保证资源数据的准确、一致和完整，因为在系统实现层面角色和权限的灵活性有限，更多要靠管理手段来保证。对于该方式，流程中的抉择和推进由人来执行，所以这种流程驱动也可以说是人和制度在驱动。当资源结构复杂、资源数据庞大的情况下，不仅管理费时费力，而且因为人的主观性、理解力和判断均无法统一，会导致资源数据管理过程不可控、数据质量不可控，使得整个资源系统及其数据失去价值。

对于上述方式(2)，第一种接口实现方法由于文件附件的引入带来了如下问题：首先，是文件中的数据失控。文件本身不具备业务规则判断能力，数据在文件中也无法与资源系统中的数据进行比对和同步，数据在文件中的变更无法控制和跟踪，数据值的错误在所难免。其次，文件的格式需要统一约定，对于庞杂结构化的资源数据来说，这种格式统一本身就是一个工作量大且重复性强的工作，而且对于不同格式的文件难以达成一致。此外，这种接口方式还不可避免的涉及到附件文件的合并和拆分问题，因为资源信息的维护和变更往往是分布式的。此外，文件附件的校验机制、保存机制、因文件数据本身的规范性问题引发的流程回退和反复等，都将带来一系列的实现复杂性。

对于上述方法(2)，第二种接口实现方式的主要问题是复杂度高，实现代价大。首先，流程分级实现后，存在于不同的系统中，实际操作中很难定义出流程间的契合点，接口繁多复杂，诸如资源数据接口、流程控制接口、资源调度配置结果接口等。其次，流程系统需要保存部分资源系统所管理的资源数据，以支撑整个流程的运转，因此需要解决资源同步问题，包括同步机制、同步时机的选择等，这都会增加接口实现的复杂度。最后，这种实现方式的结果，用户可能需要做多次切换，感知不好。

针对相关技术中资源访问复杂度高、效率低的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中资源访问复杂度高、效率低的问题，本发明提出一种资源信息访问的实现方法和系统，能够降低资源访问和管理的复杂度，提高资源访问的效率。

本发明的技术方案是这样实现的：

根据本发明的一个方面，提供了一种资源信息访问的实现系统，该系统包括资源系统和流程系统，其中，流程系统用于向用户提供资源访问的界面，并根据用户对界面的操作访问资源系统中存储的资源信息；并且，资源系统与流程系统之间设置有消息控制接口和内容服务接口，消息控制接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程系统之间的控制类消息，内容服务接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程系统之间的服务数据。

并且，资源系统进一步用于响应于流程系统的访问对资源信息进行修改和/或呈现。

此外，流程系统进一步用于记录用户对界面进行的操作。

优选地，消息控制接口通过基于HTTP协议类的消息接口、基于服务调用的接口、基于组件调用的接口、或者基于TCP/IP协议栈和API开发的接口方式承载控制类消息。

进一步地，内容服务接口通过基于界面集成方式、基于文件共享的方式、基于消息中间件的方式、基于过程调用和共享数据的方式、或者基于数据库接口的方式承载服务数据。

其中，优选地，界面集成方式为基于HTTP/HTTPS的URL调用。优选地，基于HTTP协议类的消息接口为WebService方式实现的接口。

此外，上述控制类消息可以包括鉴权信息、流转请求控制信息、流程环节通知信息、和/或资源服务状态查询信息。

根据本发明的另一方面，提供了一种资源信息访问的实现方法。

根据本发明的资源信息访问的实现方法包括：

流程系统通过其提供的界面接收用户的操作；

流程系统根据用户的操作访问资源系统中存储的资源信息；其中，资源系统与流程系统之间设置有消息控制接口和内容服务接口，在流程系统访问资源系统的资源信息时，通过消息控制接口传送资源系统与流程系统之间的控制类消息，通过内容服务传送资源系统与流程系统之间的服务数据。

该方法可进一步包括：资源系统根据流程系统的访问对资源信息进行修改和/或呈现。

并且，该方法还可进一步包括：流程系统将用户通过界面预先输入的鉴权信息经由消息控制接口发送至资源系统；在资源系统对用户鉴权成功的情况下，允许用户根据预设的工作流任务访问资源信息。

并且，在用户完成服务数据的一个处理逻辑后，如果工作流任务需要进入下一个服务数据的处理逻辑，则该方法进一步包括：

流程系统通过消息控制接口向资源系统请求流转，并通过消息控制接口将工作流任务的当前流程状态通知给资源系统；

资源系统完成业务和数据的状态更新和同步。

此外，在用户受理完服务数据后，如果工作流任务需要下一个用户继续进行资源数据受理，该可方法进一步包括：流程系统通过消息控制接口将下一个用户的鉴权信息发送给资源系统，由资源系统对下一个用户进行鉴权，并在下一个用户通过鉴权的情况下，根据工作流任务的当前流程状态，通过内容服务接口向流程系统提供服务数据，以供下一个用户受理。

优选地，消息控制接口通过基于HTTP协议类的消息接口、基于服务调用的接口、基于组件调用的接口、或者基于TCP/IP协议栈和API开发的接口方式承载控制类消息。

优选地，内容服务接口通过基于界面集成方式、基于文件共享的方式、基于消息中间件的方式、基于过程调用和共享数据的方式、或者基于数据库接口的方式承载服务数据。

本发明通过在资源系统和流程系统之间采用数据和流程相互独立的松耦合接口设计，将流程控制和业务操作进行了明确分割，并且在流程系统上提供用于对资源系统中的资源数据进行直接访问的操作界面，一方面能够解决人工驱动带来的数据管理过程和数据质量不可控的问题，降低了管理成本和人力成本，提高了资源管理的效率，另一方面能够避免流程分级分割带来的复杂的处理机制，无需处理跨系统的流程转接和数据交换问题，简化了接口设计；此外，还能够省去复杂的数据导出、导入、拷贝、以及数据同步，降低处理的复杂度，提高处理的效率，并且有助于对数据修改状况以及用户操作状况进行监控和管理。

附图说明

图1是根据本发明系统实施例的资源信息访问的实现系统的框图；

图2是根据本发明方法实施例的资源信息访问的实现方法的流程图；

图3是根据本发明方法实施例的资源信息访问的实现方法的具体处理实例的消息流程图。

具体实施方式

针对相关技术中资源访问和管理复杂度高、效率低的问题，本发明提出：资源系统与流程系统的接口设计采用了数据和流程相互独立的松耦合结构。在这种结构中，流程系统仅负责流程控制，对资源数据的操作信息进行透明化处理；资源系统则仅负责自身业务数据的处理需求和业务逻辑规则的控制。通过本发明，能够在资源服务中解决资源权限控制、资源维护实时性、流程流转控制、工作流状态同步、资源业务规则核查控制等关键问题，流程驱动的机制通过来自流程系统的工作流状态同步来完成，从而能够有效解决工作流和业务流多级耦合的问题，并避免了系统间数据同步带来的复杂度。

下面将详细描述本发明的实施例。

系统实施例

在本实施例中，提供了一种资源信息访问的实现系统。

如图1所示，根据本实施例的资源信息访问的实现系统包括资源系统和流程系统(也可称为流程引擎平台或流程引擎)，其中，资源系统包括多个资源服务实例，用于提供资源服务。

参照图1，流程系统用于向用户提供资源访问的界面，并根据用户对界面的操作访问资源系统中存储的资源信息；并且，资源系统与流程系统之间设置有消息控制接口和内容服务接口，消息控制接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程系统之间的控制类消息，即，形成图1中所示的通道一，通过该通道可以实现访问控制和流程同步，内容服务接口用于在流程系统访问资源系统的资源信息时传送资源系统与流程系统之间的服务数据，形成图1中所示的通道二，通过该通道实现资源业务的访问。

并且，资源系统可以进一步用于响应于流程系统的访问对资源信息进行修改和/或呈现。流程系统可以进一步用于记录用户对界面进行的操作。

相比于上述的方式(1)，根据本发明的资源信息的访问系统在进行资源访问时，访问流程由流程系统驱动，从而增强流程的可控性以及避免由于认为操作带来的庞大工作量。

在上述方式(2)的第一中接口实现方法中，在对资源系统中的资源信息进行访问时，需要导出数据，并且导出的数据需要拷贝到流程系统，之后由人工修改流程系统中的数据，在该方法中，由于人工修改是认为操作，并非基于一定的规则，从而会导致文件内数据的修改状况无法控制和管理，一旦修改出现不合法的情况，就会导致流程回转，并且，用户的修改访问均基于拷贝到流程系统中的数据，但是资源系统中的数据并未发生变化，因此，在用户完成访问之后还需要进行复杂的变更同步过程，该过程同样需要将数据导出导入。

根据本发明的上述系统在进行资源访问时，用户可以通过界面实现访问，在资源系统直接修改数据，省去了数据的拷贝、导出、导入资源系统中的同步数据，并且，基于界面操作的方式，能够在界面上实现数据修改等操作的标准化，避免流程回转的问题。

在上述方式(2)的第二中接口实现方法中，流程系统和资源系统双方均控制流程，流程的衔接需要在两个系统中均进行流程的接口，流程需要对接，并且需要交互流程之间的处理中间结果，因此，对于资源的管理，需要获取资源系统和流程系统两者的处理结果，才能够最终获知用户的访问操作状况，不利于对流程的监控和追踪，也不利于对每个用户的操作进行管理，并且，在流程对接时需要实现复杂、繁多的流程接口，导致整个系统的复杂度增加。

根据本发明的上述系统在进行资源访问时，在流程系统中即可实现流程的监控、跟踪、任务过程的记录(审计)等，数据的变化在资源系统中能够明确第体现出来，因此，不需要结合两个系统的综合结果，有效提高了用户管理和资源数据管理的效率。

在根据本发明的上述系统中，优选地，消息控制接口可以通过基于HTTP协议类的消息接口(如WebService、HTTP/HTTPS(超文本传输协议/超文本传输协议安全版)等)、基于服务和组件调用的接口(如J2EE/EJB/RMI/JCA等)、基于其他组件技术标准和架构的接口(如CORBA、TUXEDO等)、基于TCP/IP协议栈和API开发的接口(如SOCKET方式、私有API接口开发等)等方式承载控制类消息。

优选地，内容服务接口可以通过基于界面集成方式、基于文件共享的方式(如FTP)、基于消息中间件的方式、基于过程调用和共享数据的方式、基于数据库接口的方式等承载服务数据。其中，界面集成方式基于HTTP/HTTPS的URL调用方式实现，这种方式便于实现，并能够有效降低业务数据同步和流程衔接的复杂度。

此外，上述控制类消息可以包括鉴权信息、流转请求控制信息、流程环节通知信息、和/或资源服务状态查询信息等，本文不再一一列举。

优选地，考虑到技术标准化、可扩展性和实现简单性，可以将内容服务接口承载在HTTP/HTTPS协议上。另外，考虑到协议标准化、技术发展趋势和可扩展性，推荐用WebService协议承载消息控制接口，使得系统的应用具有更好的推广性，具有良好的标准化性和可扩展性，实现代价较低。

在采用了WebService和HTTP/HTTPS协议后，不需开发类似FTP(例如文件附件)、HTML(例如资源调度结果表单)等的交互方式，因此简洁实用，便于资源服务组件的开发和加载(并且可以plug-in的方式加载新资源服务)，接口维护也很简单。

此时，在进行接口消息交互时，涉及到资源相关的任务处理的消息通过HTTP/HTTPS方式传输，涉及到流程确认、用户身份认证、鉴权等控制类消息则通过WebService方式传输。在具体实现上，资源系统开发出基于各业务领域的资源服务，用户在流程系统的带动下，经过了认证和授权，就可以通过HTTP/HTTPS接口访问资源系统提供的资源服务。

可以看出，本发明的方案中接口实现简洁，通过设计两个相对独立的消息通道，从设计上进行了流程和数据的分割，在抽象的资源服务的概念下，通过两个标准协议对这两个接口进行承载，能够使这种分割获得实现层面的简单和标准化。

实际应用中，在资源系统提供资源服务时，一个原子级的资源服务对外的接口包含控制请求和业务请求两部分接口消息。其中，控制请求消息包括资源权限校验、流转请求控制、流程流转环节告知、资源服务状态查询等信息。这部分消息只负责两个系统间的控制交互，并不涉及资源数据信息。

业务请求消息也可称为资源服务请求消息，用户在流程系统中可以根据流程状态适时发起资源服务请求消息，调用资源服务的业务界面(资源服务的业务界面由资源系统实现)，这样实现了资源系统与流程系统的松耦合。流程系统不需要再另行维护一套资源数据，同时也不必关心资源服务的业务内容，只需要知道哪个环节调用哪个资源服务接口即可。

在资源系统中，资源服务的结构可以是多层封装结构。首先，需要根据业务域的资源需求分析结果，抽象出基本层次的资源服务，称为原子级的资源服务。由原子级的资源服务可以组合成更高级的资源服务。多个资源服务可以纵向级联，从而构成复杂的资源服务或是完成一个资源需求实现过程逻辑。

资源系统中的资源服务实例构成了一个面向具体资源需求的业务逻辑的模块，其外在表现就是提供了一系列的资源服务界面，并符合该资源业务流程的要求。资源服务实例只负责资源的业务操作，如资源数据的查询、呈现、基于本资源服务业务逻辑的控制校验等等。优选地，如上，资源系统提供的接口可以为内容服务接口，并通过HTTP/HTTPS承载。

通过上述系统，基于业务和流程分离的接口配置方案，能够降低资源访问的复杂度，提高管理的效率，有效解决工作流和业务流多级耦合的问题。

方法实施例

在本实施例中，提供了一种资源信息访问的实现方法。该方法可以基于上述系统实现资源信息的访问。

类似地，下文中提到的消息控制接口可以通过基于HTTP协议类的消息接口(如WebService、HTTP/HTTPS等)、基于服务和组件调用的接口(如J2EE/EJB/RMI/JCA等)、基于其他组件技术标准和架构的接口(如CORBA、TUXEDO等)、基于TCP/IP协议栈和API开发的接口(如SOCKET方式、私有API接口开发等)等方式承载控制类消息。内容服务接口可以通过基于界面集成方式、基于文件共享的方式(如FTP)、基于消息中间件的方式、基于过程调用和共享数据的方式、基于数据库接口的方式等承载服务数据。

如图2所示，根据本实施例的资源信息访问的实现方法包括：

步骤S202，流程系统通过其提供的界面接收用户的操作；

步骤S204，流程系统根据用户的操作访问资源系统中存储的资源信息；其中，资源系统与流程系统之间设置有消息控制接口和内容服务接口，在流程系统访问资源系统的资源信息时，通过消息控制接口传送资源系统与流程系统之间的控制类消息，通过内容服务传送资源系统与流程系统之间的服务数据。

在用户进行访问之前，流程系统需要将用户通过界面预先输入的鉴权信息经由消息控制接口发送至资源系统；在资源系统对用户鉴权成功的情况下，允许用户根据预设的工作流任务访问资源信息。

在用户访问的过程中或访问结束之后，资源系统可以根据流程系统的访问对资源信息进行修改和/或呈现。

在用户完成对服务数据的一个处理逻辑后，如果工作流任务需要进入下一个资源数据的处理逻辑，则该方法进一步包括：流程系统通过消息控制接口向资源系统请求流转，并通过消息控制接口将工作流任务的当前流程状态通知给资源系统，以便资源系统完成业务和数据的状态更新和同步。

在用户受理完服务数据后，如果工作流任务需要下一个用户继续进行资源数据受理，则该方法进一步包括：流程系统通过消息控制接口将下一个用户的鉴权信息发送给资源系统，由资源系统对下一个用户进行鉴权，并在下一个用户通过鉴权的情况下，根据工作流任务的当前流程状态，通过内容服务接口向流程系统提供资源数据，以供下一个用户受理。

也就是说，对于每个执行工作流任务的用户，均需要通过消息控制接口完成鉴权后才能访问资源系统，并执行各自的任务。

下面将结合图3详细描述用户通过流程系统访问资源系统的一个资源服务实例的处理过程。

如图3所示，具体包括以下步骤：

步骤1，用户通过流程系统创建工作流任务。

步骤2，流程系统根据任务类型判断所需资源服务类型，通过资源系统提供的认证和鉴权服务对用户进行认证和授权，认证和鉴权可通过消息控制接口实现。

步骤3，认证和授权完成后，流程系统调用资源系统提供的该任务相应的资源服务。其中，资源系统可以反馈相应的服务调用界面以供执行具体的操作。该调用可以通过内容服务接口实现，具体可以基于HTTP/HTTPS方式集成资源系统提供的资源服务业务界面，在流程系统内进行资源服务访问。

步骤4，在流程系统中，用户通过资源系统提供的资源服务操作界面，遵照相应的资源业务规则和业务流逻辑(内置于资源服务当中)，对资源数据进行增加、删除、修改、查询等操作，完成对资源的访问。

其中，图3中最上方的4个步骤(步骤1至4)即相当于流程创建环节。

步骤5，用户完成当前阶段操作，触发流程系统向前流转。

步骤6，流程系统调用资源系统提供的资源服务，以确认资源配置合法性和可行性。这其中涉及到资源数据的比对、业务规则的校验、关联资源的影响性和可用性等等，比如资源配置是否已完成，是否可进行下一步操作。这些是基于资源全局的一种确认，需要资源系统结合自身数据从全局角度进行分析和判断，因此只有资源系统才能很好的完成。

然后，资源服务反馈流程系统发起的查询、请求等操作的结果。

步骤6中的交互可以通过消息控制接口实现。

步骤7，根据资源系统接口服务反馈的结果，流程系统启动相应的规则和动作，并通知用户。

步骤8，流程系统调用资源系统的资源服务接口，通知资源系统当前工作流状态，以便资源系统结合内置的业务逻辑和资源变化关系，由工作流状态判断资源信息生命周期阶段，以完成资源数据的状态同步和管理。步骤8中的消息传输可以通过消息控制接口实现。

步骤9，经过流程系统中若干环节的流转，业务流的下一个用户开始受理，执行相应的任务。

步骤10，流程系统根据业务流的定义和要求，判断用户是否需要操作资源，如果需要，同样需要启动认证和鉴权过程(如前所述)。实际上，是通过同一资源服务接口的不同参数来认证和鉴权，以决定是否可访问服务，是只读访问还是可写的访问资源服务等。

步骤11，本环节的用户受理业务完毕，完成本阶段任务，触发流程流转到下一环节。

步骤12，经过流程系统中若干环节的流转，审核决策角色的用户查看本次资源服务流程的结果。同样需要先启动认证和鉴权过程(如前所述)，再启动资源系统的服务调用接口以进行审查。

步骤13，最终用户确认资源变更的结果后，触发流程系统结束工作流，完成工作流的闭环。

步骤14，流程系统触发工作流状态的传递，通知资源系统本次资源变更业务流完成。资源系统同步工作流状态，完成业务逻辑和资源数据生命周期阶段的确认，资源变化最终的更新完成。同样，这个消息的传递通过资源服务提供的消息控制接口实现。

其中，对于中间进行工作流任务的每个用户，资源系统、流程系统、以及用户之间的交互流程均可以按照步骤9、步骤2、步骤3、步骤10、步骤11、步骤6、步骤7、步骤8的顺序执行，可以将这些处理称为受理环节。

应当注意，尽管图3中示出了具体的处理顺序和处理步骤，但是本发明并不限于此，在实际应用中，可以增加、删除、改变图3中的处理，或调整处理步骤的顺序。

并且，尽管之前列举了用于承载控制类消息和服务数据的多种协议，但是本发明并不限于此，凡是能够承载控制信息的协议均可以作为消息控制接口所采用的协议，凡是能够承载业务数据的协议，均可以作为内容服务接口的协议，本文不再一一列举。

综上所述，相比于上述方式(1)，本发明能够通过电子化的流程系统来自动驱动资源数据的变更，解决了人工驱动带来的数据管理过程和数据质量不可控的问题，并简化了管理成本和人力成本，提高了资源管理的效率；相比于上述方式(2)中的第一种接口实现方式，本发明无需文件附件传递资源数据信息，解决了附件文件中数据不可控问题，强化了面向业务规则的检查机制，规避了文件附件方式引发的一系列复杂处理机制，从流程驱动资源变化的实际粒度和效果上都有了明显的提升，并且，能够省去数据的导出、导入、拷贝、以及资源数据的同步，有效提高了处理的效率，降低了资源访问实现的复杂度；相比于上述方式(2)中的第二种接口实现方式，本发明将流程控制和业务操作进行了明确分割，避免了流程分级分割带来的复杂的处理机制，无需处理跨系统的流程转接和数据交换问题，简化了接口设计，有效实现了流程中的权限传递、数据同步。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (15)

1.一种资源信息访问的实现系统，其特征在于，包括资源系统和流程系统，其中，

所述流程系统用于向用户提供资源访问的界面，并根据所述用户对所述界面的操作访问所述资源系统中存储的资源信息；并且，所述资源系统与所述流程系统之间设置有消息控制接口和内容服务接口，所述消息控制接口用于在所述流程系统访问所述资源系统的所述资源信息时传送所述资源系统与所述流程系统之间的控制类消息，所述内容服务接口用于在所述流程系统访问所述资源系统的所述资源信息时传送所述资源系统与所述流程系统之间的服务数据。

2.根据权利要求1所述的系统，其特征在于，所述资源系统进一步用于响应于所述流程系统的访问对所述资源信息进行修改和/或呈现。

3.根据权利要求1所述的系统，其特征在于，所述流程系统进一步用于记录所述用户对所述界面进行的操作。

4.根据权利要求1至3中任一项所述的系统，其特征在于，所述消息控制接口通过基于HTTP协议类的消息接口、基于服务调用的接口、基于组件调用的接口、或者基于TCP/IP协议栈和API开发的接口方式承载所述控制类消息。

5.根据权利要求1至3中任一项所述的系统，其特征在于，所述内容服务接口通过基于界面集成方式、基于文件共享的方式、基于消息中间件的方式、基于过程调用和共享数据的方式、或者基于数据库接口的方式承载所述服务数据。

6.根据权利要求5所述的系统，其特征在于，所述界面集成方式为基于HTTP/HTTPS的URL调用。

7.根据权利要求1至3中任一项所述的系统，其特征在于，所述基于HTTP协议类的消息接口为WebService方式实现的接口。

8.根据权利要求1至3中任一项所述的系统，其特征在于，所述控制类消息包括鉴权信息、流转请求控制信息、流程环节通知信息、和/或资源服务状态查询信息。

9.一种资源信息访问的实现方法，其特征在于，所述方法包括：

所述流程系统通过其提供的界面接收用户的操作；

所述流程系统根据所述用户的所述操作访问资源系统中存储的资源信息；其中，所述资源系统与所述流程系统之间设置有消息控制接口和内容服务接口，在所述流程系统访问所述资源系统的所述资源信息时，通过所述消息控制接口传送所述资源系统与所述流程系统之间的控制类消息，通过所述内容服务传送所述资源系统与所述流程系统之间的服务数据。

10.根据权利要求9所述的方法，其特征在于，进一步包括：

所述资源系统根据所述流程系统的访问对所述资源信息进行修改和/或呈现。

11.根据权利要求9所述的方法，其特征在于，进一步包括：

所述流程系统将所述用户通过所述界面预先输入的鉴权信息经由所述消息控制接口发送至所述资源系统；

在所述资源系统对所述用户鉴权成功的情况下，允许所述用户根据预设的工作流任务访问所述资源信息。

12.根据权利要求11所述的方法，其特征在于，在所述用户完成所述服务数据的一个处理逻辑后，如果所述工作流任务需要进入下一个服务数据的处理逻辑，则所述方法进一步包括：

所述流程系统通过所述消息控制接口向所述资源系统请求流转，并通过所述消息控制接口将所述工作流任务的当前流程状态通知给所述资源系统；

所述资源系统完成业务和数据的状态更新和同步。

13.根据权利要求11所述的方法，其特征在于，在所述用户受理完所述服务数据后，如果所述工作流任务需要下一个用户继续进行资源数据受理，所述方法进一步包括：

所述流程系统通过所述消息控制接口将所述下一个用户的鉴权信息发送给所述资源系统，由所述资源系统对所述下一个用户进行鉴权，并在所述下一个用户通过鉴权的情况下，根据所述工作流任务的当前流程状态，通过所述内容服务接口向所述流程系统提供服务数据，以供所述下一个用户受理。

14.根据权利要求9至13中任一项所述的方法，其特征在于，所述消息控制接口通过基于HTTP协议类的消息接口、基于服务调用的接口、基于组件调用的接口、或者基于TCP/IP协议栈和API开发的接口方式承载所述控制类消息。

15.根据权利要求9至13中任一项所述的方法，其特征在于，所述内容服务接口通过基于界面集成方式、基于文件共享的方式、基于消息中间件的方式、基于过程调用和共享数据的方式、或者基于数据库接口的方式承载所述服务数据。

Images