SAP ABAP-BOPF基础培训-02 导入、节点和关联

1. 介绍-Introduction

业务对象实例示例：

本次案例主要探讨客户发票业务对象内容。
ESR中建模的业务对象示例：

发票的结构和属性在ESR中建模。在使用业务对象之前，我们需要首先实现该模型的所有功能。

2. 导入业务对象代理-Importing a Business Object Proxy

将代理模型导入BOPF：

请执行以下步骤将代理BO导入BOPF:
① 启动BOPF设计工作台Workbench(事务码： /BOBF/CONF_UI)；
② 通过按图标创建一个新的业务对象；
③ 输入BOPF名称和BO的代理名称；
④ 将代理对象模型导入BOPF，并创建与ESR模型实体(节点、关联等)相对应的BOPF模型实体。

重新导入代理-Proxy Re-Import：

如果ESR-Model或代理发生了变化，则需要将代理模型重新导入BOPF。

1) “Extras” > “Import Proxy Business Object”;
2) 成功重新导入后，将自动显示更改列表;
3) 显示了更改节点的详细信息;

3. 节点配置-Configuration of the Nodes

导入后的节点配置-Node Configuration right after Import:

导入后的BOPF节点需要进行配置。该节点实例没有存储数据所必需的数据类型集。

3.1 创建节点数据模型-Create Node Data Model

数据结构(Data Structure)：每个节点都有一个包含持久字段的内部数据结构;
数据结构(tr.) transient：包含该节点临时字段的数据结构(临时字段:不存储在持久性中，只存在于缓冲区中的字段);
组合结构(Combined Structure)：由数据结构、可选的临时数据结构和包括一个 technical key(例如缓冲所必需的)；
组合表类型(Combined Table Type)：用于存储一个节点的多个实例的数据的表类型(对于大规模访问是必要的)。行类型对应于组合的结构。

3.2 建议存储库名称-Propose Repository Names

BOPF为各种字典对象提供了命名建议：
可以选择实体，并为生成的名称指定名称空间和前缀；
检查提议的名称是否符合命名约定(截断等)；

这是执行“Propose Repository Names”函数的结果。

3.3 生成DDIC元素-Generate DDIC Elements

BOPF可以在模型中指定其名称后生成DDIC元素(手动或通过“Propose Repository Names”)。
可选择生成的元素:
组合数据结构包括手动创建的内部数据结构和添加框架特定字段；
组合表类型使用组合数据结构作为行类型。
命名建议和字典元素生成的示例：

① 手动创建数据结构(只有当有临时字段时才创建临时字段的数据结构)；
② 建议组合结构和组合表类型的存储库名称；
③ 为合并结构和合并表类型生成字典元素。

3.4 代理属性映射-Proxy Attribute Mapping

代理结构和内部模型之间的映射是必要的，因为代理结构可以深度嵌套，但内部数据类型应该是完全扁平的(数据库的限制)。

        将每个叶代理结构元素分配给组合结构的内部结构元素(对每个业务对象节点执行此操作，在本例中仅为根节点)；
      必须映射代理结构的叶子元素，因为只有叶子元素包含数据；
      未映射的内部字段可以存储内部数据，这些数据对客户永远不可见。

异常(Exception):显示映射表项是否一致。
层次(Hierarchy):该属性的代理结构中的级别。
转换(Conversion):可以添加转换规则(例如大写或字母数字)提示:如果不启用写模式，属性表是完全不可见的。

3.5 创建数据库表-Creation of a Database Table

为节点创建数据库表：
1. 数据库表名可以由BOPF提出(" Extras " -> " proposed Repository Names ")
2. 数据库表可以生成(“Extras”->“Generate Repository Objects”->“Generate Dictionary Elements”)或手动创建

3.6 节点持续性映射-Node Persistency Mapping

数据库表中的持续性：
数据库中的字段名必须与内部数据结构相对应，或者一个命名的include可以在持续性映射中使用和指定；
数据库表中不存在的内部字段称为“transient”(即临时字段)；
示例中的节点是根节点的子节点，因此我们可以将两个字段(ROOT_KEY和PARENT_KEY)映射到一个数据库属性，因为它们总是具有相同的值。

3.7 常量接口生成-Constant Interface Generation

每个配置元素(例如节点，动作)在设计时和运行时都是由GUID在BOPF中唯一标识的。
使用内部模型信息的应用程序特定内容必须使用这些guid(例如，重用实现)。
BOPF提供了生成包含所有guid的常量接口的可能性。
提示:在创建新的配置元素之后需要重新生成Constant Interface。

3.8 加载-Loading

节点可以单独加载：Node Can Be Loaded Separately

缓冲数据(buffering data)的两个原因:
事务性缓冲(Transactional Buffer):数据在事务期间被更改(ESI要求)；
缓存(Cache):出于性能原因对数据进行缓存。

BOPF的标准缓冲区实现以组合的方式支持这两种方法:
        提供简单的加载逻辑来管理缓存;
        决定何时以及加载业务对象的哪个部分;
        通过模型信息控制.

BOPF的方法:加载组(Loading groups)
        由一个标记为可加载的节点及其本身不可加载的子节点组成;
        根据定义，ROOT节点必须是可加载的;
        没有持续性的对象(临时对象)没有加载组；
        性能建议:加载组越小越好(通常是一个节点)。

3.9 锁定-Locking

节点可以单独锁定：Node Can Be Locked Separately

ESI 合同没有定义业务对象的锁定粒度，BOPF负责锁定业务对象实例
显式锁定(Explicit locking)请求从ESF只有通过EDIT_MODE检索调用；
隐式锁定(Implicit locking)需要通过修改；

锁定每个单独节点的可能性是没有意义的.

BOPF的方法:锁定组(Locking groups)
        由一个标记为可锁定的节点和它本身不能锁定的子节点组成;
        当对不可锁定的节点请求锁定时的策略:锁定最近的可锁定的上级节点；
        可锁定节点也必须是可加载的。

规则:来自同一个加载组的所有节点必须属于同一个锁定组!

3.10 节点类型-Node Types

BOPF在内部模型中支持不同类型的节点:
        标准节点(Standard Nodes)
        框架节点(Framework Nodes):默认不显示，包含有关实例的信息:
                属性节点-Property Nodes(后缀“_PROPERTY”):存储动态属性;
                锁节点-Lock Nodes(后缀“_LOCK”):缓冲锁信息;
                消息节点-Message Nodes(后缀“_MESSAGE”):包含的信息验证.

示例中未显示:
        委托节点-Delegated Nodes(依赖对象的表示);
        业务对象表示节点-Business Object Representation Nodes(跨bo关联目标的表示);
        查询响应转换节点-Query Response Transformation Node.

BOPF框架节点-BOPF Framework Nodes:

框架核心不保存任何实例特定的数据，因此框架节点用于存储这些数据；
框架节点不能被服务使用者访问，但是可以从BO内容访问；
框架节点不是持久化的(例外情况:消息节点可以选择持久化)；
框架节点结构:
        每个节点只有一个属性节点；
        每个节点只有一个消息节点；
        每个可锁节点只有一个锁节点；

如何显示框架节点？

默认情况下，框架节点在CONF_UI中是不可见的；
要使它们可见:"Utilities" >"Settings"> "Business Object"，如上图对应打勾。

框架节点配置说明：

4. 关联的配置-Configuration of the Association

Association配置概述：

Association 类型和类别：
BOPF在内部模型中提供了两种不同类型的Association：
复合关联(Composite Associations):沿着父节点和子节点之间的组合。

类别(Categories):
       常规组合关联-Regular Composition Association；
       特殊化(不等于面向对象的“特殊化”)-Specialization (not equal to the "specialization" from object orientation)；
       关联到委托节点(从属对象)-Association to delegated node (Dependent Object)；
       框架关联(链接到框架节点，如属性节点)Framework Associations (Link to Framework Nodes, e.g. Property Nodes)。

一般关联(General Associations):跨组合树链接。

类别(Categories):
        外键关联/反向外键关联- Foreign Key Association / Reverse Foreign Key Association;
        反向特殊化-Reverse Specialization；
        关联到Parent-Association To_Parent；
        关联到Root-Association To_Root；
        跨BO关联-Cross-BO Association；
        常规关联(具体实现)-Regular Association (implementation specific)；

基数和解析节点-Cardinality and Resolving Node
关联的基数(Cardinality of an Association):连接到一个源实例的节点实例的数量。

解析节点(Resolving Node):可以根据用于解析关联的节点来区分关联。
源解析关联(Source resolved associations):源节点包含解析关联所需的信息;
目标解析关联(Target resolved associations):目标节点包含解析关联所需的信息。

实施与绑定-Implementation vs. Binding
关联逻辑可以通过两种不同的方式存储:
实施(Implementation):
        需要与特定业务逻辑的关联，现有的关联绑定没有涵盖这一点。
        IF_FRW_ASSOCIATION接口的实现是必要的;
关联绑定-Association Binding：
        可以在不需要任何实现的情况下轻松建模；
        绑定由缓冲区实现解决；
        绑定支持的关联类型:
        – Compositions (no binding necessary)
        – Specialization / Reverse Specialization
        – Foreign Key Associations / Reverse Foreign Key Associations
        – To_Parent
        – To_Root