分类 SAP 下的文章

 

本文阐述了ABAP CDS association的概念，并且展示了在CDS视图中和SQL语句中写路径表达式（Path Expression）代码的方法。我也会解释如何在CDS asociation中指定inner join——默认情况下是left outer join，以及如何为association添加过滤。

 

对于CDS的相关开发，SAP希望我们使用association而不是join，因为association更加接近“概念思维”。基本上，association本身不是join，它只是有关join连接可能性的元数据，它会按需成为join。真实的join会在路径表达式使用association的时候被创建。

 一个简单的CDS association例子，它看起来和left outer join没区别：

@AbapCatalog.sqlViewName: 'ZCDS_ASSOC11'defineview zcds_assoc1 as select from scarr assca

   association[0..1] to spfli as_spflion sca.carrid =_spfli.carrid   

   {* }

即便努力去尝试最小化SAP系统中的自定义内容，通常还是无法避免大量的自定义业务逻辑。在过去，这意味着需要在系统的各种地方引入自定义ABAP代码，包括user-exits，enhancement，BAdi和自定义程序等等。考虑到SAP系统的复杂性和相互依赖性，人们不得不小心翼翼地管理基于ABAP的自定义内容，以保证不同的功能区域的业务逻辑一致、且不重复。

现在，Business Rule Framework Plus（业务规则框架，以下简称BRFplus或BRF+）来了，它是SAP推出的新功能，可以在一个位置、通过可复用的方式管理你的所有自定义业务逻辑。

 

本文链接：http://www.cnblogs.com/hhelibeb/p/9021665.html

英文标题：BRFplus - a hidden gem within your SAP system

可用性

通常来说，BRF+功能在任何基于合适版本的SAP NeWeaver的系统都可用。要快速地检验它是否在你的系统上可用，只需要执行事务代码BRFPULS或者BRF+。如果你看到了在新浏览器窗口打开的web应用，那么基本上你的环境允许使用BRF+。（如果不能的话打开的话，有可能是系统本身不支持，也有可能是没有配置webdynpro相关服务等）

值得注意的是，在2013年，SAP发布了一个名为Decision Service Management（DSM）的解决方案，它建立在BRF+的基础上，并且添加了某些新的功能。最重要的是DSM允许跨SAP系统和实例的中央业务规则管理。然而，DSM需要额外的许可证，相反一般BRF+通过已有的SAP许可证就可以使用。我们发现对绝大多数客户来说，DSM的功能有点过了头，BRF+则更适合使用。

使用场景

现在你知道了一点BRF+的历史，那么在你能用它来做什么呢？这里是一些真实世界利用BRF+满足业务需求的例子：

  • 输出表单中的Logo判断
  • 服务提醒文档的默认优先级和截止日期判断
  • 销售订单的默认工厂判断
  • SAP Transportation Management中的默认载具判断

从技术的观点看，BRF+最常见的用例是在user-exits和增强中的自定义业务逻辑实施中。事实上，在这些情况下，BRF+是我们实现自定义业务逻辑的首选实现手段。它在较高层面上可以被描述为2步：

  1. 在BRF+中创建一个function，依据需要的业务逻辑，它接收输入、进行处理，然后给出输出结果。
  2. 通过ABAP在user-exits/BAdi/enhancement/自定义程序等地方调用先前创建的BRF+应用。

很重要的一点是，在上述的方式中你还是需要写一些ABAP代码来调用BRF+ function。（和完全使用ABAP代码实现业务逻辑的）区别在于，通常来说，在这种情况下，ABAP代码只负责调用BRF+，不会直接包含业务逻辑。你可能要问这样做的好处在哪里。它的好处是：

  • BRF+ function易于复用，通常可以大大地减少系统中重复业务逻辑实现的数量。
  • BRF+包含一个巨大的expression库，可以加速映射业务规则的开发过程，特别是这些业务规则比较复杂的情况下。使用ABAP编码来从零开始（from scratch）实现某些东西，也许可以花上数天甚至数周的时间，但是在BRF+里只要使用expression就可以快速地建模实现。
  • 你的所有自定义业务逻辑可以在一个地方实现——BRF+事务。你不需要从庞大的自开发程序、增强中搜寻代码以调整现有的业务逻辑。
  • 对现有的业务逻辑的简单调整可以经由非编码的方式实现，不需要开发人员的参与。

最后一点值得详细阐述。SAP通常建议通过BRF+工具让业务用户代替ABAP开发者来作为他们自己的逻辑的维护者。坦白说，这种建议有点夸张（exaggerattion）。实际上，BRF+元素（function, expression等）的创建依然是一件相当技术性的活动。大部分没有技术背景的SAP专家可能会发现，想要掌握BRF+的全部内容是件具有挑战性的事情。了解一些基本的编程概念，如变量和循环，会对BRF+的使用起很大帮助，即便你只是通过鼠标来创建这些对象，而不是写ABAP代码。但是撇开陡峭的学习曲线不说，在具备足够多的学习时间和努力的情况下，SAP功能分析师当然是可以精通BRF+的，由此便可以在不依赖开发者的情况下构建复杂的自定义业务逻辑。然而，业务用户完全是另一回事。业务用户对BRF+进行某些实验性的调整是可能的，例如改变已有的decision table中的值，但是BRF+内的主要变更还是需要由IT团队进行。

特性

BRF+中包含很多了不起的特性，使得它是一个杰出的业务规则框架。

expressions

在许多方面上expressions是BRF+中第一个令人心动的东西。它们是预包装的逻辑对象，可以在BRF+环境中大大加速业务规则的建模。虽然BRF+中支持多种表达式类型，但最常用的一种是Decision Table。如果你熟悉SAP系统中的条件技术，decision table会给你相似的感觉，并且它会提供扩展性更强的功能。除了可以从表的顶部检索到底部直到找到匹配的记录为止外，你也可以维护输入值为多值的range、sets、通过空白来表示任意值、以及使用其它一些逻辑操作符等。

customizing and master data applications

定制和主数据应用（customizing and master data applications）是BRF+中的一个灵巧的特性。定制应用需要使用SAP transports来在不同SAP系统之间移动修改，相反主数据应用允许直接在每个SAP系统和client直接进行修改。在你将主数据值，比如客户、供应商、物料等是业务逻辑的一部分时特别有用。记住，因为在多数情况下BRF+通过ABAP调用，function本身需要存在在一个定制应用中。但是这些定制级别的function接下来可以利用存在于主数据级别应用下的expressions（例如decision tables）。一言蔽之，你可以在一个业务规则中混合使用定制和主数据BRF+对象。

user interface

BRF+中的建模大多通过“点击”的用户界面进行，通过事务代码BRF+访问它。你可以通过简单地右击屏幕左侧的节点来创建新的对象，并且通过上下文菜单选择合适的条目。

api

你也可以通过API和BRF+交互。这意味着你不仅可以通过事务BRF+来创建和更新BRF+对象，你也可以通过标准交付ABAP类和方法（standard delivered ABAP classes and methods）实现同样的事情。例如，在某个场景中我们需要存储美国的柴油平均价到BRF+的decision table中。我们可以创建一个自定义ABAP程序通过公网服务来查找上周的柴油价格，并且最后经由BRF+ API更新decision table。

web services

BRF+ functions可以很容易地暴露为web services。这意味着你可以同时在SAP和非SAP系统中消费BRF+业务逻辑。

helper tools

BRF+伴随着大量的工具，可以帮助你开发、导入/导出、检查和BRF+对象和排查故障。其中某些工具可以从BRF+事务中的菜单访问，不过最简单的查找他们的方式是在SE38中运行程序FDT_HELPERS。较早地了解这些工具，你就可以在将来省下很多时间。例如，下图里选中的工具允许你快速地识别和解决大部分有关系统间传输BRF+对象的问题。

 

总而言之，大部分SAP客户都可以在不需要额外许可证的条件下使用BRF+。我们鼓励你仔细了解BRF+、并且开始为你的自定义业务逻辑需求使用它。

我的BRF+教程系列：http://www.cnblogs.com/hhelibeb/tag/BRFplus/

 

 

本文是对接口编程的讨论，希望能对年轻的开发者有所帮助。

要点：

  • 通过接口对类方法进行更高层的抽象
  • 接口使代码清晰易读
  • 接口使你可以创建模拟对象（Mockup Object）以提高代码的可测试性
  • 帮助实现SOLID原则
  • 可以在不使用RTTS和类型转换的前提下使用多种类的不同实例。

因为在学习ABAP之前，我曾经学习过其它面向对象语言，因此我很纠结于ABAP中不存在的一个特性——重载方法（overload)。

也许你会问，重载是什么？

重载就是函数或者方法有相同的名称，但是参数列表和实现不相同的情形。

没有了重载，在某种程度上，类也许会变的过大，并且难以追踪那些有着相似行为但是名字不同的方法。

接口不提供重载能力，但是通过限制名字不同但是功能相近的方法的数量，接口可以整理和简化你的代码。

 

本文链接：http://www.cnblogs.com/hhelibeb/p/8919767.html

英文原文：Using interfaces to standardize your ABAP OO Development

简介

在ABAP中类的继承是单一继承（每个类只能有一个父类），接口实现可以有多个。

例如，上图中的LCL_Child_Class继承LCL_Parent_Class中所有的非私有变量、方法、类型和常量，并且必须实现LINF_Utility和LINF_Saver接口中所有的功能。

为了解释接口的定义，我将使用个“不怎么专业”的描述——它是一个类似于类的实体，不包含所声明的方法的任何具体实现，但是它可能包含常量、类型和变量。接口无法被初始化。

默认情况下接口的所有方法都必须被实现——这是面向对象编程中的一个通常的强制规则。不能允许接口方法的实现变得可选择，但是这不属于本文的讨论范围，所以不会展开论述。

（译注：原文评论指出，在ABAP中，可以使用DEFAULT IGNORE|FAIL附加项指定可选的接口方法，虽然好像并没有什么用）

“真实”用例

设想下我们有个程序，需要从多种数据源获取数据并更新到表SFLIGHT：

  • Excel上传
  • RFC上传
  • 在程序运行期间上传修改和插入的行

当然我们可以在该清单中添加ADBC源、经由HTTP客户端对象抓取的JSON/XML源等，但是我只是想介绍下要点，没必要穷举所有例子。

同时，因为本文只是对可能性的表述，因此我不会创建一个能真正工作的程序。

声明接口

我们将创建2个接口，不过在这个例子里只有一个是真实需要的。

第一个是最重要的，我命名它为linf_sflight_career，因为这是个用于EXCEL、RFC和本地表运输（carrier）的本地接口，在本地类中实现。

interfacelinf_sflight_carrier.

    types: tt_sflight type standard table of sflight with default key,

           st_sflight type sorted table of sflightwith non-unique key mandt carrid connid,

           ht_sflight type hashed table of sflightwith unique key mandt carrid connid fldate.

    methods:"! Returns hashed table SFLIGHT contents
             "! @parameter r_sflight |
get_hashed_records returning value(r_sflight) type ht_sflight,"! Returns sorted table SFLIGHT contents
             "! @parameter r_sflight |
get_sorted_records returning value(r_sflight) type st_sflight,"! Returns standard table SFLIGHT contents
             "! @parameter r_sflight |
get_standard_records returning value(r_sflight) type tt_sflight.       

endinterface.

定义

读取访问日志（以下简称RAL）用于监视并记录对敏感数据的读取访问。这里的数据是指会被法律、外部公司政策或公司内部政策归类为敏感信息的数据。以下典型问题可能会与使用读取访问日志的应用程序有关：

  • 谁访问了某个商业实体的数据，例如银行账户？
  • 谁访问了私人数据，例如商业伙伴的数据？
  • 哪位员工访问过某些个人信息，例如宗教信仰？
  • 有没有人搜索过，是否有VIP被送入医院？
  • 哪些用户访问过哪些帐户或业务合作伙伴（BP）？

这些问题都可以使用“特定时间范围内、访问特定数据的人的信息"来回答。从技术上讲，这意味着必须启用所有（访问数据的）远程API和UI基础设施以进行日志记录。但是，目前仅限于以下渠道可以使用RAL：

  • Remote Function Calls (sRFC, aRFC, tRFC, qRFC, bgFRC)
  • Dynpro
  • Web Dynpro
  • Web services

 

有关每种渠道可以记录的对象的更多信息，可以访问： Channel-Specific Information.

RAL的主要目的

RAL通常需要符合法律法规或公共标准（如数据隐私政策），比如在银行或医疗保健应用程序中。数据隐私即是对个人数据的访问保护和限制。在一些国家，数据隐私法规甚至要求报告对某些个人数据的访问行为。此外，公司和公共机构们，出于其自身的原因，也可能希望监视对其保密数据或其他敏感数据的访问。如果没有跟踪或记录访问数据行为，则很难跟踪到需要对数据泄漏事件负责的人员。RAL提供了这些信息。

日志记录的目的（purpose）是根据组织的需求自由定义的(例如，数据隐私)，而RAL总是基于该目的。日志记录目的会作为属性被分配给每个日志条目，从而允许根据日志记录目的对日志数据进行分类和组织。例如，可以基于记录目的创建各种归档规则或报告。

因此，阅读访问记录框架可用于履行法律或其他法规、检测欺诈或数据盗窃、审计或用于任何其他内部目的。

RAL架构的背景信息

当应用程序启动时，会读取RAL配置。 根据RAL配置识别当前启用远程的功能模块、Web服务操作或Web Dynpro UI元素是否与日志相关、以及相关程度如何。 例如，应该只有访问行为本身被记录，还是包括访问内容？ 日志条目可以根据它们的语义进行结构化。

SAP应用程序可能包含预定义配置。但是，客户的管理员通常必须根据自己的需求来调整配置，以满足其组织的法律要求——SAP并不了解全部的需求。 客户也可以创建自己的配置。

注意：注意与所有日志记录功能一样，您的对日志数据的需求，必须与记录日志对系统性能的影响保持平衡。 系统的性能取决于您记录的数据量以及您为记录数据指定的条件的复杂程度。

活动

配置工作

1. 确定在哪些情况下必须记录哪些数据。

组织必须定义要应用哪些法律或安全要求以及哪些数据必须在语义级别上进行记录。例如，法律部门可能确定必须记录对社会保障号码（SSN）的访问。

2.  为读取访问记录定义目的（ purposes ）。

根据日志记录的目的以及必须满足的法律法规，应用程序可以定义报告和保存和处理数据的规则。有关更多信息，请参阅Defining Logging Purposes。

3. 确定可以访问数据的渠道。

例如： RFC, Dynpro, Web Dynpro, 或者 Web services.

4. 定义日志域。

日志域是需要记录的语义相关数据字段组。例如，总薪水和净薪水可能会被分组到薪酬日志域中。日志域捆绑了相同语义实体的不同技术表示。日志域是独立于渠道的。有关更多信息，请参阅Defining Log Domains。

5.  定义规则以描述必须适用于读取访问记录的条件。

您可以定义需要记录哪些数据以及是仅记录访问还是内容。有关更多信息，请参阅Configuring Read Access Logging。

运营期间的工作

1. 为读取访问日志配置定义用户排除列表。

如果您想从读访问日志记录中排除某些用户，请将其添加到用户排除列表中。 这对于没有用户交互的自动处理很有用，例如后台作业。 有关更多信息，请参阅Defining a User Exclusion List。

2. 启用当前client的读取访问日志

读取访问日志必须在当前client中启用。 否则，配置将被忽略。 有关更多信息，请参阅Enabling Read Access Logging in Current Client。

3. 显示对RAL配置所做的更改，并评估错误和警告。

请参阅：Working with the Administrative Log

4. 使用信息生命周期管理（ Information Lifecycle Management, ILM）和归档开发工具包（ Archive Development Kit, ADK）归档和删除读取访问记录数据。

请参阅：Archiving Read Access Logging Data

5. 为档案创建信息结构

监控

您可以使用Read Access Logging监控器查看所有日志条目。 有关更多信息，请参阅Monitoring the Read Access Log。

事务代码

相关的3个事务代码：SRALMANAGER，SRALMONITOR，SRALCONFIG。

事务代码描述
SRALMANAGER RAL记录管理器。显示Read Access Logging Manager中的监控和管理标签。
SRALMONITOR RAL记录监控器。只显示Read Access Logging Manager中的监控标签。
SRALCONFIG RAL日志记录配置。只显示Read Access Logging Manager中的管理标签。

 

 

参考阅读：How to Configure Read Access Logging in SAP

　　　　   System Security for SAP NetWeaver AS for ABAP Only- Read Access Logging

　　　　   Read Access Logging (RAL) Configuration

　　　　   1969086 – Availability of Read Access Logging and prerequisites (kernel and SAP GUI version)

 

在以SAP系统作为主要ERP的企业中，不同系统之间的数据库数据同步是个重要的工作。对于这种需求，除了开发ABAP接口之外，也有高效的工具可用。SLT就是其中之一。

SLT是SAP的第一个ETL（Extract-Transform-Load）工具，它允许实时加载和复制数据，或者将数据从源系统和非源系统调度到SAP HANA数据库。

SAP SLT服务器使用基于触发器的复制方式以实现从源系统到目标系统的数据传递。

SLT服务器可以安装在单独的系统或SAP ECC系统上。

SLT系统的好处如下：

  • 允许实时或按计划时间进行数据复制。
  • 在实时复制数据的过程中，可以以SAP HANA格式迁移数据。
  • SLT可以处理簇表和池表
  • 在加载/复制期间支持非Unicode和Unicode的自动转换。
  • 与SAP HANA Studio有着完全的集成。
  • SLT有表设置和转换能力。
  • 可以通过SAP HANA Solution Manager监控。

 SLT的全称是 SAP Landscape Transformation

本文链接：http://www.cnblogs.com/hhelibeb/p/8258915.html

 

SAP/非SAP系统的SAP SLT服务器的架构概述如下：

SAP系统和SAP HANA之间的SLT连接架构

SAP SLT Replication Server将所有元数据表定义从ABAP源系统转换为SAP HANA的元数据表定义。

对于SAP源，SLT连接具有以下功能：

  • 在复制表时，SAP SLT Replication Server将在源系统中创建日志表。
  • 读取引擎在SAP源系统中创建。
  • SAP SLT和SAP源系统之间的连接基于RFC连接。
  • SAP SLT和SAP HANA之间的连接基于DB连接。

与“SYSTEM”具有相同权限的数据库用户可以在SAP SLT和SAP HANA数据库之间创建连接。

SAP SLT Connection between SAP System and SAP HANA DATABASE

图  SAP SLT连接SAP系统和SAP HANA数据库

在SAP源系统中配置SLT服务器

首先，我们需要配置SAP SLT Replication Server以连接SAP源服务器和SAP HANA数据库。 事务代码LTR用于在SAP源服务器和SAP SLT之间创建连接。

步骤1）登录到SAP SLT服务器，并从SAP SLT复制服务器调用事务“LTR”。

系统会弹出一个Web Dynpro窗口，用于登陆到SAP SLT服务器。

输入用户名密码并登录。

 

会出现一个如下的弹出窗，用于配置：

点击“New”按钮，创建一个新的配置。

步骤2）在本步骤：

  1. 输入配置名和描述。
  2. 选择SAP系统作为源系统。
  3. 输入SAP系统的RFC连接（destination）。
  4. 输入用户名/密码/主机名和实例编号。
  5. 输入作业选项细节。
    • 数据传输任务编号
    • 计算任务编号
  6. 选择复制选项为实时。
  7. 一旦所有选项维护完毕，点击‘OK’来创建一个SLT的新SCHEMA。

现在已经添加并激活了名为“SLTECC”的新配置：

 

成功配置SAP SLT服务器后，SAP SLT服务器会自动为SAP HANA数据库创建数据库连接（当通过事务LTR创建新的配置时）。不需要手动创建它。

下一步，我们将数据从SAP源导入SAP HANA。

通过SLT将数据从SAP源导入至SAP HANA

一旦我们成功配置了SAP SLT服务器，SAP HANA数据库就会创建一个和SAP SLT中的配置同名的SCHEMA。

该SCHEMA包含以下对象：

  • 1 Schema- SLTECC.
  • 1 User– SLTECC.
  • 1 Privileges
  • 8 Tables：
    • DD02L (SAP Tables Name )
    • DD02T (SAP Table Texts)
    • RS_LOG_FILES
    • RS_MESSAGE
    • RS_ORDER
    • RS_ORDER_TEXT
    • RS_SCHEMA_MAP
    • RS_STATUS.
  • 4 Role -
    • SLTECC_DATA_PROV
    • SLTECC_DATA_POWER_USER
    • SLTECC_DATA_USER_ADMIN
    • SLTECC_DATA_SELECT
  • 2 Procedures
    • RS_GRANT_ACCESS
    • RS_REVOKE_ACCESS

所有配置完成后，现在我们从SAP ECC（ERP中央组件）中加载一个表。

 

步骤1）要将表从SAP ECC加载到SAP HANA数据库，请按照以下步骤：

  1. 从Quick View前往Data provisioning。
  2. 选择SAP HANA系统
  3. 点击完成按钮

 

程序会显示一个基于SLT的Table Data Provisioning屏幕。有5个用于data provisioning的选项：

Provision 选项
描述
Load (Full Load) 这是一个一次性事件，会开启从源系统的初始数据加载。
Replicate (Full Load + Delta Load) 会开启一个初始加载（如果之前没进行过的话），并且也会传输增量数据。会为每个表创建数据库触发器和日志表。
Stop Replication 为当前表停止复制过程。完全地移除触发器和日志表。
Suspend 暂停正在进行的表复制过程。数据库触发器不会从源系统移除，日志也将继续记录。相关信息会存储在源系统的日志表里。
Resume 重启暂停的表复制。

 

我们使用“加载选项”列表中的第一个选项来对表（LFBK）数据进行初始加载，将其从源系统加载到SAP HANA数据库。

操作步骤如下：

  1. 根据SAP SLT配置选择源和目标系统详细信息。
  2. 点击加载按钮，然后选择我们需要在SAP HANA中加载/复制的表（LFBK）。
  3. 表（LFBK）将被添加到数据加载管理部分，它的Action是"Load"，状态为"Scheduled"。

数据加载后，状态将变为“已执行”。 该表和数据将在“SLTECC” schema中创建。 

步骤3）通过schema “SLTECC”中的Data Preview检查表（LFBK）中的数据：

  1.  使用SAP HANA Studio登录SAP HANA数据库，并且选择SAP HANA系统HDB（HANAUSER）。
  2. 在表节点下选择表（LFBK）。
  3. 右键点击表（LFBK）选择打开Open data preview。
  4. 在Data Preview屏幕中将显示通过SLT处理加载的数据。

现在我们已经成功的将数据加载到表“LFBK”中。 我们可以在未来的建模中使用这个表。

非SAP系统和SAP HANA间的SLT连接

SAP SLT Replication Server将所有元数据表定义从非ABAP源系统转换为SAP HANA的元数据表定义。

对于非SAP的源，SLT连接具有以下功能：

  • 在复制表时，SAP SLT复制服务器将在源系统中创建日志表。  
  • 读取引擎在SAP SLT复制服务器中创建。  
  • SAP SLT和源系统/SAP HANA之间的连接基于数据库连接。

SAP SLT Connection between Non - SAP SLT Connection and SAP HANA System/DATABASE

图  SAP SLT连接非SAP系统和SAP HANA数据库

SAP SLT只能进行最简单的转换（比如考勤机数据的同步等），对于复杂的转换，我们需要其它的ETL工具，如SAP Data Services（SAP DS）。

 

英文原文：SLT (SAP Landscape Transformation Replication Server) in SAP HANA

参考阅读：Introduction To SAP Landscape Transformation (SLT)

　　　　　SAP DS (Data Services) in HANA

 　　　　  Hana Smart Data Integration – Architecture

  1. 1
  2. ...
  3. 10
  4. 11
  5. 12
  6. 13
  7. 14
  8. 15
  9. 16
  10. ...
  11. 19