SAP 和连接：糟糕的管道是否会影响您的体验？
你知道吗 98 个最有价值品牌中的 100% 是 SAP 客户吗？ 或者 SAP 系统几乎触及 占全球交易收入的77%?
SAP Suite 为 180 个国家/地区超过 XNUMX 万活跃客户提供服务，几乎没有任何垂直领域是不可以利用的。 制造、物流、金融、销售、供应链到物联网， cloud，以及介于两者之间的所有其他内容 - 只要你能想到的。
为了抵御竞争对手挤入不断扩大的市场竞争缝隙，并考虑到快速的技术进步作为可预见的未来的背景，SAP 依靠创新来保持领先地位。
不，我不是在做一般性的声明。 SAP 投资超过 4.2 亿欧元 2019年在研发领域。你现在相信我了吗？
向 SAP S4 HANA 问好
对于不知道的读者，HANA 代表高性能分析设备。 请允许我转sla你自己。
除了现有 SAP 工具之外，SAP HANA 平台还为新型实时分析和应用程序铺平了道路。 它利用内存数据库，该数据库比在旋转介质上运行的任何传统数据库快几个数量级，旨在在创建大量数据时立即对其进行分析，从而无需复杂的数据管理层和存储。
它的USP？ 它从众多端点注入大量数据，包括但不限于：
- 来自网站的 UX/UI 数据
- 来自移动劳动力的数据
- 物联网设备和机器学习单元
- NetWeaver 堆栈不断与 HANA 数据库来回通信。
包括多个其他非传统数据源，SAP HANA 允许用户以接近零延迟的方式即时访问大量结构化和非结构化数据，使他们能够在需要时即时、按需查询数据。
糟糕的管道会破坏体验吗？
你看到你家顶上的那个水箱了吗？ 理想情况下，它能容纳足够的水来舒适地处理您几天的日常琐事。 如果您的管道系统不符合标准，那又有多好呢？ 如果水箱里的水不流入厨房水龙头，那么它就没有任何用处。 SAP 和网络连接的情况也不例外。
SAP 数据库是水箱，网络连接是管道系统。
当连接要求很简单时，传统网络做得很好。 当工作场所有明确的边界时，SAP 等应用程序通常留在私人数据中心。
但随后出现了多种趋势，用户开始扩散。 不要忘记，新冠肺炎灾难只会加剧局势。 用户对数据的依赖在几年内也增加了四倍。
例如，考虑物联网技术。 这不仅会产生大量数据，而且还需要与众多应用程序共享。
SAP 也是如此。 用户几乎可以在任何地方使用他们的 SAP 应用程序。 因此，即使 SAP HANA 也需要强大的网络来促进多个站点（尤其是远程站点）的数据复制。 还有安全方面的问题，但我们改天再讲这个故事。
将会是什么？
到 2023 年，近 80% 的 SAP 用户将全部或部分迁移到 cloud。 如果您正在阅读此博客，那么您的组织很可能已经在考虑它。 （如果他们还没有切换）。 那么，您打算如何修复该管道系统？
公共互联网？
除了您的业务流量将与猫和狗的视频争夺带宽这一事实之外，还有多个其他原因导致这不是一个好主意。
互联网是延迟、数据包丢失和抖动的滋生地。 它的英文意思是它无法跟上 SAP Web 应用程序发送的大量文件传输和大量数据包。 当不一致的延迟出现时，由于网络拥塞和网络对等策略，它会破坏吞吐量，即使是在较小的距离内。
结果？ 数据丢失、传输速度变慢、连接超时以及 SAP Web 应用程序性能平庸
MPLS?
不仅具有刚性的性质 MPLS 违背 SAP HANA 背后的创始理念，即分散 SAP 的存在并使其随时随地可用； 对于一个严重依赖不同操作单位和远程工作人员之间数据来回移动的工具来说，很难与中心和辐射架构一起工作。 MPLS.
这种架构无意中使数据回程淹没了网络，导致流量“长号”，导致路由效率低下，增加了用户与其应用程序之间的距离。 这除了 MPLS 灵活性和可扩展性限制。
认为 Cloud-第一
将您的分支机构连接到 SAP HEC 并不困难。 如果有一种简单的方法可以直接连接到所有 SAP 实例以及在所有 SAP 实例之间进行连接，而无需 MPLS、复杂的设备，还是需要对等互连？
就像哈娜一样， Aryaka是， Cloud-第一 WAN 是从头开始建造的 cloud-首要原则。 它允许用户在 30 毫秒或更短的时间内从世界任何地方安全地连接到他们的 SAP HEC 实例。
你 wan想更多地了解我们如何做我们所做的事情吗？ 阅读我们的 SAP HANA 解决方案简介 了解更多有关情报的信息 Aryaka 与您的 SAP 应用程序绑定——尤其是 S4 HANA。
你也可以学 我们如何帮助一家美国特种化学品制造企业erp上升 拥有 5,000 多名员工，他们的 SAP Suite 性能极其糟糕。
Wan对 SAP 格局有深入的了解吗？ 看看我们的 关于优化 SAP HANA 性能的网络研讨会 Aryaka，“ Cloud-第一 WAN.
需要移动得更快吗？ 请求免费演示.
关于作者
