CN103186661A

CN103186661A - 声明性视图对象

Info

Publication number: CN103186661A
Application number: CN2012105851773A
Authority: CN
Inventors: F.布伦斯威格; O.盖索; D.戈德曼; C.哈斯; T.约翰; S.施米特
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2011-12-28
Filing date: 2012-12-28
Publication date: 2013-07-03
Also published as: EP2610740A1; US20130173549A1; US9009110B2

Abstract

在目标部署单元中在元数据储存库的设计时间环境中生成视图对象。在源部署单元的业务对象上建模视图对象。源部署单元包括物理上从目标部署单元去耦合的业务应用的一组过程组件。选择源部署单元的业务对象的属性的子集。属性的子集至少包括由通用消息收发框架实施的出站代理和入站代理。利用业务对象的属性的子集在目标部署单元中建模视图对象。视图对象的入站代理被配置用于从业务对象的出站代理接收复制消息，并且复制消息包括用于仅以来自业务对象的数据配置视图对象的复制数据。

Description

声明性视图对象

技术领域

本公开总地涉及声明性视图对象，并且更具体地，涉及一种用于在元数据储存库中建模视图对象作为业务对象投影的系统和方法，在该系统和方法中业务对象节点的永久属性可以在投影中使用。

背景技术

为了运行和完善复杂的业务场景，通常需要访问来自位于不同部署单元（Deployment Unit，DU）中的业务对象（business object，BO）的信息。DU表示可以在与其它过程（process）组件相隔离的单独的系统上操作从而不同的部署单元可以在不同的物理系统上被实例化（instantiated）并且完全去耦合（decoupled）的一组过程组件。例如，存在一些简单的用例（use cases），其中要求参考另一个DU的BO以便实现搜索和验证（validation）。或者，在更加复杂的用例中，可能要求具有来自另一个DU的BO的信息，以便准备或运行后续的过程。而且，存在这样的用例，其中要求来自另一个DU的BO的信息，以便在“本地”BO的上下文中在用户界面（UI）上容易地示出数据。

示例：

1．搜索和验证：项目（project）被复制到时间和人工管理（TLM）以便创建用于时间记录的特定于雇员的工作列表。

2．准备后续过程：项目被复制到财务（FIN）以便实现项目成本计算并使得能够使用项目作为会计对象。

3．实现后续过程：与项目有关的时间确认、费用报告、商品和服务收据、以及供货商发票被复制到项目管理（PRO）并存储在项目费用视图中作为项目清单开具（invoicing）的基础。

4．在UI上显示数据：与项目有关的采购请求和订单被复制到PRO并存储在项目采购请求中以便在项目的上下文中可视化采购申请/订单。

今天，这些问题通常通过引入所谓的“视图对象”来解决。视图对象是另一个DU中“主（master）”BO的镜像对象（mirror object），“主”业务对象的数据通过视图对象被复制到要求该信息的DU；通常通过以来自接收DU的附加信息来充实（enriching）该视图对象。在一些实施方式中，数据复制使用过程代理框架来达成。

视图对象主要用于符合本地架构指南、健壮性（robustness）标准、以及快速数据访问（即，本地访问），还有对于合作者增强的要求。例如，SAP业务ByDesign（“ByD”）平台垂直架构基于一种三层方案（three tier approach），该三层方案由数据库层、应用层、以及用户界面层组成。在ByD实施中，整个应用逻辑在基于业务对象的ABAP应用服务器中运行。从水平架构的角度看，平台被划分为通过过程管理去耦合的多个单元，因为平台过程在部分范围场景中或者对于第三方集成的灵活部署是平台的关键优点。

图1示出了这样的平台的简化的业务示例的系统架构。在图1中示出的业务示例由客户关系管理（CRM）DU和项目管理（PM）DU组成。该示例基于销售订单快速活动用户界面（Sales Order QuickActivity User Interface），其具有用于创建带有对项目的参考的销售订单的用例。这个用例导致（lead to）搜索允许的和已有的项目以及验证（validate）在销售订单中使用的项目标识符的要求。

当前，跨DU（cross-DU）通信基于由过程代理框架（PAF）支持的应用对应用（A2A）或业务对业务（B2B）网络服务。在SAP ByD方案中，例如，所有DU过去被部署在单一的系统中，但是这种情形已经随着联网的应用的引入而改变，所述联网的应用运行在分离的系统中但是也需要在已有的ByD平台中的过程集成。

图2显示了使用绑定到销售订单快速活动控制器的快速活动平面布局（floorplan）的“创建订单”示例。销售订单快速活动使用销售订单作为主要（leading）BO。如果销售订单BO中的项目标识符被修改，则将由销售订单服务提供者经由在复制的项目视图中的本地客户代理（local consumer proxy，LCP）查找来验证该项目标识符。只能在只读模式下访问复制对象。项目视图业务对象的所有属性性质都是只读的，并且启用的（enabled）节点性质创建、启用的更新、以及启用的删除都被禁用（disabled）。此外，在用户界面上的值帮助（value help）经由基于文本挖掘（mining）系统（例如，SAP的文本检索和抽取（TREX）系统）的快速搜索基础结构（fast search infrastructure，FSI）查询来提供。用于这个场景的基本假设是所有的项目相关的数据从项目管理DU被复制到CRM DU。

项目BO的复制过程经由过程集成来实现。图3显示了具有复制的“创建项目”示例。利用创建项目导引的活动来创建项目。当保存项目时，“项目视图”出站代理被触发。出站代理从项目BO读取所有复制相关数据并经由过程代理框架调用项目视图入站代理。项目视图入站代理在CRM DU中创建项目BO视图的新实例。当保存项目BO视图时，复制的数据被存储在项目视图数据库大纲（schema）中，并且还将被复制到TREX。

包括数据的复制的描述的场景的开发要求必须被建模、实施、和/或改变的许多开发工件（artifact）。图4示出了视图对象的开发工件。必须被人工维护的大量的工件导致对于这样的场景的不合理的工作量。例如，使用传统系统，对于上述示例的工作估计是60人日（person days）：在元数据储存库中建模十四个新的开发对象，两个映射必须在Excel中建模。此外，必须实施多于六个的开发对象，并且必须改变七个开发对象。必须提供所有这些实体，包括设计、管理、测试、以及文件整理。

发明内容

在一方面，一种方法包括在目标部署单元中在元数据储存库的设计时间环境中生成视图对象。在源部署单元的业务对象上建模视图对象。源部署单元包括物理上从目标部署单元去耦合的业务应用的一组过程组件。该方法还包括选择源部署单元的业务对象的属性的子集。属性的子集至少包括由通用消息收发框架实施的出站代理和入站代理。该方法还包括利用业务对象的属性的子集在目标部署单元中建模视图对象。视图对象的入站代理被配置用于从业务对象的出站代理接收复制消息，并且复制消息包括用于仅以来自业务对象的数据配置视图对象的复制数据。

在以下附图和描述中阐述了一个或多个实施例的细节。从描述和附图，以及从权利要求中，其它特征和优势也将清楚。

附图说明

现在将参考以下附图详细描述这些以及其它方面。

图1示出了业务应用平台的系统拓扑。

图2显示了使用绑定到销售订单快速活动控制器的所绑定的快速活动平面布局的创建订单示例。

图3显示了具有复制的“创建项目”示例。

图4示出了用于视图对象的开发工件。

图5显示了简单投影视图对象的示例。

图6示出了目标架构。

图7示出了BO项目和项目视图之间的不一致的潜在源。

各个附图中相同的参考标号指示相同的元素。

具体实施方式

这个文件描述了在元数据储存库中建模视图对象作为BO投影的系统和方法中的声明性（declarative）视图对象，在该系统和方法中BO节点的永久属性可被用于投影中。这意味着不可能添加在BO本身中不具有它们的源（origin）的属性。所有其它的实体，诸如动作、除了组成以外的特殊关联、以及查询，默认地都不是投影的一部分，并且不可能添加它们。视图对象的投影的名称以及所有其它需要的新的工件都遵循储存库工具将支持的专门的命名约定（convention）。

基于元数据储存库中的这个模型信息，可以生成服务提供者和视图对象的永久性（persistency）。这个服务提供者基于BO处理框架，该BO处理框架负责在运行时的数据的对象关系映射。对于每个节点，支持“按照元素查询（query by elements）”。此外，至少在根节点级别，“选择所有（select all）”查询被提供用于初始加载TREX。数据也在TREX中被复制。

对于视图对象的复制，基于业务服务适配（business service adaptation，BSA）由通用（generic）框架实施和提供出站和入站代理。关于源BO的每个业务过程相关的“保存（save）”，复制出站代理以运行时最优化的格式使用投影的模型信息，以便从源BO读取复制需要的数据并组装（assemble）复制消息。这个消息然后经由过程代理框架发送到相应的通用入站代理，该入站代理分解（disassembles）复制消息并更新视图对象。这些专门的更新由复制上下文保护，以保证只有入站代理，而不是用户界面，才能够改变视图对象的数据。

建模

根据一些实施方式，元数据储存库支持新BO类别（category）视图对象，其优选的是具有约束（constraints）的BO，所述约束即（复制的）视图对象必须位于另一个DU中，每个源DU和源BO只允许一个视图对象，并且所有实体的命名都遵循命名约定。其他约束是：只有永久属性可以是投影的一部分；不支持瞬时属性、特殊关联、以及动作；视图对象的属性是只读的；生成视图对象模型；以及服务提供者不能被实施而是由通用框架提供。在另一些实施方式中，通用上下文和约束启用用于更新的弱性质检查，在每个节点上提供按照元素的查询，并且数据也被复制到TREX。在根节点级别上提供至少一个“选择所有”查询。在优选的实施方式中，支持对主数据的跨BO关联，要求可扩展性（extensibility）但是其不允许复制ACL，并且保持每个发送者和接收者的至少一个业务过程变体类型（business process variant type，BPVT）。

视图对象的名称由<目标过程组件的名称>+“的视图（ViewOf）”+<业务对象名称>得出。过程组件的名称可以由<部署单元的名称>+“视图对象”得出。

图5显示了在基于项目管理DU中的项目BO的客户关系管理DU中的CRM项目视图的简单投影视图对象的示例。

元数据储存库设计时间提供了通过选择需要的BO属性创建视图BO的投影的工具。根据一些实施方式，图4中所有人工建模的开发对象是使用以下命名约定来生成的：

● 过程组件

● 过程组件交互

● 交互角色

● 出站服务接口

● 出站操作

● 出站消息类型

● 出站代理

● 入站服务接口

● 入站操作

● 入站消息类型

● 入站代理

● 视图业务对象

此外，也生成以下开发对象……

● 作为SADL的出站映射

● 作为SADL的入站映射

● BOPF配置

● TREX视图

运行时

用于代理和视图BO的运行时部分由异步出站代理和入站代理根据业务服务适配（BSA）和视图BO服务提供者以及基于BO处理框架（BOPF）来执行。额外的配置数据被存储在元数据储存库中。这种配置数据可以以性能最优化和存储器最优化的运行时格式在运行时使用，但是不需要视图BO开发者配置这些运行时工件。

图6示出了目标架构。在目标DU中，从源BO到出站消息的映射以及从入站消息到视图BO的映射通过服务适配定义语言（service adaptationdefinition language，SADL）来描述。出站消息类型和入站消息类型具有相同的结构，然而由于它们需要位于不同的独立的软件包中的事实而具有不同的名称，但是它们在技术上是相等的。在运行时，使用业务服务适配（BSA）通过代理实施来运行SADL。这些出站代理和入站代理部分很快由建模的代理架构所取代。

在复制用例中，入站代理以允许代理修改视图BO的约束“服务启用”来设置上下文“复制”。如果不设置这个上下文，则任何对视图BO的修改都将导致异常（exception）。根据定义，视图BO对于标准客户是只读的。视图BO的服务提供者以BO处理框架（BOPF）来实施，用于标准创建、检索、更新、以及删除操作（CRUD）。如果定义了TREX视图，则TREX服务提供者被用于这些查询。为了支持TREX，视图BO提供select_all查询，该查询由BOPF使用主数据库永久性来实施。对于TREX的初始加载，需要select all查询。复制也可以取决于用于出站代理的开始、改变、取消条件（状态），从而并不是源BO的每一个保存都将导致复制。这些条件可以在通用出站代理实施中建模和运行。

根据场景，代理能够实施完整的传输或增量处理（delta handling）。PIP条目（entries）被要求支持调和（reconciliation），并且在增量处理的情况下，被要求确定动作代码。

初始加载通过PI升级框架来进行，其在停机时间（downtime）之后为所有受影响的实例触发调和消息。通过这样做，从一开头就正确地创建PIP，并且不通过额外的XPRA延长停机时间。然而，必须考虑到，在升级之后的一小段时间内，在目标DU中一些BO实例可能消失，直到所有的调和消息都被触发和处理为止。

在标准用户界面用例中，视图BO可以用在任何包括对象值选择的只读场景中。外键关联还可以用作对视图BO的目标。必须在参考或使用视图BO的分离的BO中提供额外的业务逻辑。不支持视图BO的模型充实，并且该视图BO的模型充实必须由属于正确（right）过程组件的分离的BO来实现。

视图对象不是基于角色的授权管理（role-based authorization management，RBAM）相关的，并且不能用在本地客户代理（LCP）调用中的栈级别1（stacklevel one）上，即例如用户界面中。视图对象只被允许在特许模式（privilegedmode）中使用。因此，视图BO不能是用户界面中的主BO。如果其被联接（joined），则主BO的授权将被继承。

设计时间支持取决于合作者开发工具，并且如果视图BO还未存在的话，源BO的公共方案部分可用来定义视图BO。如果视图BO确实存在，则应当经由包括入站代理和出站代理的标准可扩展能力来扩展视图BO。在合作者层中，可以通过选择源BO的附加的需要的字段来扩展已有的视图BO。所有的模型和配置增强通过基础结构来生成。在这个用例中，要求对于视图BO中的扩展的属性的初始（增量（delta））加载。视图对象的复制通过出站和入站代理来实现，并且相关联的消息可以导致源BO和视图BO之间的不一致性。数据流验证（DFV）检测一个单一的系统实例的各个BO中的不一致性。

这些不一致性是事件（incidents）的潜在来源（potential source）。当得知并且已经改正了不一致性的根本原因时，可以使用DFV来检查和清理视图对象。由于视图对象模型信息在元数据储存库中并且是可以获得的，并且生成服务提供者和视图对象的永久性，因此必要的DFV预定义的内容（映射和一致性条件）也应当存储在MDRS（MO DFV）中。只能比较BO对的DFV约束也被满足，因为只允许每个源DU的一个视图对象。在运行时（定期调度DFV MDRO），则通用DFV框架能够基于所生成的内容读取源BO的相关部分，并且将数据与复制的视图BO进行比较。在检测到不一致性的情况下，DFV能够触发从源到目标对象的调和消息以便去除该不一致性。

图7显示了BO项目和项目视图之间的不一致性的潜在来源。这里，基本假设是RC DFV也工作在不同的系统实例之间，并且该概念并不是这个文件的一部分。比较逻辑针对具体节点的存在以及这些节点上的属性的正确性而检查BO/视图对。

在本说明书中描述的一些或全部功能操作可以以数字电子电路来实施，或者以计算机软件、固件、或硬件（包括在本说明书中公开的结构以及它们的结构等效物）来实施，或者以它们的组合来实施。本发明的实施例可以实施为一个或多个计算机程序产品，即，编码在计算机可读介质（例如机器可读存储设备、机器可读存储介质、存储设备、或机器可读传播信号）上、用于由数据处理装置运行或者控制数据处理装置的操作的计算机程序指令的一个或多个模块。

术语“数据处理装置”涵盖所有用于处理数据的装置、设备、以及机器，作为示例，包括可编程处理器、计算机、或多个处理器或计算机。除了硬件以外，所述装置可以包括创建用于所讨论的计算机程序的运行环境的代码，例如，构成处理器固件、协议栈、数据库管理系统、操作系统、或者它们的组合的代码。传播信号是人工生成的信号，例如，机器生成的电、光、或电磁信号，生成所述信号以便对信息进行编码，用于传送到合适的接收者装置。

计算机程序（也称为程序、软件、应用、软件应用、脚本、或代码）可以用包括编译或解释语言的任何形式的编程语言来编写，并且其可以用任何形式来部署，所述形式包括作为独立程序或作为模块、组件、子例程、或其它适于在计算环境中使用的单元。计算机程序不必对应于文件系统中的文件。程序可以存储在保存其它程序或数据（例如，存储在标记语言文件中的一个或多个脚本）的文件的一部分中、存储在所讨论的程序专用的单一文件中、或者存储在多个经协调的文件（例如，存储一个或多个模块、子程序、或代码部分的文件）中。计算机程序可以被部署为在一台计算机或多台计算机上运行，所述多个计算机位于一个地点或者分布在多个地点并通过通信网络互连。

本说明书中描述的过程和逻辑流可以由一个或多个可编程处理器执行，所述处理器运行一个或多个计算机程序，以便通过对输入数据进行操作并生成输出来执行功能。过程和逻辑流也可以由专用逻辑电路执行，并且装置也可以实施为专用逻辑电路，专用逻辑电路例如为FPGA（现场可编程门阵列）或ASIC（专用集成电路）。

作为示例，适于运行计算机程序的处理器包括通用和专用微处理器两者、以及任何种类的数字计算机的任何一个或多个处理器。通常，处理器将从只读存储器或随机存取存储器或者从两者接收指令和数据。计算机的主要元件是用于执行指令的处理器和用于存储指令和数据的一个或多个存储设备。通常，计算机还将包括通信接口，或者计算机将可操作地耦接到通信接口，以便从一个或多个用于存储数据的大容量存储设备接收数据或者向该大容量存储设备传送数据或者两者，所述大容量存储设备例如为磁盘、磁光盘、或光盘。

而且，计算机可以嵌入另一个设备，例如移动电话、个人数字助理（PDA）、移动音频播放器、全球定位系统（GPS）接收器，仅举数例。适于包含计算机程序指令和数据的信息载体包括所有形式的非易失性存储器，作为示例，所述非易失性存储器包括半导体存储设备，例如，EPROM、EEPROM、以及闪存设备；磁盘，例如，内部硬盘或可移动盘；磁光盘；以及CD ROM和DVD-ROM盘。处理器和存储器可以由专用逻辑电路补充，或结合到专用逻辑电路中。

为了提供与用户的交互，本发明的实施例可以实施在计算机上，所述计算机具有：显示设备，例如CRT（阴极射线管）或LCD（液晶显示器）监视器，用于显示信息给用户；以及键盘和指示设备，例如，鼠标和轨迹球，用户可以以此提供输入给计算机。其它种类的设备也可以用来提供与用户交互；例如，提供给用户的反馈可以是任何形式的感觉反馈，例如，视觉反馈、听觉反馈、或触觉反馈；并且来自用户的输入可以以包括听觉、语音、或触觉输入的任何形式接收。

本发明的实施例可以在包括后端组件或包括中间件组件或包括前端组件的计算系统中实施，或者以这样的后端、中间件或前端组件的任何组合实施，后端组件例如为数据服务器，中间件组件例如为应用服务器，前端组件例如为具有图形用户接口或网络浏览器的客户端计算机，用户可以通过图形用户界面或网络浏览器与本发明的实施交互。系统的组件可以通过任何数字数据通信形式或介质（例如通信网络）互连。通信网络的示例包括局域网（“LAN”）和广域网（“WAN”），例如，因特网。

计算系统可以包括客户端和服务器。客户端和服务器一般相互远离，并且通常通过通信网络交互。客户端和服务器的关系凭借在各自的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生。

为清楚起见而在本说明书中在分离的实施例的上下文中描述的某些特征也可以以组合提供在单一实施例中。相反地，为简单起见而在单一实施例的上下文中描述的各种特征也可以分别或以任何合适的子组合在多个实施例中提供。而且，虽然在上文中特征可能被描述为以某些组合动作并且甚至最初是这样声称的，但是在一些情况下，可以从所声称的组合中去除来自该组合的一个或多个特征，并且所声称的组合可以指向子组合或子组合的变型。

已经描述了本发明的特定实施例。其它实施例在所附权利要求的范围之内。例如，在权利要求中列举的步骤可以以不同的顺序执行，并且仍达成期望的结果。此外，本发明的实施例并不限于关系数据库架构；例如，能够实现本发明以便向建立在除了关系模型以外的模型上的数据库（例如，导航数据库或面向对象的数据库）以及包括具有复杂属性结构的记录（例如，面向对象的编程对象或标记语言文件）的数据库提供索引建立和归档方法和系统。描述的过程可以由具体执行归档和检索功能或嵌入在其他应用之内的应用来实施。

Claims

1.一种计算机实施的方法，包括：

在目标部署单元中，在元数据储存库的设计时间环境中生成视图对象，在源部署单元的业务对象上建模所述视图对象，所述源部署单元包括物理上从所述目标部署单元去耦合的业务应用的一组过程组件；

选择所述源部署单元的业务对象的属性的子集，所述属性的子集至少包括由通用消息收发框架实施的出站代理和入站代理；以及

利用所述业务对象的属性的子集在所述目标部署单元中建模视图对象，所述视图对象的入站代理用于从所述业务对象的出站代理接收复制消息，所述复制消息包括用于只以来自所述业务对象的数据配置视图对象的复制数据。

2.如权利要求1所述的方法，其中在设计时间环境中生成视图对象还包括生成服务提供者和元数据储存库中的视图对象的永久性。

3.如权利要求2所述的方法，其中所述服务提供者基于业务对象处理框架。

4.如权利要求3所述的方法，其中所述业务对象处理框架在运行时处理所述视图对象的对象关系映射。

5.一种计算机程序产品，包括存储指令的机器可读介质，当由至少一个可编程处理器运行所述指令时，所述指令使得所述至少一个可编程处理器执行操作，所述操作包括：

6.如权利要求5所述的计算机程序产品，其中在设计时间环境中生成视图对象的操作还包括生成服务提供者和元数据储存库中的视图对象的永久性的操作。

7.如权利要求6所述的计算机程序产品，其中所述服务提供者基于业务对象处理框架。

8.如权利要求7所述的计算机程序产品，其中所述业务对象处理框架在运行时处理所述视图对象的对象关系映射。

9.一种系统，包括：

至少一个可编程处理器，其与应用服务器相关联；和

机器可读介质，其存储指令，所述指令当由至少一个处理器运行时，使得所述至少一个可编程处理器执行操作，所述操作包括：

10.如权利要求9所述的系统，其中在设计时间环境中生成视图对象的操作还包括生成服务提供者和元数据储存库中的视图对象的永久性。

11.如权利要求10所述的系统，其中所述服务提供者基于业务对象处理框架。

12.如权利要求11所述的系统，其中所述业务对象处理框架在运行时处理所述视图对象的对象关系映射。