Overall idea
One order model consists of a series of objects with two different types:
(1) extension: data segments which exclusively belong to the header or to an item. We therefore distinguish header extensions and item extensions.
(2) set: a collection of data which can be linked to the header OR to an item of the transaction.
In the old world, each extension / set has each own persistence table:
And in the runtime each extension / set has their own runtime buffer as well, to store latest information modified by end user.
In new world, all fields from original extension / set are now merged into a single header and item table. Now for each transaction category like BUS2000116(Service Order), only one header and one item table are there.
(1) read: the set / extension data is read from new DB, and filled to corresponding object buffer in the runtime
(2) write: the latest change splited in set / extension is merged into a single record, and persisted to new DB.
Such work is done by convertor class for each set / extension.
We use github repository to manage issues & discussion during our development.
89 internal bugs are detected and fixed:
Phase 2 - CDS view development
The current Order advanced search in WebUI is implemented by advanced search:
CDS view design:
Check this excel: webui_search_fields_service
Phase 3 - prepare test data for performance test
Latest status on 2017-06-03 15:09PM
My progress
On Monday, I adapt Carsten's test report. For the original implementation, if we specify a very large number of Service Orders to be created, say 1 million:
I will meet with this out of memory exception:
So I change the order creation behavior, from creation all orders in a single call to the creation using WHILE LOOP:
After that I perform a performance comparison, no performance loss after adaptation :)
And then I spend quite a lot of effort for creation optimization:
We are still far away from the target 100 million test data, so we have to use the clone way:
Phase 4 - Authorization integration to CDS view
check this excel: DCL_Mapping.xlsx
A draft performance measurement is done, the result is no performance punishment after DCL is added to a CDS view.
Feasibility study to use CDS view to re-implement CRM Interactive Report
Phase 5 - performance measurement using Gerwens, Heiko's test framework - in process
本文来自云栖社区合作伙伴“汪子熙”，了解相关信息可以关注微信公众号"汪子熙"。
来源：oschina
链接：https://my.oschina.net/u/4383725/blog/3209890