添加一个新的Data source：

选择之前配置的指向northwind OData的Destination，

注意，在Neo和CloudFoundry环境里都要创建同名Destination才行。在Neo里创建的Destination还需要带上三个额外的properties，而CloudFoundry里的Destination则不需要。

输入/V2/Northwind/Northwind.svc，点击Test按钮：

确保该OData的metadata能够正常显示，点击Next按钮。

将其用作缺省模型：

点击Run按钮进行测试：

得到结果：

我写了一个report：

DATA:     ls_kw_business_object TYPE sibflporb,
          lv_relation_name      TYPE crmt_relation_name,
          lt_loios              TYPE skwf_ios,
          lt_phios              TYPE skwf_ios,
          ls_phios              TYPE skwf_io,
          lt_prop_result        TYPE crm_kw_propst,
          ls_prop_result        TYPE crm_kw_props.

  ls_kw_business_object-instid = 'F8D9601DAFD6674F94EA19C1CDBE37DA'.
  ls_kw_business_object-catid = 'BO'.
  ls_kw_business_object-typeid = 'BUS1006'.

CALL METHOD cl_crm_documents=>get_info
      EXPORTING
        business_object       = ls_kw_business_object
        newest_only           = 'X'
      IMPORTING
        ios_properties_result = lt_prop_result
        loios                 = lt_loios
        phios                 = lt_phios.

我解决问题的思路：

首先在UI上debug打开contact detail page的时候，contact上面的attachment是怎样从DB里面读出来并且显示在UI上的。
可以参考product的debug：

这个方法的输入是一个bol entity，输出就是ui上的attachment。所以我通过观察lr_entity里面的attribute就能知道为了读取document，需要哪些输入参数。

这里可以发现instID必须传BP的guid进去。

那下一个问题就是如何在你的代码上下文里拿到BP guid呢？我们只知道contact的id。
如果你观察BP的model，你会发现BuilHeader有三个association都能到另一个root object BuilContactPerson,

而BuilContactPerson也有association到BuilHeader。

如果你在UI上修改account ID = 400646的description，你会发现对应的contact ID = 400646的description也自动变了。所以这里的contact和account对应DB（BUT000）里面是同一条entry，BP的guid也就是contact的GUID。

所以你直接用contact的guid作为api的输入就可以了。