Week3
Unit 1: The Enhanced Business Scenario
本节介绍了将要练习的demo的业务场景，在前两周成果的基础上，也就是只读列表，也可以说是报表APP基础上启用了事务能力，也就是CURD以及自定义业务功能的能力，从创建基本的behavior definition，然后behavior definition projection，同时介绍了EML（Entity Manipulate Language），使用EML实现实际的业务逻辑，然后扩展到了validations,determinations,以及actions，在unit7，会介绍draft的使用，最后一节会介绍常见的解决问题的方法。
最终的APP包含CRUD功能，将会用到determinations，为travel 这个entity设置初始状态 ，用Validations检查输入数据的一致性，Actions来审批Travel，并且会有静态和动态的特性控制，以及权限控制，Draft允许用户把未提交的数据保存到数据库，即使换了操作设备或是异常结束后面也可以继续。
看一下开发流程和将要用到的managed runtime
Managed runtime是相对于Unmanaged runtime来说的，简单来说就是，如果几乎没有需要复用的已有代码逻辑，那就用Managed runtime,好处就是框架会自动实现CRUD操作，如果已有很多逻辑需要复用，那就选择Unmanaged runtime，自己来实现CRUD等Behavior，开箱即用（out-of-the-box），开发人员只需要通过专用的出口(Determinations,validations,actions)关注额外增加的BO特定业务逻辑既可，Runtime会自动管理BO的生命周期，所以这种特别适合新应用。
Unit 2: Defining the Basic Business Object Behavior
这是本节要实现的内容，Behavior Definition就是定义BO的事务能力，我们将使用Root CDS Interface View的上下文菜单创建它，
开始
一定要注意这里的Implementation type
可以看到，两个entity已经被assign了基本的CUDcreate update delete操作，注意一个细节，Booking的创建是Associate到Travel的，因为它是child node。如果不创建entity是不可以创建Booking的。
接下来在这基础上做一些调整,两个entity基本类似：
persistent table zrap_atrav_1132,指定persist 表，就是数据库表，然后框架才知道对哪个表进行CUD。lock master，为entity启用锁处理，锁的实现由RAP框架（ managed runtime）来自动实现。etag master LocalLastChangedAt,为Travel实体启用所谓的乐观锁——即ETag处理。取消etag那行语句的注释，并将其中的<field_name>替换为LocalLastChangedAt。field ( numbering : managed, readonly ) TravelUUID;,因为使用了UUID做为主键，所以需要insta
