APF model和Fiori launchpad tile的同步问题

If I create a new representation in APF modeler:

Execute the configuration in APF modeler, I could see the new representation:

But why will the changes affect the app in Fiori Launchpad Tile? If I go to the tile and run the app:

I could see the new representation too:

Usually I need to update the Fiori Project code manually and commit to project portal for review and central build, then update to BSP application.
I thought now APF modeler is automatically connected to the Fiori Project and trigger an automatic upload, but it’s not.
To my understanding, the tile is using the Semantic Object/Actions to link to a certain Target Mapping, and Target Mapping is linked to a certain BSP application, only when BSP app is updated, the tile will be updated too.

The reason for this phenomenon is because of this:

There’s now a APF drill down option in the Smart Business Tile configuration, could also select a specific APF configuration;

but why is drill down has such a effect?

No, I double checked, the reason is not simply because of this. I checked my tile, I’m using the old tile, not the new one Sean created, the old one didn’t have this configuration.

对比了一下读取Representation时的请求和新增Representation时的请求：
在Tile App中读取的时候：

在APF Modeler中新增Representation保存的时候：

URL是一样的，是否可以认为是读取了同一个后台文件？但是去后台上怎么找这个文件呢？在SICF中查不到这个Service:

APF的configuration都是以文件的形式存在LREP里的，这个LREP是一个repository，里面的内容实际还是存在database table里的。
你在UXT/928里执行这个report ZLREP_READ试试。

*&---------------------------------------------------------------------*
*& Report ZLREP_READ
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zlrep_read.

DATA: lo_lrep_api          TYPE REF TO /uif/cl_lrep_api,
      lv_layer_type_result TYPE /uif/lrep_layer_type,
      ls_file_id           TYPE /uif/lrep_file_id,
      ls_admin             TYPE /uif/lrep_admin,
      lv_content           TYPE /uif/lrep_content,
      lv_found             TYPE boole_d VALUE abap_false,
      lv_layer_type        TYPE /uif/lrep_layer_type.

ls_file_id-name = '14638100006405115631366280507841'.
ls_file_id-namespace = 'sap/apf/dt/14638099251984376548304796678006/'.
ls_file_id-type = 'apfconfiguration'.
CREATE OBJECT lo_lrep_api.
lo_lrep_api->read_rt_content( EXPORTING is_file_id    = ls_file_id
                                                  iv_layer_type = lv_layer_type
                                                  iv_admin      = abap_true
                                        IMPORTING ev_found      = lv_found
                                                  ev_content    = lv_content
                                                  ev_layer_type = lv_layer_type_result
                                                  es_admin      = ls_admin ).

APF在runtime的时候分为了vendor layer和customer layer. 在runtime的时候，如果用户在smart business tile的设置中设置了Configuration，或者在Target Mapping中配置了Configuration ID，APF在runtime的时候都会在vendor layer直接去APF modeler中读取app，不通过BSP application去取，在Tile中也一样。
这是为了方便在开发系统上进行测试，也是方便客户通过在APF modeler中import程序之后进行修改。只有在程序deploy的时候，是通过自定义的Semantic Object/Action去获取的BSP application。
也就是说在smart business tile中如果作的是如下设置：

没有在Drill Down中选择APF，但是只要在target mapping中设置了Configuration ID，那么APF runtime的时候都会去读APF modeler中的设置。

但是很奇怪的是这和UXT重开之前的behavior是不一样的，我很确定在之前我在target mapping中也设置了configuration ID，但是smart business tile是去取的BSP的application。
所以针对这一点，我会去Target Mapping中删除掉configuration ID，然后试试Tile是不是可以直接去取BSP app。原因在target mapping的设置里，只要target mapping里设置了configuration id，那么最终就会直接根据config id去lrep拿而忽略bsp的。换言之，在SSB里tile里的设置config其实是没有用的。

要获取更多Jerry的原创文章，请关注公众号"汪子熙":