嗨-我要伸出脖子说，不管"最佳"方法是什么，它将涉及服务器端的一些逻辑，以便按顺序生成"下一个" ID，同时避免冲突和 如果您也要部署为云本机应用程序，则在分布式环境中工作时也要足够快。 换句话说，这使我记得R/3 ABAP堆栈体系结构中的数字范围是如何工作的，以及其中涉及的内容。

很可能您需要在数据库级别上进行某种持久化才能使其正常工作。

UUID可能很丑，但它们以不同的方式也很漂亮；-）

所以这是否意味着目前没有标准的方法 ？ 这至少是计划好的吗？ 许多业务应用程序都要求为对象提供一些用户友好的ID。

我也不理解您的评论。 当然，它需要在后端完成。 我猜想几乎每个关系数据库都支持自动增量。 至少对于SQLite，Postgres和HANA似乎确实如此。

如果您具有ID作为UUID，则无需显式传递ID。 CAP将生成ID作为新的GUID。

示例：//注意sap/cds/common的cuid方面会自动添加UUID

命名空间com.sap.orderprocess.app;

使用'@ sap/cds/common'中的{cuid}；
entity SalesOrderFlow：cuid {

SOID：字符串；

WFID：字符串；

状态：字符串；

}

HTTP POST

/order-workflow/SOFlow

-标题

Content-Type application/json

-body

{" SOID"：" S00002"，" WFID"：" W12346"，" Status"："已启动"}

响应：

{

" @ odata.context"：" $ metadata#SOFlow/$ entity"，

" ID"：" acb8765a-3239-4d32-b5ec-acbb7a4133e4"，

" SOID"：" S00002"，

" WFID"：" W12346"，

"状态"："开始"

}