关于abap:对于-basis-管理员来说ABAP-Platform-意味着什么

59次阅读

共计 3355 个字符,预计需要花费 9 分钟才能阅读完成。

依据 note 2620910 – SAP S/4HANA 1511, 1610, 1709, 1809 and SAP BW/4HANA 1.0, 2.0: Recommended and released Application Server Platforms:

从内核 773(ABAP 平台 1809 + HANA 2.0)开始,ABAP Platform 删除了对某些操作系统的反对。

这些放弃反对的操作系统列表:

依据客户的反馈,咱们看到大多数客户抉择 Linux x86_64 作为他们运行 SAP 零碎的首选平台,只管 Windows 和 AIX 依然受反对并且是齐全无效的选项。

革除过期的 SAP Profile 参数

如果您作为 SAP 根底管理员工作了一段时间,您可能晓得 SAP 一直地引入、更改或删除配置文件参数。因为各种 SAP 产品和版本应用雷同的 SAP 内核,因而参数中的这些频繁更改必须尽可能兼容,以防止产生不心愿的附带影响。

然而 SAP ABAP Platform 1809/Kernel 7.7x 不同,它突破了与旧内核和 SAP Netweaver 版本的向下兼容性。这是 SAP 清理所有这些已存在多年的历史和过期参数的绝佳机会。

有 2 个次要区域已被清理和 / 或优化:

  • ABAP VMC
  • ICM 和 SAP Web Dispatcher

虚拟机容器(简称 VM 容器或 VMC)是集成到 SAP Web AS ABAP 中的一个组件,它使合乎 Java 规范 J2SE 1.4 的 Java 性能可能在 AS ABAP 中执行。

依据 SAP Note 2560708 的阐明,S/4 HANA 的内核自 1809 年起不反对 VMC。因而,有很多 VMC 和 JVM 参数不再受反对,必须从 SAP 实例配置文件中手动删除。

ICM 和 SAP Web Dispatcher 参数也有重要变动,许多已升值和过期的参数也已被删除。您能够在 SAP Note 2593926 – Incompatible ICM / SAP Web Dispatcher Parameter Changes in 773 – Deprecated, Obsolete and Changed Parameters 中找到所有详细信息。

指标再次是删除过期的参数并简化 ICM/Web Dispatcher 组件的治理,这些组件当初与 FIORI 一起成为 SAP 零碎的要害组件。

新的保护模型和运行级别

在我看来,这是为 SAP S/4HANA Cloud 引入的一项乏味性能,但也可用于 SAP S/4HANA“Any-premise”版本,因为这些 SAP S/4HANA 产品共享雷同的代码。

有两个新概念:运行级别和保护期。

事务 SMAINTENANCE 容许您定义保护期:

  • 普通用户将无奈登录,只有具备非凡平安配置文件的系统管理员能力连贯(事务 SECPOL)
  • 只会执行治理批处理作业(所有其余作业将被搁置)

有不同的运行级别,从运行级别 0(零碎在失常操作中运行)到运行级别 100(零碎处于保护中),容许以更灵便的形式定义 SAP 零碎的状态以及依据运行级别容许或不容许哪些操作:

在 SAP S/4HANA 外部部署零碎上激活保护模式后,只有 SAP 系统管理员(具备正确的平安配置文件)能力连贯:

新的客户端复制工具

通过多年没有重大变动,终于有了新版本的工具来创立、删除和治理 SAP 客户端。

次要的变动能够概括为:

  • 因为工具应用 SAP HANA 优化,速度进步了 10 倍。
  • 近程客户端复制速度进步 5 倍
  • 无需用户 SAP* 即可进行客户端复制,无需重新启动零碎
  • 在隔离环境中运行,失败的退出和存储在日志中的表
  • 基于表格的 UI,具备附加信息和更好的持久性;日志不同局部的多个选项卡

下表摘自 SAP 官网帮忙,形容了 ABAP 平台中可用的新事务和工作列表:

例如,当初您能够预计一个 SAP 客户端的大小,并应用新的 SCC_CLIENT_SIZE 事务替换旧报告,具体理解哪些表占用更多空间:

内存配额和内存耗费的软转储

当一个过程耗费了他所有的内存配额(扩大内存 + HEAP 内存)时,会生成一个 ABAP 短转储(例如 TSV__NEW_PAGE_ALLOC_FAILED)并勾销该过程作为一种爱护机制,以防止整个零碎解体。

到目前为止,当过程耗费过多内存时,不可能失去“晚期正告”。惟一可用的选项是被动监控,查看哪些过程耗费了更多内存并尝试在为时已晚之前做出反馈。

从内核 7.77 开始,当过程耗费的内存配额超过用户定义的百分比时,能够生成软转储:

  • ABAP 处理器写入“coreinfo”文件
  • 有一个过程会定期读取这些外围信息并将转储信息保留在 ST22 中。
  • 转储 SESSIONMEM_QUOTA_WARNING 信息在 ST22 中可见

经典的 ABAP 短转储和新的软转储之间的次要区别在于过程不会被勾销,但系统管理员能够对正告做出反馈并决定什么是正确的操作:

正如您在后面的示例中看到的,只管内存配额约为 6GB,但会话内存正告配置为 3.6GB

我确信对系统管理员十分有用的另一个乏味性能是容许更灵便地配置内存配额的选项。

默认内存配额实用于所有用户,默认状况下没有人能够耗费更多内存。然而,通过配额扩大,咱们能够授予特定用户(必须在事务 SMEM_USEREX 中注册)不同的配额,容许他们生产更多或更少)

能够应用以下参数管制配额扩大和配额正告:

系统管理员必须通过事务 SMEM_USEREX 注册用户能力容许他们应用新的配额豁免机制:

ABAP 推送通道 (ABAP push channel) 和 WebSockets

另一个重大改良属于 ABAP 连贯畛域,是 RFC 的互联网反对。新的 WebSocket RFC 容许通过 HTTP/WebSocket 进行 RFC 调用,并且始终通过 SSL 传输以确保安全性。跨业务网络的 RFC 连贯不再须要 VPN 隧道。

WebSocket RFC 应用规范的 HTTP 基础设施、反向代理、HTTP 路由器等,而不是专有的 SAP 路由器。

大多数 ABAP 应用程序应用轮询技术来实现事件驱动的通信。为了将事件从 ABAP 后端推送到基于浏览器的用户代理(如 SAPUI5、Web Dynpro、Business Server Pages (BSP) 或 WebGUI),常常应用以多秒为距离的轮询。这是一种相当耗费系统资源的技术。在 SAPGUI 中,定时器控件通常用于检测 ABAP 后端系统中的事件。ABAP Channels 技术的指标是通过基于公布 - 订阅基础设施和 ABAP 中的 WebSockets 的推送告诉来取代这种基于轮询技术的低效事件。

ABAP 通道基础架构随 SAP NetWeaver AS ABAP 7.40 反对包 2 (SP2) 一起提供,用于简略的测试和原型设计,并随 7.40 反对包 5 (SP5) 一起公布。
ABAP 通道的根本思维是对基于事件驱动架构的交互和合作场景的原生反对。ABAP 通道的范畴包含以下通信通道:

借助 WebSocket RFC,RFC 最终与古代云和互联网架构兼容:

  • 应用规范的 HTTP 基础设施:反向代理、HTTP 路由器等……不再是 SAPRouter。
  • 跨业务网络的 RFC 连贯不再须要 VPN 隧道
  • 反对规范的 HTTP 身份验证机制,如 SAML 不记名令牌、Oauth 等……
  • 兼容经典 RFC(应用雷同的 ABAP 语句 CALL FUNCTION)

限度:

RFC 回调和调用功能模块,可关上基于 SAP GUI 的用户界面。

用户治理——技术用户与商业用户

到目前为止,“技术用户”(例如系统管理员、接口和批处理作业的用户等)和“业务用户”(在 SAP 外部执行业务流程的人)的定义形式完全相同,通过事务 SU01 和它们的次要区别在于 SAP 受权和登录详细信息。

从 SAP S/4HANA 1909 开始,为业务用户提供了一种新的身份模型。

业务用户是在零碎中由业务搭档和用户链接代表的自然人。该业务用户将在业务流程(采购员、销售代表等)的上下文中与软件进行交互

所以当初,在事务 SU01 中,技术用户和业务用户之间有显著的区别:

技术用户:没有关联的 BP,也没有 SU01 中的“地址”选项卡。
业务用户:用户 id 与对应的 BP 关联,局部细节无奈通过 SU01 更改

对于业务用户,局部业务用户数据已集成在 BP 中,无奈再在 SU01 中编辑:

  • 集体数据来源于相应的业务合作伙伴
  • 工作核心数据来源于相应业务搭档的工作地址
  • SU01 中的通信数据来源于对应业务搭档的工作地址
  • SU01 中的 ORGANIZATION_NAME 和 LOCATION 来源于对应 BP 的公司地址

更多 Jerry 的原创文章,尽在:” 汪子熙 ”:

正文完
 0