on 09-13-2016 4:11 PM
Hello,
Is there a limit to the BO extensions? If I want to add 100 custom field to Opportunity->Item node, what is the impact?
thanks
Mahesh
Hi Mahesh,
We have a HANA DB limit of 749 fields for every node/table. Also the patch process in PDI creates duplicates of the fields and it is better to restrict the fields in a node/create node extensions for the extension fields.
Regards,
Kavya
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Mahesh,
As mentioned by you should consider that in the dev tenant the extension fields are doubled by the original and the patch solution.
Furthermore the KUT Extensions Fields are added to the same DB table.
And other solutions may extend the same node.
Adding a great number of Extension Fields to the Root node will slow down the loading of the instances (e.g. in any OWL)
Opportunity (in C4C) is node-extension enabled. Maybe this helps.
HTH,
Horst
Thanks all for replying.
So, in case we add a custom node with huge number of fields within Opp->Item node, the performance would be better than adding all the fields directly in Opp->Item node? And we dont have number of columns constraint?
Also, data migration templates will have this node? Can we extend this node to services?
thanks
Mahesh
Hello Mahesh,
Often the Extension Fields can be better modelled in a 1-n node. This means you have several instances of the extension node but fewer elements inside this node.
That was the aim of my remark.
If you simply move all Extension Ffields from Root to Item, the OWLs would be faster, but the time for accessing the Item node would raise of course.
At the end it goes all down to databse tables. This means the restriction on the number of fields still persists.
Bye,
Horst
Hello Mahesh,
@Horst Schaude, Can we suggest a workaround here of keeping all the extension fields inside an embedded component and just link them to item level using UUIDs and keeping that UUID as primary key of that embedded object.
Do you think this workaround will bring some performance value in his case..?
Regards,
Saurabh
Hello Horst,
thanks for replying.
I understood that the restriction on the number of fields still exists if we move to a node. I assumed a new node means, a new table and we would have around 350 fields available.
My main worry is now about extending this node to Web-services and migration templates, because we are trying to condense the number of fields.
I believe 1602 introduced extension of custom nodes in some BOs to services. Can you please confirm that? Also, migration templates?
thanks
Mahesh
Hello Mahesh,
My Suggestion is to go for Custom BO with alternative keys like Item UUID or root UUID. This will reduce the load on standard object and you may experience some significant performance difference.
I just wanted to make sure from Horst that if it could be a good approach.
Regards,
Saurabh
Yes, that was my initial thought. By team expressed concern about the addition work while migrating legacy data, we need to create file inputs for this custom BO, and then create custom services for the custom BO.
Instead, if we have a custom node, if it is possible to extend the node to services and migration templates, we can live with that. Obviously there would be a hit on performance. We need to measure it though.
thanks for your replies..all.
Mahesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.