在 SAP Gateway 项目里，$filter几乎每天都会碰到。Fiori 列表页输入销售组织，前端发出$filter=SalesOrganization eq '1000'，DPC_EXT 收到条件，转换成 Open SQL，再从数据库读取数据，这条链路大家都很熟。真正容易把问题搞复杂的，是过滤条件不再停留在当前 Entity Type 的简单属性上，而是开始沿着 Navigation Property 往关联实体里走。例如销售订单列表不只是按照订单自身字段筛选，而是希望按照关联对象的属性筛选。URL 可能变成下面这样。SalesOrder?$filter=TwinEntity eq 'null' SalesOrder?$filter=TwinEntity/property eq 'xyz' SalesOrders?$filter=EditState ne 2 or (EditState eq 2 and TwinEntity eq null) SalesOrder?$filter=TwinEntity/next_navigation/...last_navigation eq 'null'SAP Gateway Foundation 对这种$filter是有框架级支持的。关键并不在于 Gateway 简单地保存了一段$filter字符串，而在于 Gateway 会解析过滤表达式，并在 Backend System 中建立一棵 Filter Expr
在 SAP Gateway 项目里，$filter几乎每天都会碰到。Fiori 列表页输入销售组织，前端发出$filter=SalesOrganization eq '1000'，DPC_EXT 收到条件，转换成 Open SQL，再从数据库读取数据，这条链路大家都很熟。真正容易把问题搞复杂的，是过滤条件不再停留在当前 Entity Type 的简单属性上，而是开始沿着 Navigation Property 往关联实体里走。例如销售订单列表不只是按照订单自身字段筛选，而是希望按照关联对象的属性筛选。URL 可能变成下面这样。SalesOrder?$filter=TwinEntity eq 'null' SalesOrder?$filter=TwinEntity/property eq 'xyz' SalesOrders?$filter=EditState ne 2 or (EditState eq 2 and TwinEntity eq null) SalesOrder?$filter=TwinEntity/next_navigation/...last_navigation eq 'null'SAP Gateway Foundation 对这种$filter是有框架级支持的。关键并不在于 Gateway 简单地保存了一段$filter字符串，而在于 Gateway 会解析过滤表达式，并在 Backend System 中建立一棵 Filter Expr
)
