cancel
Showing results for 
Search instead for 
Did you mean: 

Maximum number of extension fields we can add to a BO

Former Member
0 Kudos

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

Accepted Solutions (0)

Answers (2)

Answers (2)

kavyakrishnan
Associate
Associate
0 Kudos

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

HorstSchaude
Product and Topic Expert
0 Kudos

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

Former Member
0 Kudos

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

HorstSchaude
Product and Topic Expert
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

Hello Saurabh,

this is what we are planning to do. But the question is where to create the fields..in a custom node of Opp->Item or in Opp->Item node or an entirely new BO with alternative keys of Opp ID and Opp Line ID.

thanks

Mahesh

Former Member
0 Kudos

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

Former Member
0 Kudos

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

HorstSchaude
Product and Topic Expert
0 Kudos

Hello Mahesh,

A new node means a new DB table. So the limit here is 749.

Reg. Web-Service and Migration Templates you need to wait for the next releases.

Bye,

   Horst

former_member186648
Active Contributor
0 Kudos

Hi Mahesh,

You cannot extend node to standard service as of now, instead you can create new service on the standard BO and include the extended node.

Thanks, Pradeep.

former_member186648
Active Contributor
0 Kudos

Hi Mahesh,

There is no limit: http://scn.sap.com/thread/3508975

Thanks, Pradeep.