SAP Graph自由研究1時間チャレンジSAP Graph自由研究1小时挑战

2 年 ago
科, 雅
1 minute

本文是作为2021年夏季自由研究的一部分而撰写的chillSAP文章。

首先

暑假已经结束了呢。
正在阅读这篇文章的各位，我想大家都是成年的绅士淑女吧，大家还记得小时候暑假做过什么样的自由研究吗？

不管内容如何，说到我自己，我想起了在上学的那天早晨编造研究，并在截止日期前拼命地在工作纸上乱写了些虚假的结果。

スクリーンショット 2021-08-29 20.24.25.png

虽然本来我想展示给大家看的是我在童年时培养起来的，在脑海中充当最佳研究室的能力，从假设验证到思考，一切尽在其中。但我忍住了这份渴望，在一个小时内进行了实机验证并尝试写下这篇文章。

以上、无论如何对于准备不足的强调。
我们立刻进入正题吧。

研究的起因

我对GraphQL这项技术一直很感兴趣，并且从去年的TechEd上听到了SAP Graph这个词后就一直心存好奇，因此选择了这个主题。

GraphQL是什么？

在讲解SAP Graph之前，我们先来简单介绍一下GraphQL。
GraphQL是一种用于Web API的查询语言，类似于SQL在Web API中的作用。（这么说是为了让大家更好理解概念）
它经常与传统的Restful API进行比较，有时也被称为下一代API。

RestfulAPI具有以下已克服弱点的特点：
– 无法在调用方控制获取的信息
– 对规范变更不敏感

スクリーンショット 2021-08-29 21.14.48.png

如果从调用者的应用程序中只需要姓名（name）这一项数据，尽管可以获取到许多其他信息，但除了姓名外的数据都会被认为是不必要的数据。也就是说，应用程序只能沉默地接收这些无用的信息。

如果需要超出所获得的信息的额外信息，例如，如果想知道出演作品中的名字是Darth Vader的是哪部，就需要执行另一个API，这会带来一些麻烦。
此外，如果API的端点名称规范发生更改，调用方也需要进行更改，这也会增加一些麻烦。

GraphQL是一种解决了这类问题的机制。

嗯？OData呢？ (Ń 呢？)

在解释GraphQL之前，如果你很聪明，可能已经意识到了以下内容。
在SAP的世界中（不仅限于SAP），有一个强大的盟友叫作OData。
调用OData时的描述可以定义如下。

  @Override
    protected void doPost(final HttpServletRequest request, final HttpServletResponse response)
            throws ServletException, IOException {

        final PurchaseOrder po = PurchaseOrder.builder()
                                .purchaseOrderType("NB")
                                .purchasingOrganization("organization")
                                .purchasingGroup("group")
                                .companyCode("1000")
                                .supplier("supplier")
                                .language("JA") 
                                .purchaseOrderItem(poi)
                                .build();

与之前介绍的一般的RestfulAPI不同，OData可以在调用方控制传递（接收）给API的信息量。我之前不经意间一直在使用它，但原来它是如此大的恩赐啊。（深深感慨）

然而，即使使用OData，也无法应对OData本身规范的变化。而且由于标准的OData通常是按照单个发货单进行构建的，所以如果要获取与特定发货单相关联的销售单据，就需要执行多个OData操作。

用GraphQL解决问题

在GraphQL中，我们可以指定所需的数据并发送请求。
以前面的例子为例，如果只想获取Darth Vader出演的作品，我们可以通过这样的查询来执行GraphQL的终端点。

query {
  person(personID:4) {
    name
    filmConnection {
      films {
         title
      }
    }
  }
}

这样的话，大的优点就是只需一次请求就可以获取所需信息。
此外，无需理解后台每个API的规范和终点，这也是一个重要特点。

就GraphQL而言，我已经写了下面的内容，但现在我们来讨论正题。

重新定义SAP Graph是什么？

image.png

尝试使用SAP Graph

由于时间限制，我只有1小时的时间，所以我将在SAP Graph上轻松执行API Business Hub，同时感谢SAP。 （这篇博客和内容几乎相同。）

スクリーンショット 2021-08-29 22.26.56.png
image.png
スクリーンショット 2021-08-29 22.32.08.png
スクリーンショット 2021-08-29 22.34.37.png

我本来想试试在一次执行中获取与该SalesQuote有关的更强大的Product信息等，但这将在以后的机会中再试一下。（时间不够）

考察和展望

最近在OSS的世界中，GraphQL正逐渐流行起来，我觉得在SAP的世界中也可能会变得流行起来。
再次感受到了OData的优点。
但是尽管它封装了复杂的SAP业务对象，标准的OData数量庞大，寻找起来还是很困难，希望在SAP Graph中能够更轻松一些，这是我的乐观想法。

请參考

如果没有的话，我就已经死了。真的非常感谢你。
https://dev.classmethod.jp/articles/reinvent19-graphql-modern-api/
https://qiita.com/NagaokaKenichi/items/a4991eee26e2f988c6ec
https://blogs.sap.com/2021/06/08/part-1-introduction-to-sap-graph/
https://blogs.sap.com/2021/06/15/part-2-hello-graph-write-your-first-sap-graph-application/
https://explore.graph.sap/docs/beta/overview

结束

中国传统文化非常注重教育与日常生活的规划，因此听到有人建议花更多时间，认真写代码进行验证，我感到非常抱歉。希望在来世，能成为一个更加计划性强、能够完成作业的孩子。暂时只希望大家能大致理解我传达的意思。这篇文章虽然稍显随意，但我想通过无声的压力来结束它。

✖
广告
将在 10 秒后关闭
bannerAds