技术文章
集中传输命名标准-即时服务集成
本文是集中传输命名标准系列文章的第四篇。
参见博客文章:
集中运输命名标准 |
上下文
由于集中式传输命名标准解决方案已经发展并推广到更多的开发系统,因此要求验证以下段3
<项目/区域>:<项目/释放/ Sprint >: < Change_Ref >: <描述>:<三角洲没有>
例如标出:R1:TASK000000000001描述:1:示例
计划是根据前缀向Service Now或Azure DevOps验证这个数字,因为Service Now是优先级,所以我所需要做的就是从SAP调用一个预定义的API。应该不会有太多问题吧?!
该表扬就表扬
首先,我在验证运输标题中提供的参考编号的过程中获得的大部分知识归结为以下两项:
- 〇维基使用OAuth 2.0客户端API访问Microsoft Azure
- 和SAP代码样本在Github上abap-alv-google-upload-sheet
这些帮助我找到了正确的方向,并完成了90%的谜题。非常感谢约阿希姆Doersam而且塞巴斯蒂安Machhausen分别用于编写wiki和提供代码。如果您需要通过OAUTH2连接到外部系统,这些应该是您的第一个调用端口。(此外,作为本博客的背景信息,快速浏览一下也会非常有用)。
不幸的是,通常情况下,剩下的10%的解决方案似乎花了很长时间,这就是我希望在这篇博文中关注的问题。因此,这不是配置和代码集的详尽列表,上面的项目已经提供了,下面的差异是由于客户端凭证我必须使用的流程。
OAUTH 2.0客户端流程
由于从未接触过OAUTH,这对我来说是一个棘手的问题,让我学会了相信比我更了解的人!我被告知好几次我必须使用客户端凭证心流而不是授权批准但由于我并不真正理解其中的区别,再加上我已经在后者方面取得了很大进展,所以我继续前进。后来,当我对客户凭证流程的理解终于有所改变时,我意识到我应该听取那些更了解的人的意见。事后诸葛亮是件好事……
我所面临的问题的核心是,我所遵循的文档和提供的代码示例是用于授权授予流的,我需要将其转换为客户端凭据流。事实证明,这并不难——只要你知道怎么做。
客户端凭证流将强制执行以下流程:
- 来自SAP(客户端应用程序)的请求转到Azure活动目录
- 提供给SAP的不记名令牌
- 然后提供不记名令牌对“立即服务”进行身份验证
- 获准查阅及适当检索所要求的资料
图1 -客户端凭证流
这个流的关键在于不需要人工交互,并且令牌过期后可以自动更新。对于授权授予流,我最初必须通过OA2C_GRANT事务手动设置(根据wiki)。同时还请求了一个刷新令牌(以确保我不会不断地手动重新验证),并且根据OA2C_GRANT提供并接受了ok)。这在初始授权的第一个小时内工作得非常好,但一旦过期并请求刷新令牌,它就再也不起作用了。Service Now期待一个客户凭证流,而我还没有设置它,因此我被一个部分有效的解决方案困住了,并且在我承认失败之前进行了太长时间的进展。因此,我认为提供一些让我感到困惑的步骤是有用的,以防它们对面临类似情况的其他人有用。
在使用OAUTH2(使用SAP作为客户端)进行身份验证的链条中有相当多的环节,wiki将它们逐一进行。下面,我将添加为了使客户端凭据流正常工作而需要进行的更改。
授权对象
在维基中提到过,但在给自己提供了一个测试配置文件后,我后来忘记了为其他用户测试——后来进行了大量调试,我才记起来。因此我要放一个顶部!
在通过下面的create_oauth_client()方法创建oauth2客户端时,有一个检查:
图2 -授权要求
确保将以下内容添加到需要调用代码的所有用户id中。
- S_OA2C_USE
- PROFILE = '您的配置文件名称,即ZSERVICENOW* '
- Actvt = 16
SSL证书
目标应用程序(在本例中是Service Now)需要受到信任,因此需要在STRUST中上传证书。根据您的公司设置,Basis可能必须为您执行此操作。如果你已经吸毒了ABAPGit(如果没有的话,我强烈建议),该过程与添加在Github证书中发现的相同在这里.
巴迪
维基中提到了两个BAdI。
OA2C_CONFIG_EXTENSION_BADI_DEF和OA2C_SPECIFICS_BADI_DEF
当我记录这一点时,我现在想知道OA2C_CONFIG_EXTENSION_BADI_DEF是否实际上是必需的,因为它只引用了授权代码授予和SAML 2.0授予令牌——我的实现不需要这两个。我将审查这一点,并删除后,如果适用。
OA2C_SPECIFICS_BADI_DEF
遵循维基百科,但确保在最后一行添加。稍后,您将看到这在OA2C_CONFIG事务中启用选项的位置。
图3 - oa2c_specificbadi
客户端配置文件
需要三个客户端概要文件,它们将与稍后提到的AAD应用程序保持一致。(假设您已经根据wiki在OA2C_TYPES中设置了ZSERVICENOE)。
图4 -客户端概要
作用域
只需要一个作用域,这是由Service Now API团队提供的,并添加到作用域选项卡上的客户端配置文件中。范围也有详细说明在这里.
Azure活动目录(AAD)配置
然后我必须在AAD中创建3个独立的“应用程序”。以匹配上面的客户配置文件。这些是非常基本的,纯粹用于提供令牌。关于设置这些的信息可以在这里找到在这里.客户端id、客户端秘密和提供的端点,然后在如下所示的OA2C_CONFIG事务中使用。
图8解释了这些字段以黄色突出显示的原因。
图5 - OA2C_CONFIG
类
下面的UML图显示了描述类的层次结构塞巴斯蒂安Machhausen在他的样本访问谷歌表。
图6 - Service Now类的UML
我实现这些方法就像一个复制/粘贴练习,对上面突出显示的方法做了微小但重要的更改。它被输入到下面的接口中,有3种不同类型的流执行。
图7 - IF_OAUTH2_CLIENT
突出显示的代码是拼图的最后一块。我不明白为什么流会失败,直到我发现它调用的是execute_refresh_flow方法,而不是execute_cc_flow。加上代码需要使用报头字段,但OA2C_CONFIG指定的表单字段。(我在实验中犯的错误)。
因此,在下面的方法中,我们可以看到头字段和execute_cc_flow方法与图5中所示的OA2C_CONFIG是同步的。
图8 -设置令牌
结果
所以最后它都工作了,我现在对服务任务和事件都进行了验证。在下面的图9中,我尝试释放传输任务,但由于引用号处于不正确的状态,因此被阻止。
图9 -错误消息
我承认这不是最漂亮的弹出窗口,但确实管用。我目前正在使用SAP标准POPUP_WITH_TABLE_DISPLAY FM,因为它存在于7.31以上的所有卫星开发系统上,因此不需要任何额外的开发。我更喜欢一个标准的HTML版本,它肯定会看起来更好,并提供更好的灵活性-欢迎任何建议!
总结
因此,标准再次变得更加严格,并且根据系统中的原因对每个传输进行审计变得更加容易,从而节省了开发负责人在电子表格上搜索的大量时间。
当然,我在这个特别的练习中学到了很多东西,这对我验证Azure DevOps也很有帮助——我是通过SAP还是AWS来验证还没有决定。首先,一旦我完成了测试,我需要将这段代码从Feature分支移到Main分支。
非常需要一个……以上步骤清晰明了
谢谢年代Abinath.我很高兴你觉得它有用。
谢谢你提供的有用信息!