VDM适用于一项Odata服务,不适用于另一项Odata服务

时间:2019-03-26 09:20:41

标签: s4sdk

我试图使用S4 SDK连接到S / 4 HANA Odata服务。 S / 4团队为我们提供了两项服务。在相同的目的地,使用相似的代码,与一种服务的集成有效,而与另一种服务的集成则无效。

最诚挚的问候

Y

使用的代码是

final List<User> userList = new DefaultS4cUserMetadataService()
        .getAllUser()
        .select(
            User.USER, 
            User.BUSINESS_UNIT,
            User.COMPANY,
            User.COST_CENTER) 
        .filter(
            User.TIME_STAMP.ge(LocalDateTime.of(1970, Month.JANUARY, 1, 0, 0, 0)))
        .orderBy(User.USER, Order.ASC)
        .execute(configContext);
return userList;

我也调用了不带选择和过滤器的程序,但它得到了相同的错误:代码为500的内部错误。但是对于获得业务角色的服务而言,它却起作用。用于获得业务角色的代码是

final List<IAGBusinessRoleView> businessRoleList =
        new DefaultS4cBusinessRoleMetadataService()
            .getAllIAGBusinessRoleView()
            .select(
                IAGBusinessRoleView.BUS_ROLE_ID,
                IAGBusinessRoleView.USER_NAME,
                IAGBusinessRoleView.UUID,
                IAGBusinessRoleView.DESCRIPTION,
                IAGBusinessRoleView.TIME_STAMP,
                IAGBusinessRoleView.LANGUAGE_KEY)
            .orderBy(IAGBusinessRoleView.BUS_ROLE_ID, Order.ASC)
            .execute(configContext);
return businessRoleList;

它使用了相同的目的地。

1 个答案:

答案 0 :(得分:6)

在查看了问题之后,我们发现后台的S / 4HANA服务没有达到预期的效果。

进一步的参考资料中,我将介绍一种了解OData VDM幕后发生情况的方法。


使HTTP调用可见

要查看OData VDM执行的HTTP请求,我们将构建一个测试,该测试设置并拆除将请求发送到的本地模拟服务器。为此,我们使用Wiremock

先决条件

唯一的前提条件是下载要测试的服务的元数据文件。您可以使用目标系统的$metadata端点来获取此信息。

对于PhysicalInventoryDocumentService,它可能看起来像这样:

https://myserver.com/sap/opu/odata/sap/API_PHYSICAL_INVENTORY_DOC_SRV/$metadata

可以在您的服务的服务界面中找到该路径以进行检查。在此示例中,您可以在PhysicalInventoryDocumentService中找到它:

public interface PhysicalInventoryDocumentService
{
    // ...
    String DEFAULT_SERVICE_PATH = "/sap/opu/odata/sap/API_PHYSICAL_INVENTORY_DOC_SRV";
    // ...
}

设置测试

在测试目录(在本示例中为SomeTest)内创建一个普通的测试类。

将在上一步中下载的元数据文件移动到测试后命名的子目录中的test-resources目录中。因此,在我的示例中,我具有以下结构:src->test->resources->SomeTest->API_PHYSICAL_INVENTORY_DOC_SRV.edmx

在测试班级中,在班级上添加以下几行:

private static final MockUtil mockUtil = new MockUtil();
@Rule
public final WireMockRule erpServer = mockUtil.mockErpServer();

对于每种测试方法,这将设置一个模拟服务器,执行代码,最后再次关闭服务器。您可以在S / 4HANA Cloud SDK的MockUtil库中找到com.sap.cloud.s4hana:testutil

然后添加以下setUp方法:

@Before
public void setUp()
{
    final String metadataAsString =
        TestUtil.readResourceFile(SomeTest.class, "API_PHYSICAL_INVENTORY_DOC_SRV.edmx");
    stubFor(
        get(urlEqualTo("/sap/opu/odata/sap/API_PHYSICAL_INVENTORY_DOC_SRV/$metadata"))
            .willReturn(okXml(metadataAsString)));
}

您需要在其中将类名称,元数据文件名和url替换为服务中的一个。 这些行将告诉模拟服务器如果在给定URL上收到请求,则返回元数据。 由于这是每个OData VDM调用的第一步,因此需要对其进行模拟。

现在创建如下的测试方法:

@Test
public void testSomething()
    throws ODataException
{
    new DefaultPhysicalInventoryDocumentService().getAllPhysInventoryDocItem().execute();
}

您需要将此处的呼叫替换为您要实际测试/验证的呼叫。

运行测试

如果运行测试,您将收到一条包含下表的错误消息:

[qtp1038820134-18] ERROR WireMock - 
                                               Request was not matched
                                               =======================

-----------------------------------------------------------------------------------------------------------------------
| Closest stub                                             | Request                                                  |
-----------------------------------------------------------------------------------------------------------------------
                                                           |
GET                                                        | GET
/sap/opu/odata/sap/API_PHYSICAL_INVENTORY_DOC_SRV/$metada  | /sap/opu/odata/sap/API_PHYSICAL_INVENTORY_DOC_SRV/A_PhysI<<<<< URL does not match
ta                                                         | nventoryDocItem?$format=json
                                                           |
                                                           |
-----------------------------------------------------------------------------------------------------------------------

如果服务器收到未模拟的请求,这是通常的Wiremock响应。在左侧,您可以看到最接近的模拟请求,而在右侧,您可以看到实际收到的请求。

您现在可以通过Postman或浏览器使用右侧的请求,并直接验证行为。