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:
The current Order advanced search in WebUI is implemented by advanced search:
CDS view design:
Check this excel: webui_search_fields_service
Latest status on 2017-06-03 15:09PM
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